@def_monk In the linked recent post where we discussed your alpha testing of our “Built on openSUSE” (early-adopters/developers only) offering we had the following exchange:
Now we have 3.9.2-52 rpm out I had a failure here to offer this update on an openSUSE rpm install that I’m unable to reproduce, the exact same machine with no other updates applied, when reverted to 3.9.2-51 now offers, via Web-UI, 3.9.2-52, as intended. Yet there has been no rpm dependency changes between these 2 rpm versions (last dep change was 30/11/2019, a few days before 3.9.2-51’s last merge).
As you are now intrepidly testing (and debugging samba issues) on such an install, could you report if your system successfully offered you the just released 3.9.2-52 rpm upgrade, assuming you have now subscribed to the testing channel from within the Web-UI that is.
You should be / have-been presented with the following indicator within the Web-UI:
and have the consequent changelog offered upon clicking that link or visiting System - Software Update.
It’s a bit of a quandary but I’m super keen on having this system working first as it’s a ‘quality of life’ component for those doing the testing as they can then, post fix release, just update and further test this crucial feature as we work towards getting feature parity with our CentOS offering. I’d added a few unit tests and the like to this part of the code in 3.9.2-51 as part of establishing our testing channel re-launch so if you have a reproducer of this issue then great, and any pertinent log entries will hopefully help to diagnose what went wrong that I can’t now reproduce. Many fish to fry so thought I’d ask your experience of this critical feature from your own testing.
The GitHub issue for this is as follows:
So if you could let me know either way that would be great. No worries otherwise as I know these things can be quite the time drain.
Anyone else able to chip in with relevant reports on this function are of course, and as always, welcome. Frustrating that I was unable to catch the ‘cause’ at the time but the particular machine was critical to the most recent testing channel rpm roll out and that took priority. And now it works as intended we have/had a heisenbug; possibly an interim update was masked by an in play (read in memory) binary. But all updates were applied first and the system was rebooted prior to it’s final testing roll just prior to the new rpm publication, so pretty sure I didn’t have an ‘in memory only’ package controlling binary at play. This may simply be a case of me not using dev mode ‘disable cache’ in my final testing. But no user is likely doing this either so that would be a double edged procedure in it’s own right.
Hey @phillxnet, Just looked at it. I’m being offered 3.9.2-52. I haven’t opened the UI since the weekend, either, so it has been pretty untouched since then. I see the changelog and was even presented with a few icons to act as notifications that the update was available. Everything seems to be working.
I do notice that my package updates also lists an update for rockstor. Is it recommended to use one update method over the other? I assume both buttons just run zypper update behind the scenes?
I just wanted to quickly answer the second part of your post:
They both do different updates:
The UP arrow next to the Rockstor version will bring you to the System > Updates page, which will then take care of updating the Rockstor package only. No non-Rockstor package will thus be applied this way.
The little rss/wifi signal-like icon located to the left of the kernel version, however, will proceed with the system package update, i.e. everything that is not Rockstor package. Conveniently, clicking this icon will first provide you with a nicely-parsed list of all updates available and their description as well so that you will know exactly what is to be updated.
If the RSS icon is supposed to be all updates other than rockstor, why is this there?
EDIT: My thought is that if this isn’t supposed to be there, is it possible using it to update could cause the weird state that we’re looking for with no update presented.
The most likely explanation in this case is that I spoke too quickly and was dangerously wrong. I’ll have to let the expert (@phillxnet) give you the correct answer then.
My sincerest apologies for possibly sharing erroneous information there .
EDIT:
Now, as to why I was wrong: I quickly tested that on a system freshly subscribed to the Testing channel. I could thus see the new rockstor 3.9.2-52 release, but the the system updates (RSS icon) were not listing the rockstor package. After a reboot, it does show the same as you.
I should have been more diligent and careful and not jump to my erroneous conclusion; my apologies again.
I’ll update my previous post to correct all that once we get confirmation from the experts.
This was intentional and serves as a secondary indicator of a rockstor package update availability. And in the single instance that sparked this thread, where the rockstor package Web-UI update system failed to work for me, the rockstor package was still listed on that system, as you have pictured in this thread. So in that case it worked as intended when the rockstor package only system failed (for unknown reasons). Thus it was a backup that there was a rockstor package update available even when the System - Software Update failed in this regard. We then have the user informed of this case and then might ask “why is this showing up” ergo backup notification system. So I was quite pleased that it at least worked on the ‘problem’ system. We could add, against this listing, to “use Software Update” or the like to that particular entry. Just haven’t gotten around to it.
As covered in part by @Flox already there is a difference.
Flashing wifi to the left of the OS and linux version in the header = all but rockstor package.
Rockstor version click or System - Software Update does the rockstor package.
So the first is for those wanting specifically to update everything except rockstor.
Flashing wifi in code (on the openSUSE variants) does the following:
System - Software Updates, in the openSUSE variant does the following:
Which uses the following distro specific variables:
So in short on Tumbleweed we use “zypper dup” and on Leap we use “zypper up”.
Note also that we use “–no-recommends” as our ‘in development’ installer is based on openSUSE JeOS which employs this for package management to keep things small.
So when one is prompted for a Rockstor version update the following file is created, by the referenced code, and run via the system AT service, as we can’t change our own legs while running on them.
This info should really be written up in a technical wiki entry on our update system but at least we have it here now and it’s mostly only the indicated single python file anyway.
So as always room for improvement but at least we have this technical doc of sorts available now.
In the process of writing this reply I’ve done a 3.9.2-51 to 3.9.2-52 “uses openSUSE Leap …” update via Web-UI System - Software Update. And then, there after, a flashing wifi / RSS icon update of everything else. So @def_monk with regard to:
You could try the other way around as neither is preferred but both are required to maintain a system. This way we cater for those wanting to upgrade their installs but not the Rockstor package (ie testing channel with a dodgy looking update that can wait for a better time) and those wanting to update just their rockstor package. This separation is really useful and helps with maintaining a system. N.B. in the our “Uses openSUSE” variants we have yet to implement the autoupdates feature, for this see the caveat in the last pull request concerning this part of the code:
Caveats:
This pull request does not cover unattended updates for the openSUSE variants, but a TODO was added to the relevant code to indicate this lack of feature parity. It is proposed that this can be addressed in a focused issue of it’s own.
There was not found to be an equivalent, yet, of pending update per package change logs. However a potential fix for this may be in upstream. For now we inform the user of this unavailability and a code TODO has been added linking to the upstream feature addition to zypper.
To touch again on the rockstor listing in the all but rockstor updates option, I like it, but it could do with a ‘special case’ text against it indicating it relates to System-Software Update mechanism. That would at least explain to users why it persists when all the other package get installed. It helped in my case of a broken rockstor package system so I say we leave it that way but add the suggested text on this entry. That I think should address all concerns hopefully and give us a backup indicator and keep the code simpler.
Not that any changes to this code should be accompanied by unit tests as we really need this to work as good as we can get it as it supports the rest of our development for the less technical who are less inclined or able to drop to a terminal. This then makes our testing channel more accessible which, in time, can only be good. But for the time being it’s still pretty rough.
Hope that helps and apologies for not having already done a technical wiki on this part of the code, I find myself pulled in all sorts of directions, as I’m sure you both appreciate. But as stated this post is not far off such an entry now anyway, at least on the openSUSE side. For CentOS it’s esentially the same but uses Yum. Also note that we do still use some yum in our “Uses openSUSE” installs but it’s now dnf-yum, not the regular yum as that is now deprecated. And for a little while wasn’t even available in Tumbleweed.
I just finished updating mine in the other order (packages first, then rockstor). As described, after the packages finished, it actually still listed the rockstor package in the package menu, so it is working as expected. I went through the System -> Software Update afterward to update that, and had no issues.
.
