[Proposal] New way to handle upstream updates

[flatspin (Ralf Jeckel)]

That’s right, but to be also a little philosophic:

If you reach a certain level, the effort to getting better grows exponentially and at some level it doesn’t make sense to invest more, because the investment doesn’t stand in any relation to the improvement.
The question now is: Are we allready at that level?

[medworthy (Mark Edworthy)]

@Stefano_Zamboni,
This is a large and diverse community (I use the term “diverse” in a broader meaning and not within the current limited politically correct / corporate speak definition).

Sure, you may not have time or the inclination to examine the wider issues related to this subject, but there are others that would like to see a more integrated approach to these related issues.

Remember, no man is an island, we are all part of a community with similar / overlapping aims and objectives.

[stephdl (Stéphane de Labrusse)]

@davidep

Yes, IIRC @stephdl added an option for it in his module for yum-cron

probablement à l’insu de mon plein gré (french joke)

More seriously, what this module needs more ?

[davidep (Davide Principi)]

@giacomo

We also proposed a couple of solutions.

1. (Short term) The administrator should be able to choose the upgrade policy of its own server: fast/slow

Today @giacomo and I were thinking about this solution and its feasibility. How to implement it?

We found two alternatives.

1. Software center banner

As upstream problems occurred with minor releases (7.3->7.4), we could display a banner in Software center page that explains what will happen if the system is updated. In other words, instead of the usual yellow “Updates available” banner, we could display a scaring red one: “System upgrade”.

This solution is an enhancement of the current policy. It does not implement the fast/slow policy but still leaves the responsibility of updating the system to the sysadmin.

It provides a better awareness of what’s going to happen (hopefully).

2. “Slow” policy mirror infrastructure

The fast/slow policy requires a set of additional mirrors to serve the “slow” updates. Whilst “fast” would rely on the upstream mirror infrastructure (as we’re doing by now), the “slow” must be implemented with our own servers.

This solution seems quite expensive because upstream mirrors are on a different order of size compared to our tiny NethServer repositories. Disk requirements (yum repolist -v) are the following

At minimum:

base, updates / 26 GB

But also sclo and extras should be mirrored for completeness:

base, updates, sclo, extras / 40 GB

Moreover, the less mirrors, the more bandwidth/load is required!

What do you think? Who’s available to host a such mirror? Isn’t the banner enough?

[alefattorini (Alessio Fattorini)]

@medworthy

When are we going to start using the above statement as our mantra / slogan?

Of course not

But please guys don’t go off-topic, we should focus on what we can do NOW with our repositories in order to fix the problem turned out at the conference, as @giacomo correctly explained.

[filippo_carletti]

I was pointed to Proxmox subscription plans and this thread came to mind. We could cover the slow updates repository costs with a paid subscriptions plan.
https://www.proxmox.com/en/proxmox-ve/pricing
Probably worth a new thread @alefattorini.

[davidep (Davide Principi)]

You make me think the two “alternatives” aren’t mutually exclusive.

We can implement both the banner and an alternative (slow/managed) updates channel!

[stephdl (Stéphane de Labrusse)]

@davidep

What do you think? Who’s available to host a such mirror? Isn’t the banner enough?

------------------------------------------------------------------------------------------------------------------------
   74,4 GiB  /smeserver                                                                                                                   
   60,8 GiB  /archlinux
    3,1 GiB     /nethserver
  733,3 MiB   /stephdl

actually the 4 repositories hosted on my mirror

[giacomo (Giacomo Sanchietti)]

While we can keep going the discussion on a possible paid subscription plan, I would like to have some firm points to proceed with next NethServer release.

If anyone agree, I’d go with:

1. Define a list of hot point to check before releasing minor release. Please add here: https://wiki.nethserver.org/doku.php?id=howto:qa_testing_hot_points (@quality_team, @iglqut)
2. Add the banner inside the Software Center to inform users about upgrade between minor releases (as suggested by @davidep)
3. Move @stephdl’s yum-cron package to the core, so anyone can enable automatic security updates (please bear in mind that a security update could also disable insecure feature causing incompatibilities usually with legacy clients)
4. Better document update policies as request by @medworthy (@docs_team would you like to create a new wiki page or adding directly it to the manual?)

[iglqut (Dr Thomas Quinton)]

