also : https://www.centos.org/minutes/2021/September/centos-meeting.2021-09-15-14.10.log.html

Guessing from the the general Linux community sentiments on auto-updates, this will probably end up being a touchy subject. However, for how Stream operates I think this is a good discussion to have.

From a user perspective, I would be okay with an auto-update mechanism if the following two conditions were satisfied:

1) A preference toggle is clearly exposed at installation time for what update method to use (can default the selection to apply+notify), and
2) This only applies by default for interactive installations.

I could be wrong, but I would like to assume that admins authoring kickstart configs for non-interactive provisioning have a stronger update procedure than most. As such, the default value of some "updatepolicy" command should be to not apply updates automatically. I'd lean towards a default of notifying of available updates without downloading said updates over doing nothing. Having this be opt-in for more advanced users sounds like a better option to me.

Am I correct in assuming that we are effectively discussing the policy for RHEL9 here, as what is in Stream9 will end up in RHEL9?

If we move forward with this feature, this is one instance where CentOS Stream behavior may differ from RHEL behavior.

Hi Brian,

What would be the justification for the divergence in behaviour?

(In reply to Phil Perry from comment #6)
> Hi Brian,
> 
> What would be the justification for the divergence in behaviour?

The distribution model of the project vs. the product are significantly different.

CentOS Stream is a continuously delivered OS, with no point releases, with updates reflecting the development state of the next RHEL release flowing directly into a single set of repositories.

RHEL continues to have minor releases in 6mo intervals, with updates and bug fixes for those minor releases.  This is not modeled forward to CentOS Stream, and the development binaries of RHEL are conversely not delivered publicly as CentOS Stream provides that.  RHEL channels also require entitlement and subscription.  Further, Red Hat has other tooling and management products in place to help manage and update RHEL instances and long-standing recommended practices.

There is nothing preventing a RHEL customer from enabling dnf-automatic for their installations if that is the management and update strategy that their process and policies prefer.  However, it is highly unlikely that we will make that the default in RHEL.

In regards to the default in CentOS Stream, my personal preference would likely be to do the following:

1) An RFE to configure root notification during installation, having the option for a day 0 operation instead of day 1 configuration after the fact.
2) dnf-automatic defaulting to "notify"
3) An option to opt-into "apply+notify"

While I like the idea of helping CentOS Stream users be more aware of pending updates, I'd hesitate to apply those automatically out of the box.  The cases like kmod-nvidia (or other kmods) will cause issues for a not insignificant number of users.  Further, remediation of bugs introduced becomes harder for cases where an update causes a large impact, particularly if a whole fleet of installations is updated at once as opposed to a few canary updates, etc.

I do like Mike's twist of having this be contingent on interactive installations if we pursue anything.

I think this is a good idea -- not just notification but apply by default.

I don't think interactive vs. kickstart is a good way to distinguish. There are _plenty_ of kickstart installed systems which would also benefit. And, arguably, the cases identified where there might be problems (kmod-nvidia, say) are _more_ likely to be interactive (single-system desktop) installs.

I think it'd be better to have the default be to set to automatically update, but clearly document a kickstart command to change that. Admins going through building their EL 9 kickstarts will be going through the documentation in doing so, I hope. (And those who don't.... well, automatic updates seems like an _especially_ good choice.)

What about starting with the default of notification but no updates, and at the same time propose a feature in Fedora Server to enable _applying_ updates, with the kickstart command to adjust? Then, after baking in Fedora for a little bit and time to digest and document for CentOS stream, automatic updates could become the default there too.

(Incremental progress towards the somewhat better, times time, is how big change really happens!)

I am highly concerned about community blowback if we default to automatically applying updates.  A popular critical narrative is that the goal of the Stream changes are to convert CentOS users into RHEL beta testers.  This is of course false, but this change would fit far too easily into that narrative.

"First you took away my point releases, now you're defaulting me to automatic updates?"

I am in favor of giving users installer and kickstart options to opt-in to automatic updates.  As Matthew pointed out, these should go to Fedora first and be given time to mature, before being brought to CentOS Stream.

The thoughts from Matt (https://bugzilla.redhat.com/show_bug.cgi?id=2004572#c8) sound good to me :)

Looks like 'notify only' didn't make it for the Stream9 announcement today.  How can I help this move forward?

It doesn't look like I've got the relevant rights to submit this as a change proposal for Fedora 36...

I'm trying to use Centos 9 Stream on my Laptop. I figured it'd be a way for me to get familiar with what's coming on the RHEL servers I support.

But I'm running into stability issues, and the majority of the ones I encounter involve failures of dnf due to broken or incompatible versions of things being dependencies for different packages. This is made much worse by the Windows-Style go-away-I'm-busy-updating-your-computer automatic execution of dnf.

Today it hung on shutdown, and after about 20 min I had to power-cycle the machine, and was fortunate to have it come up. It's become unbootable after I did that at least once before.

Maybe Centos 9 Stream is just too unstable for it to be my work laptop OS, or maybe not. But my experience is that the more-or-less rolling update process is sending out too many updates with installation issues for any kind of automatic update process to be a good idea.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.