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.