@kupan787 Re:
That would be great. And yes, should just be allowing it as an option and reporting it correctly there after. But theres also the kernel version issue but soon we are going to have to set a minimum kernel version we ‘support’ and it’s likely to be whatever Leap15.2 arrives with and it’s associated back-ports.
Agreed, but we could start by surfacing within the Web-UI the raid levels and take it from there. We currently fudge these a little and favour the data for reporting I believe, from memory. But getting them both in the Web-UI and through-out the models etc would be great. But this ‘level’ of stuff has to have unit test coverage and there exists already a test for the reporting bit so looking to that would be a good starting point.
Again from memory I think we have the facility to track this but just don’t, so you may well find stuff in place already. Again it’s been a while since I looked at the code from that angle. Also many fencing issues with regard to what we don’t allow will have to be revised once we introduce new levels, i.e. min number of disk etc. But yes it would be fantastic to at least start to report the metadata as well as data raid levels. And from that unit test it looks like we collect the lot already at the lowest level. It’s just fudged later to represent only data.
Exactly. Our current focus is on feature parity with our CentOS variant (very close) so we can establish the new ‘Built on openSUSE’ Stable Channel rpms. There after we can steam into this stuff in the testing channel, but we first have to do the little matter of the Python 3 changeover !! But all doable and in progress.
Bit by Bit, and I’m looking forward to where we are going on all of this.