@giacomo

would you like to create a new wiki page or adding directly it to the manual?)

I think it belongs to the manual- splitting up to much makes things more complicated, than they already are.

[m.traeumner (Michael Träumner)]

@filippo_carletti

We could cover the slow updates repository costs with a paid subscriptions plan.

I think this is the solution we allready have, a community version with fast updates and the enterprise with tested updates a little bit later.

[m.traeumner (Michael Träumner)]

@giacomo

Define a list of hot point to check before releasing minor release.

What do you think about checking modul function like squid, groupware and nextcloud? I think these are moduls which are used very often.

[davidep (Davide Principi)]

@davidep

1. Software center banner

Here’s a preview

Any hint?

[giacomo (Giacomo Sanchietti)]

@m.traeumner

What do you think about checking modul function like squid, groupware and nextcloud? I think these are moduls which are used very often.

I agree, could you add it to the linked wiki page?

@davidep

Any hint?

Excellent, this is a “go” for me

[m.traeumner (Michael Träumner)]

@giacomo

I agree, could you add it to the linked wiki page?

Of course. It’s added.

[giacomo (Giacomo Sanchietti)]

I think we are ready for releasing NS 7.4 final as all hot points have been tested.

Just documented the update policy as requested: please review! (/cc @docs_team @medworthy)

• http://docs.nethserver.org/en/latest/packages.html#software-updates (update policy)
• http://docs.nethserver.org/projects/nethserver-devel/en/latest/development_process.html#minor-release-from-upstream (hot points)

Last bit: would you like to have nethserver-yum-cron package inside the NethForge?
If yes, @stephdl has the last word and should move the GitHub repository under NethServer organization, then I will gladly publish the package in NethForge for 7.4.
But we have no rush, we can do it after the final release or leave everything as is: users will be free to join Stephane repo! (I like this one ;))

[mrmarkuz (Markus Neuberger)]

@giacomo

But we have no rush, we can do it after the final release or leave everything as is: users will be free to join Stephane repo! (I like this one )

I fully agree. Let’s talk about paid plans and community servers first.

[m.traeumner (Michael Träumner)]

@mrmarkuz

Let’s talk about paid plans and community servers first

“Paid plans”: I would leave as it is, you have an enterprise version with a subscription with phone support and checked updates and a community edition.
What I would change is to give paying customers more flexibility, for example they want to run a proxy server, a groupware server and a print server, why not paying for moduls they want to have supported. Also different support-level could be interesting, 7/24 for example.

“Community servers first”: My opinion is that this is a good model for everybody.
Nethesis has enough testers (the community) and peoples at the community get great help fixing their problems.

@giacomo

Last bit: would you like to have nethserver-yum-cron package inside the NethForge?

I think it’s a good idea to include it, for a nethserver beginner it’s not clear that there is a Stephane repo and how to get packages of it. Another way could be to insert Stephane repo to Software Center like the following picture illustrates. Of course we have to ask @stephdl if it’s ok for him.

[stephdl (Stéphane de Labrusse)]

@giacomo

Last bit: would you like to have nethserver-yum-cron package inside the NethForge?
If yes, @stephdl has the last word and should move the GitHub repository under NethServer organization, then I will gladly publish the package in NethForge for 7.4.

I would like to incorporate it at the core side , of course if some adjustments or big changes are needed, we can talk of it

@m.traeumner

I think it’s a good idea to include it, for a nethserver beginner it’s not clear that there is a Stephane repo and how to get packages of it.

I know it is a pity that my work is not known enough but you have google, sure that it can point in the right direction, maybe we can teach to people how to use it.

Of course I’m kidding

At this point I prefer to stay on my way with my repo, for some reasons.

I’m about to work part-time. Every ten years I need to change my job…I think the time is came. The maintenance/development of the stephdl repository (about 2500 IP per month) is about to be difficult with a full job beside. Maybe you did not see how the usage of NS is rising.

Therefore several options will come

• Open the stephdl repository to subscriptions (gpl code will stay on GH). This could be my next job.
• Take the free time to learn web development and look to be hired (actually I’m really busy on it)
• Ride my MTB and go to the mountains.

In any options I would be pleased to continue to code, this is something I started like a bet and I know I love it.

sorry to hijack this topic !