Interesting, it seems that I can now update the modules for the option is no longer grayed out.
However, when clicking the update option is see the installed and available versions are still the same. I hold off of actual updating until one of the devs has taken a look at this issue, for it’s a production server and I do not want to break it (If I haven’t already…)
I am now experiencing the same issue as LayLow. I had an update for Core to v3.0.0. After I updated Core to v3.0.0. I then saw 4 available updates, and they are greyed out. Likewise, I can not update.
OK. Well I add two repos to NS8 and now the Software Center now shows the 1 updates (nethvoice), and I am able to upgrade it. I don’t know if me adding the repos (Mrmarkuz repository and Stephdl repository) changed things somehow, or if Software Center reset somehow?
Please perform a “hard refresh” of the cluster-admin page in your browser. On supported browsers (Firefox, Chrome, Chromium), my preferred method is using the key sequence Ctrl + Shift + R, but other methods are also available.
I didn’t see any announcement for Core 3.0.0 in the forum and to be honest I’ve never seen one for any NS8 updates. I still see the occasional NS7 one here though.
All I see is a link for “Review and update”, which takes you to the Update with no details available:
Yes, the process is still manual. Nethbot will learn how to do it automatically, but nobody has taught it yet. So, for now, I’m still writing the announcements by hand while replying here.
Nice catch, Martin. This is by design. I’ll explain it in the release notes. In short, you can now update to a testing version only from an existing instance card. Check the three dots menu for that option.
The update action is displayed only when a testing version is available.
Can one revert back to production level?
Is the option to upgrade to esting version only available when a testing version indeed available?
How to tell what a testing version contains or differs from the production version?
i think there is alot of Grey area on this scenario, nad might not be possible.
How this could be possible would be if NS8 makea a backup snapshot of your instance right before update, then when we revert, we only restore what you had running before.
this however means any data you added after upgrade would not be present.
i think it could also be a good case for nay updates, and then maybe auto delete it after number of days.
I think this design is ok for ‘official repo’s’ and level 3 and up certified apps, but not for other repo’s and level 2 and down apps. Testing new versions of 3rd party apps becomes way much more difficult and requires cli skills, commands, outside GUI actions and thus mistakes,
I would opt for a seperation of official/certified apps fron default and nethforge repo’s but NOT for all other apps/repo’s. It would limit the ease of use and scare testers away if testing 3rd party apss is being made difficult (read cli).
Also being able to enable the testing repo provides the opportunity see be alterted and see if there are new testing versions available. By removing the testing repo, this possibility is gone.
I believe it would be fair if subscription based servers are a little more restricted to safeguard functionality and protect Nethesis commercial services, but not community driven and maintained servers.
So please put ‘restrictions’ on certified apps but uphold the freedom to test and see watever one wants. I believe I mentioned before that ‘overprotecting’ or ‘over regulating’ leads to limitations of freedom. A bit like what the EU is doing
( @alefattorini can this post be split off into a seperate topic please?)
i think how it is, we can leave it for enterpirse, or licensed servers.
but for community server, Just allow them to run and install from testing repo.
@LayLow you are correct, it makes testing harder, even for those with clie skills, since one of the reason we started publishing alpha apps, was so that its easy to install test, report issues, then we fix and push update
Our testing cycles do not ussually involve one app, but multiple at the same time, so by the time 4 hours windo has elapsed, and updates have been pushed to git, someone gets the fresh updates for testing.
We test ussually both fresh isntall and update cycle…
Not from the UI. Downgrading an app is a risky operation and should only be done in extreme cases.
Yes, of course. Maybe I’m not fully understanding the question.
Testing is a development stage, and testing releases are meant for QA team members. Usually, a list of test cases describes what to verify with the testing release to consider it VERIFIED. The differences between testing releases and production versions are ultimately reflected by code patches.
I think there’s a misunderstanding about what we consider “testing”. I refer to a formalized process, which is described here: Development process | NS8 dev manual. Meanwhile, I think you’re referring to trying out new applications from third-party repositories.
Both are valid. However, as mentioned before, I suggest labeling new/unstable/incomplete applications with an “Alpha/Beta” suffix (e.g., “Superapp (beta)”) during early releases to avoid confusion. Additionally, use the Semver pre-release tag for testing releases meant for upcoming stable versions. Once the app is considered stable, the suffix can be removed.
We have fewer than 1 testing versus over 1000 users running production servers. The cluster-admin UI is designed for sysadmins, not developers. For developers, consider that:
add-module ghcr.io/myrepo/myapp:mytag is a simple command to install a testing version.
Testing an upgrade can be done directly from the UI. In some rare cases a testing release contains an hotfix. In those rare cases a sysadmin may need to quickly install it from UI.
This is a situation where a few community members (deserving beers and love) want to try out a new application for the entire community.
In this case, to lower the barrier for setting up repositories on the developer’s side, I would simply document the usage of a command like:
add-module ghcr.io/devdude/superapp:1.0.0
If Devdude wants to set up their own repository, they’re free to do so and can provide a link to the repository configuration procedure, where to find the application “Superapp (Beta)” or “Superapp (Alpha)” version 1.0.0 ready to install.
Let’s take a look at some of the apps from @mrmarkuz like OnlyOffice, Zabbix, MeshCentral and Zammad. What is the exact status? (thinking out loud). They are many time confirmed to be working perfectly by community members, but no process has been started to get them in NethForge?
These apps are being used at production level, but lack the ‘proper’ status. Are these apps frozen in status because Markus did not apply? Are they out of sight of Nethesis because it is a 3rd party repo? Or is the importance of these apps or effectivity not recognised? Is it because somebody does not know what a ‘PR’ is? Or does not have a github account, but hosts it somewhere else where a PR does not help?
I don’t know, but I would like to see a clear and transaprent proces(ses).
AFAIK I need to add it to Nethforge. I had no time yet but I’m going to add it asap.
I think this is the process where my wanted NethForge app is checked by other devs and released when everything’s alright.