I’ve seen it bandied around in a few places now - the possibility of rebasing on to openSUSE.
From what I see, this seems to be in progress? If so, where? Can I help?
I can see the one big win for this move would be the shift to a platform that treats btrfs as a first-class citizen. And the replacement for Centos stability and LTS here will be the LEAP releases (it is also super easy to switch from LEAP to Tumbleweed, and back, multiple times just by changing repos. I’ve done it)
@luke Hello again.
Yes that would be me.
Over the last few months I’ve been working on this and with eagle eyes one can see small references in comments and the like in a few of my pull requests over that time. Basically openSUSE has a far more advanced and very different btrfs subvol structure to their root. Plus they have their root snapshot / rollback variant of this structure selectable during the install (auto enabled if more than 16GB on root disk I think). Anyway that took an age to work out for Rockstor’s subvol surfacing and the majority of that work was merged in the following:
where I reference the existing CentOS base as legacy.
Also note that within that pr we also account for an erronous backport to Leap 15’s kernel of an unintended upstream btrfs inversion of parent-child columns which also broke a parser of our as the columns were simply the wrong way around, but I managed to account of either arrangement in the end, see:
“Account for upstream parent-child column inversion - group_is_assigned().” in that issue in your are interested. This also brings up the element of potential breakage whenever we change btrfs or kernel version. The upstream inadvertent reversal / kernel backport (at the time) is detailed in our code for reference.
But the above in turn required that our subvol mount system be enhanced as it wasn’t up to the job, hence:
Plus the newer udev (I think) and openSUSE specific treatment there-in broke assumptions we made about the output of udevadm which in turn broke and once fixed rendered unstable our existing by-id name selection hence:
https://github.com/rockstor/rockstor-core/pull/1937
which in turn (and only in part) lead to a regression in out disk activity widget which I’ve just submitted a fix for by way of the pending pr:
And there was openSUSE’s deprication (for security reasons) of ‘–stdin’ on passwd which broke our user password mechanism so this was addressed in:
https://github.com/rockstor/rockstor-core/pull/1928
Then there was the grubby assumption which broke the Web-UI’s ability to retrieve kernel version under an openSUSE source build, which was addressed in:
https://github.com/rockstor/rockstor-core/pull/1956
And then there was the default of no volume label for the system disk in a default openSUSE install which in turn was addressed in the following:
https://github.com/rockstor/rockstor-core/pull/1949
There were and still are a number of build issues which also required attention, one of which was addressed:
https://github.com/rockstor/rockstor-core/pull/1930
which also served to simplify our code.
So all in we have made quite a bit of progress towards rebasing on the openSUSE variants of Leap 15 and Tumbleweed and our subvol Web-UI surfacing of their root subvols was one of the most challenging but I have already achieved a successful replication procedure between a legacy CentOS install and a fresh openSUSE rockstor source build. And given the replication system within tests various other sub systems quite extensively, that was an encouraging win.
But during this time I have endeavoured to serve ongoing requests along with our current backlog of issues but all the endeavour to date has been very productive in routing out otherwise masked issues with out existing code and as such has also helped improve the quality of our current stable subscribers code.
I’m particularly concerned that we don’t break, at least yet, our current ‘in the field’ CentOS users by a major focus for me has been the porting / compatibility work required in our code as it stands. But in this time I have also tried to address glaring current short-comings in Rockstor’s base abilities. All the time trying to ensure that all code works also in the 4 variants of openSUSE, ie each of Leap 15 and Tumbleweed with the 2 rather different takes on root subvol exhibited by the boot to snapshot enabled or disabled variants. Fantastic feature that by the way. I’m sure many Rockstor users will relish the chance to reboot into any one of many prior working (or otherwise) install variants. Makes for a nicer all round experience if one can simply revert to a prior working instance of an entire OS. But so far that facility, although accounted for, currently won’t include the rockstor code itself, again this is from memory and would only involve a reconfig of snapper if required. Although that may also server as a separation between OS and Rockstor code; and in an rpm install setting there is the rpm reversion options for the latter anyway, db migrations allowsing.
Which brings me to my current focus. We have an unrelated build issue re:
which I’m currently working on.
There after, assuming I can get that resolved (I have some pending in test improvements build improvements but have yet to resolve the issue entirely) my next focus in on a btrfs in partition regression that I noted (via in code TODO’s) that I’d like to get to as if we leave too many regression in place we end up going backwards. Plus building on top of the recent fairly hefty improvements in:
Which addressed (bar a single detailed caveat) 3 related issue, 2 of which also depended on 11 other now closed issues. But the remaining caveat still makes it look like this feature doesnt’ work. So I would also like to get around to that remaining caveat expressed in issue:
But also in the mean time we have gained quite a few crucial capabilities, like surfacing missing disk, fs errors etc.
Anyway I think it’s clear that this is a work in progress but we also have a ‘current’ user base to consider, hence the frustrating progress on this.
Interestingly enough I also posted more recently the following by way of a teaser on the openSUSE move:
It’s also interesting that nobody has commented on the lack of their /root subvol being surfaced anymore. With the extensive subvol reworking to accomodate openSUSE’s more grown up use of btrfs it turned out that our prior /root subvol surfacing was an accidental occurrence and was ‘just plain wrong’: so it was removed to return the code to a more proper state where stuff works because it was intended to work 
.
I suspected this but there is also the SUSE supported transition from Leap 15 to there SLES
with full support. I’m sure that would also be an very attractive option to some of our larger Rockstor users. Plus they employ quite a few btrfs developers and have (obviously) their own kernel developers so can maintain their own btrfs backport to their Leap kernel (Not sure what happens with their Tumbleweed variant). Something that may be overlooked when we move and users still see the 4.12 kernel.
Anyway, as I think is obvious by now, I’m quite enthusiastic about this proposed move and have made I think quite a head way into at least transitioning our code to be compatible with their way more advanced root setup but we have an obligation to also address current concerns, hence my mix of focus of late. But I think we are getting there on:
I have been meaning to establish a wiki of the remaining issues re Rockstor and openSUSE but alas as sketched out above, there is much ongoing work that also has to be addressed.
Almost undoubtedly, especially if you are game. But my initial concern is duplication of effort. I have ‘in house’ a sequence of the remaining steps necessary to get build Rockstor master on all mentioned openSUSE variants and it would be a shame for you to have to re-discover them all but I must first focus on getting the build tree back into a ‘works first time’ state. I will then prioritise the wiki so we can steam in with the far more exciting elements of moving to our more obvious home of openSUSE.
I have incidentally also moved my main desktop workstation over to Leap 15 and moved form gnome (Fedora) to KDE in the process so it’s all been quite disruptive but I’m almost settle in again but do have to re-establish at least my prior range of KVM systems upon which I at least developed. These obviously now include a Leap 15 and a Tumbleweed.
I was also quite attracted by their transactional updates install but I think we have quite enough shiny in the near future for the time being.
Please be patient on this and in the mean time if you could establish an existing build setup such as is detailed in:
http://rockstor.com/docs/contribute.html#developers
and familiarise yourself with our existing master branch build, which is also currently our latest stable release version 3.9.2-41 (as of this post) which is now way ahead of our current testing release rpm:
then you will be in a position to assist with identifying and fixing the remaining issue re the openSUSE move as prior to ‘rebasing’ our iso and it’s associated rpm’s we first have to have it build and run as expected on openSUSE as well as CentOS, obviously.
The build OS is essentially a fully updated stable channel Rockstor (to get the production repositories and their move to docker-ce) with at least the associated rockstor rpm removed (although the build procedure is supposed to do this for you but can fail under some manual intervention scenarios).
I’m also very keen on having no regressions at all. In our current user base, stable channel CentOS based, and the proposed new installs (from source or iso install) on openSUSE. This is a tall order but one worth pursuing so if you submit any code changes please bear in mind that I at least would like for them to be non breaking in all of the existing and proposed installs.
One fairly major element of this move to openSUSE, as I see it, is the publicity hit. It should also coincide with the iso being updated, again obviously, so that all non stable subscribers will receive the very latest code which is actually now (in no minor may down to the openSUSE port effort) far more robust that our current testing release. But then there is also the sustainability of Rockstor’s development to take into account, which currently heavily relies on subscriptions. So this is all a very tricky thing that may just end up being another openFiler so any moves we make have to be carefully orcestrated to server the project as a whole which in turn also serves it’s users. Hence the current dropping of testing channel updates, there just wan’t the developer time to go around and we owed those who help support the project a ‘value add’ and that currently is the rpm updates.
Incidentally I did post a teaser image a few months back of Rockstor running on openSUSE but made no mention of what it was. I was hoping to get a bite of interest but alas it has gone unnoticed to date and I now can’t find it!
I do have the following showing a rockstor install from august on a boot to snapshot Tumbleweed install, note the fancy subvol= reference:
This was taken prior to the kernel version / grubby fix indicated above so no new fancy kernel to show off, and I’ve yet to claw may way back to a full KVM set so I’ll post something newer once that’s in place.
Good luck on getting your initial dev setup in place and do take note of my current issue re it’s required ‘hack’ to build. At least until I make some more headway.
I’ll get to that openSUSE port wiki entry shortly but I must first deal with current issue re build and backlog. If you have any build issues please open new thread or pm me as it would be great to get you on board and have this thread as an ‘opener’ on what’s happened so far on that front. I intended the wiki to be a live progress on the remaining hacks required and manual config expected prior to a build with the aim of a clean source build working as expected on only a slightly modified openSUSE install.
Hope that helps you and others on the background progress to date re openSUSE move. As is often the case it turns out to be a lot more complicated/involved than expected. But I do have a plan where all the dots actauly line up .
Oh and as a last note we even have a now rather outdated but hopefully salvageable pull request form @sfranzen on surfacing elements of snapper within Rockstor:
https://github.com/rockstor/rockstor-core/pull/1491
with it’s associated issue:
https://github.com/rockstor/rockstor-core/issues/1432
But that was before I make needed extensive changes to the subvol mechanism so that’s going to be a bit of a major undertaking to get it re-based and working as presumably it once did. But I do hope to get that one re-integrated as there was a tone of hard work that went into it. Thanks to @sfranzen for that and note that it has not been forgotten.
Just a quick update on the openSUSE rebase progress:
Latest Tumbleweed (2 days ago) Snapshot20181029 with now just a few pending build changes to master. Almost default install with: System Rollback by Booting from Snapshots enabled (default if sys disk is greater than 16 GB). Though untested from a Rockstor point of view, but looks promising as I think we are independent given our location in /opt. More basic concerns / testing to worry about just of yet.
‘system’ pool (I’ve dropping the rockstor_rockstor / rockstor_dhcpname pool label).
And the associated surfacing of only the ‘home’ share in keeping with Rockstor’s simple take on things. This should also make for a smoother transition for existing non technical Rockstor users as it should appear to be identical / bar a much newer kernel of course.
I’ll get to that wiki soon so that anyone interested can chip in with sorting out the outstanding blockers for our transition, of which I’m sure there are more than I have yet discovered. But most basic function is as per CentOS variant. But as mentioned previously I’d like to raise the level of basic function prior to this move as we currently fall just a little short in that regard.
Please consider subscribing to stable channel updates if you would like to support this effort.
I have nothing technical to add here - I’m a webdev who knows his way around Linux, but this stuff is way over my head I understand what you’re trying to achieve and roughly how you’re getting there, but I don’t see myself chipping in in a technical capacity.
I just wanted to express how absolutely thrilling and inspiring it is to see you do it. Thanks for all this hard work!
@doenietzomoeilijk Thanks, this is very encouraging. I was a little worried at how this was going to be received as change is often difficult and this is quite a big one as it goes. But I’m convinced it’s for the best and I’m trying to do it in small well defined steps so we can catch the inevitable regressions as and when.
Thanks again for your support.
I was wondering why those weren’t happening.
I’ve got a set of VM’s done now, pretty easy to test things this way 
What do you mean by “surfacing”? snapper is a wicked good tool BTW, very easy to use.
@phillxnet the one thing I’m unsure about, is where to find info on the openSUSE rebase such as:
I’m sure I’ll work it out myself, but quick access to this info would help. Also, have you considered using openSUSE Kubic as the base? Very good minimal install.
What’s the status of stable updates? Mine is up for renewal in December but do we get updates (I can’t see stable way to yum upgrade to another OS) or do we just need to start picking repos ourselves and use gui as long as it works?
I’d like to say that I love rockstor and I’m excited to see it brought up to speed to a better base OS and better kernel support for btrfs. I’ve still got 2+ years on my subscription.
But I have some questions.
What would the upgrade path would look like for a current stable subscriber to upgrade to the new rebased version. Would it be something that can be performed in place?
Will all settings, shares and rock-ons be retained?
Would it have to be done with a new iso install or can it be done with an online update?
How about hardware compatibility?
What are data loss risks when upgrading?
How about license transfer to the new base - would that be retained or would a new subscription key need to be installed?
Thanks,
Chris
@Jorma_Tuomainen and @cferra Hello again to you both and thanks for helping to support Rockstor’s continued development via a stable subscription.
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.
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.
Is CentOS still going to be supported or receiving more up-to-date kernel, or any other (security) updates from 7.6 while OpenSUSE rebase is being worked on? Leaning towards renewing my subscription but reinstall is always a hassle.
Not fond of suse and my day job is keeping tens (between 50 and 100) of different (95% CentOS 7) servers up-and-running, that’s just what I’m used to
From the Rockstor code perspective my intention at least is to maintain code compatibility with CentOS, but ultimately this whole venture is to improve the Rockstor experience by users not relying on our already failed attempt as regular kernel updates for example. So yes the rpm updates are inevitably going to stop on the CentOS platform.
That would be nice but we have failed on this one for a while now so this may also not happen (see moving our distro base so they do it for us in expert and timely fashion)
Yes, bar the kernel (copied from elrepo), btrfs-progs, and netatalk (AFP deamon), all other packages receive updates as per usual from the upstream CentOS repositories, ie from a package point of view look at the following in a stable channel Rockstor install:
yum list installed | grep '@rockstor\|@Rockstor-Stable'
btrfs-progs.x86_64 4.12-0.rockstor @rockstor
docker-ce.x86_64 17.09.0.ce-1.el7.centos @Rockstor-Stable
kernel-ml.x86_64 4.12.4-1.el7.elrepo @rockstor
kernel-ml-headers.x86_64 4.12.4-1.el7.elrepo @rockstor
netatalk.x86_64 5:3.1.11-0.1.1.el7 @rockstor
rockstor.x86_64 3.9.2-42 @Rockstor-Stable
rockstor-release.x86_64 3-9.23.el7 @rockstor
And the netatalk was only there to address a short fall on CentOS’s part.
So it’s really only those packages, the rest of the system is as per a regular CentOS install and so my understanding is that it will simply update in place as it always has done, pertaining to their support time lines anyway.
I’m personally not fond of CentOS (slow to adopt technologies), but then at another point I wasn’t fond of SUSE (no openSUSE at the time) as yast would mess with ones config files. However I’d like to say that bar a few inevitable hick-ups CentOS has been good to us. But simply put their direction is just not ours and we, as a small team with a large project, obviously need to rely on our upstream, especially and evidently for our kernel and filesystem updates. Plus of the 3 Enterprise associated variants openSUSE/SUSE is an obvious choice for us. I particularly like openSUSE’s community lead governance (only one board member is, or can be, a SUSE employee) and the fact that openSUSE survived a ‘quiet’ time for SUSE back there. Can the same be said of the now less independent CentOS?
Too right. But I don’t see a way around it. But I’m keen on moving to a far more ‘lean’ image based install so hopefully that will be a form of compensation (more on this once we have our code in order) and move to exploring / testing the install options. And hopefully we can also offer a variety of install options, ie ARM based for example.
Yes, distribution preference often comes down to that, and in fact one of my first work distributions was the original Red Hat (I chose it) before it became RHEL some way down the line, and dating from a job I used it on at the time it was November 2000 “17th International Diabetes Federation Congress” held in Mexico City. I did the registration sever database, which at the time had never run on a linux machine before, according to the developers (linux was still quite new back then). Access to the db backend from the windows clients was over SAMBA (yes don’t ask) and I had to be really really careful with file permissions and timing as the proprietary db would lock if any were out: obviously suspecting/claiming foul play of course!. I ran it across a couple of independent servers so we had complete system failure over capability. This would make it around version 6.2/7.0 by the looks of it (Oh the glories hailed for the shiny new 2.2 kernel of the time ). But I’d played with it from around 5.1/5.2 (1998) if I remember correctly. At around that era I moved my mother and my mother in law and father in law’s desktop machines over to whatever was the current version and they all saw a good few year of service. I’m a bit of a linux fan as it goes.
Hope that helps.
Based it on CentOS will make RockStor something on the net, a dedicated server. It is not mainstream software. If you want this to be distributed, you should change to Ubuntu / Mint - that is where all the kernel and device management code is done. A very good reason is “apt” - allowing release and version management at all installations. I cannot use Rockstor as it is, then the CentOS base will be considered and new platforms like DeepIn is not here. But router and network switches are based on CentOS. The AV security is based on Ubuntu / Mint - all the “Bleedin” was on Mint. But: The difference is in how it looks, not how the disk works. Ubuntu / Mint walked down a sily route with the “ssl”, but they have miles better exposure to the DMA arbitration, device drivers. They dropped KDE because nobody used it! DeepIn is pretty close.
What, exactly, are you trying to say? All I can take from it is that you seem to think that switching to an Ubuntu/Mint base is the only way forward, or something.
It is not The Only Way forward, but to e more than just a few, you should consider making a branch that is based on the distribution with the most users. Here you get the latest hardware updates and the kernel is tested on these. I have said the same to DeepIn, it is better to stay together like Ubuntu and Mint has done.
You have a valuable collection of tools and management software that I would love to present to others. The routers and TV box hardware runs Linux, and can run disks / mass storage. This is used to store tv shows for later viewing, but why not Rockstor and offer home cloud service? All photos is then available at home, all the private videos. This is where most of us use the media, they are just files - like my Word document and spreadsheets. Your decision to control the platform makes this impossible. But package the scripts and binaries as “apps” and RockStor will get a much bigger audience.
I’m as big a fan of Debian based distros as anyone (though I’d choose Debian itself, not it’s derivatives) however to address some of your points:
This is a relatively unknown statistic. I’m assuming that you’re basing this on data from DistroWatch, in which case it should be noted that this is calculated based upon page hits from desktop systems. Mint and Ubuntu are primarily desktop systems.
This is not what Rockstor is designed to be. The idea is to turn a computer into a NAS appliance, not a desktop computer.
And Rockstor can do those things as well, by itself.
This is exactly what I have setup. Rockstor running Plex for media, Owncloud for document sharing, etc.
Rockstor is the platform. That it’s built on CentOS or OpenSUSE is beside the point.
The idea here (re-iterated) is to run Rockstor like an appliance.
I’ll concede your point the day you install a toaster into your router.
Rockstor is a BTRFS NAS. Arbitrarily installing it onto a system it doesn’t understand will not work.
In the same way you cannot arbitrarily install any linux flavour of your choice and then install FreeNAS, OpenMediaVault, Synology DSM, etc.
The fact that you install it yourself does not change the fact that Rockstor is designed to be a device, not a program on an arbitrary device.
Your attitude is wrong. RockStor will be another comma in a sentence in history.
I have made file systems - you have not.
In light of the fact that this is becoming a somewhat heated argument, it should be pointed out that I am not from the Rockstor team, and my opinions/arguments do not necessarily represent that of the development team or the greater Rockstor community.
In your opinion. I don’t see why this needs to be a personal attack.
That would actually be a pretty good rating, many things go by that don’t equate to near that.
Really? Which one(s)? - I’m generally curious.
You’re right, I haven’t built any filesystems (though I wrote a FAT16 ARM driver once).
Regardless, your argument is not even about filesystems (near as I can tell anyway).
It seems that you’re arguing twofold:
For the first bullet point, this is simply not the purpose of the project. I agree that it would be a lovely idea to have a portable UI such as Rockstor, but without control over it’s entire environment, it needs to be built in a way to understand and support a multitude of different environments.
This is compounded further by the fact that Rockstor’s native filesystem (BTRFS) is managed in completely different ways to traditional linux filesystems.
The development resources to support this would be immense, and this is developed by a very small team.
Regarding the second point, I again point out that this is based upon an invalid premise that Ubuntu/Mint is the de-facto default Linux OS.
Just because it’s favoured among desktop users, this does in no way make it a de-facto default.
Also, Ubuntu and Mint are both forked from Debian and rely on Debian’s upstream.
This leads to the same challenges that Rockstor already faces, namely provisioning up-to-date Kernels due to the long release cycles.
Noted of course that at least with a Debian base you can select to be on the testing or unstable branches for quicker updates, however in my experience (Primarily a Debian since Hamm in 1998) the testing and unstable branches are dangerous to run as an appliance, as they’re quite prone to dependancy issues on the default repositories.
OpenSUSE tends to have shorter release cycles, meaning things like the Kernel is updated quite frequently. This is particularly useful to Rockstor, as it’s built on BTRFS which is actively developed and frequently updated.
Using an OS with a more frequent release cycle allows the developers to use the bleeding edge BTRFS features supplied by newer kernels.
All that said, I would suggest that if you don’t like where the project is headed, you are welcome to fork it and go your own direction, or use a different project.
In my opinion there is no real need to keep the CentOS Branch alive as long as no kernel updates would come anyway. So probably it would be better to just fokus on getting that opensuse version out, even if it would come with some hassle for migrating (perhaps complete new install). But delaying the migration because of getting a live migration working is perhaps not worth the time as you just fall back even more kernel versions with a lot of btrfs fixes.
And here we go:
It’s a bit rough but at least it’s ready (exists) now.
Hope that helps those interested in helping with this development.
Please remember that any proposed changes should not break existing CentOS installs . At least for the transition period.
Hello,
I got pointed out to this post, but I could not find why not to switch to Fedora? I mean, btrfs support is there, snapper is there, there is even integration between grub2 and snapper.
Is there anything Fedora community could do so that you will consider building platform on top of it?