Happy Saturday everyone!
3.9.1-15 is now available! I’ve updated a backend dependency(gunicorn) and @KaiRo contributed a convenient abstraction to disk management. Thanks Robert!
3.9.1-16 is now available! @phillxnet contributed an improvement to the frontend and I refactored the backend subscription logic a bit. Enjoy!
@suman with reference to your reply beginning of October, can you provide an update regarding the new update mechanism?
If I have not missed anything it looks 3.9.2 has never been officially published (forum nor webpage) and no new dev-log has been set up till now
Sorry for my question, but I want to understand and get a more “round picture” - THX!
Here’s the skinny – 3.9.2 is out and I am in the process of changing our delivery infra to push frequent updates to subscribers. We successfully pushed one such update(3.9.2-1) lately. The next few updates will make things clear on the UI about the new flow. The plan is to phase out automatic testing update delivery. It will be replaced by a set of easy-to-follow instructions which will save us $$$ in hosting and maintenance and lets us focus on providing better and faster updates to stable/paying subscribers. Hope that is round enough? and thanks for your question!
@suman thanks for explanation, sounds good … looking forward to this change
So how is that we can update to the 3.9.2 release at this point? I am currently running 3.9.1-16, but I have seen that 3.9.2-3 was recently released. I know the update process has changed, as @suman mentions above, but I haven’t seen the instructions on how to update to the new release.
3.9.1-16 is the latest testing channel release. That turned into 3.9.2-0 stable release, but since then there have been 3 ‘hot fixes’ to the stable release.
It’s in the throws of changing currently, but you are still on the latest testing channel.
Hope that helps.
So if 3.9.1-16 and 3.9.2-0 are essentially the same build, shouldn’t the hot fixes that have been applied to 3.9.2 also need to be applied to the testing channel code?
Is there a process that I could manually patch/build in those hot fixes into my environment?
We are going to stop automatic packing and delivery of updates in the testing channel. The plan is to provide a documented(in the UI) alternative for non-subscribers(testing channel) to follow to get updates. Right now, we are finalizing these steps. If you are on testing channel, you will get one or more updates as we transition into this new way. If you really want updates in the meantime, your choices are 1) subscribe to stable channel or 2) figure out the manual steps yourself from available docs. This can be very risky, even if you have high levels of linux and programming skills.
@suman Has a plan been put in place yet for updates for those of us on the testing channel? It looks like the code base has moved on to 3.9.2-9, released 2 days ago.
We are lagging behind, but the plan is indeed in place. Testing channel subscribers should see a couple of updates in the near future which will update your UI with all the information necessary to keep your system up-to-date going forward.
@suman As there is no more a dev log for new releases here on the forum…is there a way to see the changes/updates that was done within a new release?
rockstor x86_64 3.9.2-11 stable was installed over night and I was wondering what is new
We’ll add a changelog link to the UI, but you can see what’s in each update by going here: https://github.com/rockstor/rockstor-core/releases
@suman do you know if the testing plan is ready to roll out yet?
I like to keep my systems up to date (bug fixes, security, etc), so if the testing channel is being killed in favor of a paid only subscription, please let us know. That way those of us that are in limbo waiting for updates can make a decision on how to move forward.
@kupan787 Hello again
I can address this one:
All updates bar those of the rockstor package, the kernel, and btrfs-progs can be installed on either stable or testing channel at any time via the flashing icon to the left of the kernel version number (top right):
And given our kernels are unmodified elrepo-ml you have the option of adding this repo (via their instructions) to gain their updates as they come out or, as @jim.allum recently posted howto indicates:
to a specific version, until our next matching release of kernel and btrfs-progs is release. This is safer option as you are a little less ‘out on your own’.
Also see @suman’s recent post re kernel update:
Also all code is open-source and can be built from the GitHub repo via the instructions within the Developers section. Although this is non-trivial and there exists a caveat via an outstanding @Flyer pr:
which is trivial to apply. But note you may loose all settings / db entries so be careful on that front.
The plan is to transition the ‘testing channel’ away from an rpm based update to one where you can use the code published on GitHub the minute it is available. Ie as it’s merged it will be possible to initiate a rebuild directly from that code. This will server development better as there will be less delay to each testing release and less overhead to managing 2 seperate rpm update trains. So hopefully a win win, earlier and quicker updates as soon as is possible, for those who are happy with this more edgy approach, and more developer time spend on developing rather than rpm release management.
But unfortunately this is all taking longer than anticipated and is frustrating all round so please be patient as these things are always a little more involved than at first they appear. But the intention is to maintain a “value add” (probably stability/convenience based) to those on the paid subscription as that is an important element of Rockstor’s sustainability, along with Incident-Based support of course. Without these elements we could end up being another OpenFiler.
Note also that all updates to the Rockstor package in the stable channel subscription since latest testing release have been convenience and bug fix related. No security related fixes have been committed.
Hope that helps and let us know how you get on with that update everything else button provided by @Flyer, it is in keeping with all his other contributions, quite fancy: see also pincards password recovery system.
I have been running the testing channel, and after an update a little while ago to the last testing release I am having the problem where shares are not loaded on power up, which is obviously as issue for a NAS.
From what I read this is fixed i think in later stable builds, but is not fixed in the testing build (though I’m not 100% it is fixed in the stable build). At the moment I’m working around by going and executing a sequence of commands after a power cycle (enable quotas, restart the various rockstor bits).
At this stage I’m not sure if I need to sign up for stable builds just to fix my system (if it will even), or if there is another way to solve this issue? I can’t seem to see an actual ‘solved’ in the forums for this issue.
@Ivan Hello again and thanks for the report.
Not sure on this one as the main recent ‘not mounting’ issue was kicked off by a move in stable updates channel only to docker-ce which inadvertently disabled quotas which in turn caused us to have to deal better with no/disabled quotas which stable now does: via a series of ‘hot fixes’. But given you’re on testing the docker-ce move shouldn’t have happened yet. But you have apparently identified quotas as an element! Could you please open a fresh forum thread with your findings and any log entries (System - Logs manager, Rockstor Logs and Dmsg) that look suspect during a boot as it should then be possible to track down what’s going wrong on your install: make sure to include your Rockstor version. I’m not myself aware of any issues in testing that should cause this that are not quotas disabled related and unless they are turned off manually all pools should have quotas enabled, and it persists over a reboot (unless docker-ce is there to disable it for us; nice). But there have been quite a few significant improvements re pool, share, snapshot management/import/refresh that have been made so lets see if the logs can tell us anything in a focused thread.
Hopefully testing updates (in their new guise) will soon return and all stable ‘hot fixes’/improvements will be available via the testing update method (when it arrives) which is likely to pull straight from GitHub where all code is always available (tagged by stable release version) as soon as it is committed. The idea going forward is to cherry pick the best from development and release it ‘easy style’ to the stable channel.
Hope that helps.
We are now 3.9.2-17 but changelog stays at 15 - I would appreciate to follow what is new or has been improved, also to test and give feedback-> can you look into this and update the release page on github?