The openSUSE move has been in the viability testing stage for a number of months now and a significant number, but not all, of the stable channel updates have been concerned with adding openSUSE compatibility while maintaining / improving CentOS function. That has been a far more difficult task than just coding out right for openSUSE, as was done prior for our CentOS base. But I am keenly aware that Rockstor’s development is only sustainable (read possible) with the continued support of our stable channel subscribers, along with income from the Donate button within the Web-UI of course. And in this context I’m very keen on making this transition as smooth as possible. But a re-install of the openSUSE based variant is inevitable I’m afraid. However I hope to make further improvements to our Configuration Backup and Restore system before the official ‘newfangled’ openSUSE based installers emerge (new iso) and am planning to write comprehensive documentation, with pictures, on how to transition from the legacy CentOS base to our pending, and still very much in development, openSUSE base. But, as mentioned in my long post above, we also still have basic functionality ‘short falls’ which have to be addressed.
Essentially at the moment and for the last 6 months or so I have had progressively more functional openSUSE Leap 15 (pre release initially) and more recently also Tumbleweed based installs of Rockstor playing a major part in all of my development issues. This has more than trebled my testing burden as openSUSE has boot to snapshot rollback capability which presents root (system disk) subvolumes very differently depending on if it is enabled (default if sys > 16MB) or otherwise) and so there are actually 4 variants I’m trying to cater for just in the openSUSE camp. But I think it’s all going to be worth it as we do away with our bespoke (elrepo kernel-ml add-on) and ancient 3.18 install kernel (rather inappropriate now really) and simply inherit openSUSE’s default kernel maintained in part by some of the btrfs developers. This is a ‘no brainier’ on our move, especially given our past performance on kernel updates: our actions did not match our intentions so the move will ‘fix’ that. Plus I like the many additional options openSUSE presents for image construction / install options. Oh and there’s that boot to root btrfs snapshot thing which I really looking forward to. I.e. one has a working system and an update break it (obviously non of us have ever encountered that ) : our current base offers us little option, and with sever breakage re-installs (of the same OS) have been the quickest / simplest workaround. With a sufficiently large system drive, openSUSE defaults to allowing one to ‘revert’ the root of the os to any number (depending of available space) of prior working examples by selecting them at the grub boot loader. That in itself is worth the move alone. But we also need to address our evident failure to perform timely kernel updates: and this is an obvious area best left to upstream expertise: our linux distro base. This way everybody wins, we get to spend more time on the actual Rockstor code and the progressively more numerous Rockstor users will get to see the rather under represented glory of the openSUSE / SUSE distros and release tools. Plus a rather under reported element of Leap 15 is that it now has binary compatibility with SUSE’s SLES. That will be very important in at least a few mission critical circumstances.
OK initial (at least dev focused) spiel over:
They are and have been continuing during this development, and in no small part because of this development; CentOS cannot be our future: they have made this clear on their btrfs stance. OpenSUSE defaults, as we have done for quite some time, to a btrfs root and as a result can offer features no other linux distribution can.
For an as yet undetermined time I’m at least hoping to maintain code compatibility with CentOS but the creation of these rpm’s may well have to transition to our new build system and there may well be blockers via diminishing returns on maintaining our CentOS rpm releases. Especially given we occasionally receive low level fly by contributions that may well not have been tested on what will then be 5 different install bases and that’s a lot to ask for a casual contributor. Plus, if we do this right, all will automatically benefit from moving to the openSUSE base.
Short of it is this is a messy arrangement, but we should come out better overall.
Thanks for your most welcome encouragement, this mirrors my feelings on the matter. It’s also a major bonus that SUSE helps to fund openSUSE but remains independent from them; they also employ a number of btrfs developers.
The stable channel subscription funding model is a value add to our ‘backers’: more frequent Rockstor code updates. And a subscription, along with it’s associated activation code, is tided to the motherboard used during the install, ie the output (run as root) of ‘cat /sys/class/dmi/id/product_uuid’ and so any re-install using the same motherboard (bar the caveat of a few known non unique product_uuid’s) should result in the same activation code working as before. As it’s the exact same Rockstor code (bar some command paths) running on the re-install it was on the prior install: even given the move to an openSUSE install base. It is in everybody’s interests that this be maintained. But as I say we arn’t yet at that (rpm) stage and I’m currently still working on achieving the cross distro (CentOS, openSUSE Leap15/Tumblweed) functional equivalence.
- Config save and retrieve to a client machine: Configuration Backup and Restore.
- Power off & physically detach (unplug) all data drives (optional but highly recommended).
- Re-install on same motherboard, and ideally to a different system disk but not necessarily.
- Enter prior installs activation code (it’s the same motherboard so will have the same appliance id).
- Apply update and reboot when done; if all is ok power off.
- Re attach all data pool devices.
- Import pools (btrfs volumes), shares, clones, snapshots (btrfs subvolumes).
- Import prior saved config.
- Carry on as usual, the Rockstor code is and will be essentially identical.
Given the above upgrade path:
settings yes with proviso that it’s currently limited, Pools, shares, snapshots yes, rock-ons possibly not as we currently don’t have a CentOS re-install transition path for them either.
Essentially I want to preserve our current re-install capability across to the as yet non existent openSUSE install rebase. Note that all contributions on improving the config back and restore are of course welcome as this would inevitably ease this transition. I will try to take another look myself also but this is obviously a busy time. And we have mounting pressures to address our current short falls re kernel btrfs updates which in this context may not be time best spent. Rockstor is a small but dedicated team, but we also have quite a high contributor count for our age and niche, especially given the projects code size / scope. We have also had quite a number of first time GitHub contributors so I think bodes well for us.
New iso. Which of course also means that we finally get our now far better stable code into the hands of the more casual users. This will ultimately be a good thing and presumably, if it all lines up, we carry on as before: ie value add in Rockstor code update frequency for the subscribers. But with a far better introduction to the project for our then new installers as they will then get to run the now far more developed recent code.
Inevitably much improved, especially for the installer. Our current outdated CentOS installer has kernel 3.18 and is a ‘job’ to update. OpenSUSE’s image build tools are fairly fantastic and far ranging so new iso’s should in the future be more common and varied in option (possibly). I’m also hoping to move to a system disk image transfer type install option as a default (much work to be done on this as of yet) as there is then almost zero room for an ‘incorrect’ or incompatible install and should open up Rockstor to a lot more people and make re-installing a far faster and easier affair.
Hardware alterations (different system disk if used) carry with them inevitable risk. But as the Rockstor code itself will be unchanged (as far as we can make it work that way) the risk should be minimal, especially if the above advise is observed (ie disconnecting data drives entirely). And if one uses a different system disk for the openSUSE install then if it doesn’t work our right away (teething problems) then one can simply revert to booting from the prior CentOS based Rockstor install which shouldn’t pick up from where it left off. Hence the recommendation to use a new system disk for this new OS based Rockstor install, which to be clear doesn’t as yet exist; but I’d like for it to and addressing these questions is a priority as it is likely only to come to fruition via the continued support of the stable channel subscribers such as yourselves.
Only in the same case as we currently have where the motherboard in question has a non unique product_uuid.
There are still many details to work out but where there is a will I am hoping there is a way.
Any ‘would be’ code contributors / debuggers might like to take a look at our current (master branch) configuration save and restore mechanisms as they will, during this transition, receive quite a work out, so it would obviously be best if we do what we can to address their bugs / short falls prior to this move. None of that code is distribution specific, working mainly at the database save and restore level, so if any changes work on our current CentOS base they should also work equally well on our proposed future OS base of openSUSE.
The rockstor-core code is licenced under versions of GPLv2 or later. Our various and numerous rockstor-jslibs and the like have their own particular licences but are all never the less open source. The subscription system is not a licence grant of any sort, just an attempt to achieve a sustainable development model for Rockstor by way of a value add exchange. Although the Update Channels Testing Channel section is, at least for the time being, currently out of date, the intro/history and Stable Channel sections remain accurate bar the reversal of update frequency of course. We also have no contributor licence agreement which is important to some, including me.
Thanks for your pertinent questions and I hope this helps to ally any worries on the stable channel subscription plans. At least initially this looks to be the way to proceed but ideas, as well as donations, are welcome as many open source projects such as ourselves struggle to achieve sustainability while simultaneously making on-going efforts to supply a need.