Very much so yes. But quite some effort has been put into re-doing our back-end systems as we are on the verge of out growing our existing systems. We have more recently had a few timeout issues related to too many connections and the like with for example our rock-ons and our yum repos have also slowed to being a little tricky at times so work has been put towards re-doing how that’s all done in the background. Hopefully this should come to fruition shortly. A web based system to enable stable subscribers to keep an eye on their current subscriptions / installs has also entered a limited beta phase. This may grow later into more of a ‘value add’ depending on how it it received.
So all of the above has slowed our stable channel releases some what of late as our last stable release was now 2 months ago. The following Github page indicates our stable releases:
For now our testing channel is deprecated but that may not continue to be the case once we are fully moved over to openSUSE. Some background info on this is available in the intro section of the following forum thread:
However all these pertain only to the Rockstor code and currently, until we get to inherit openSUSE’s kernels, the kernel also. The rest of the system continues to receive upstream updates.
I don’t think you need to wait as it is currently undetermined when that will be. Also, as Rockstor encourages seperation between data and system, you will be able to import your CentOS based Rockstor pool into your openSUSE based Rockstor system in the usual way. There are however still some sharp edges on the configuration save / restore system that we plan to improve prior to the openSUSE based release to help ease the migration. @Flox has already begun working on some of these. But ‘as is’ imports of pools in openSUSE based install (currently only from source) are identical to imports in CentOS based Rockstor systems. I would however recommend the stable channel as the code there has many fixes in comparison to the last released testing channel. But many forum members are still using the last testing.
But yes, once we release an openSUSE based iso it will have the latest code on it so would represent an upside for the obvious pain of having to re-install. But a clean install and data pool import really isn’t that bad so definitely worth trying out CentOS based offering.
There is also a number of questions over our position re using the openSUSE, more specifically the SUSE brand. We may have to rebrand but I don’t want that. As it seems like everybody looses that way. But openSUSE are currently in talks re a name change such that they can divorce themselves from the limitations imposed by SUSE and it’s brand use. So you see there are a number of things still in the air. But that is nothing new so we intend to keep chipping away. But I for one look forward to settling down to more regular releases where we have our new backend infrastructure in place and our new disto base safely tucked in. But that time is not yet upon us. However when it is we can rely on openSUSE (or whatever their new name will be) for our upstream kernels which is an area we have essentially failed in to date (at least periodically). And given SUSE, the main supported of openSUSE, employs many of the btrfs developers and they also default to btrfs for their system disk we are likely to be in a much improved position to move forward with all our plans.
As an aside, Rockstor doesn’t support importing disks from a synology as I believe they use other layers below btrfs, ie mdraid LVM etc which Rockstor does not support. They are also very likely to use partitions where as Rockstor very strongly favours whole disk brtfs. We are aiming to keep the systems/layers involved with data retention to an absolute minimum and btrfs whole disk (no partitions) direct to disk gives us that. It also fairly massively simplifies the required Web-UI interface complexity so that’s nice also.
Hope that helps and I would encourage you to at least dabble with Rockstor on a spare system and report any of your findings here on the forum as there are now quite a few users of both testing and stable variants. Just avoid creating any shares on the system disk to easy any future transition, plus it’s good practice to keep system and data separated. Also make sure to pick an update channel and apply all consequent updates as our iso is now rather old.