On Tue, 2022-09-13 at 11:22 +0200, Fabian Arrotin wrote: > On 13/09/2022 10:07, Anoop C S wrote: > > > > Therefore I put forward a suggestion to disable `dnf update` as > > part of > > cloud-init service such that it does not interfere with other DNF > > operations done after the node is reserved by a tenant. > > > > Please feel free to correct me in any of the details mentioned > > above > > and let me know your thoughts. > > > > > > Thanks, > > Anoop C S. > > (Follow-up on the thread started on #centos-ci irc channel) > > As we initially wanted to hand over centos nodes that would be > "up2date" > wrt rpm packages, we indeed added the "dnf update -y" operation in > our > ansible deployments through the ec2 user data field, so that cloud- > init, > on ec2 init , would update automatically the machine. > If we have enough machines in the pool, it should be "transparent" > for > users but I see that tenants start to default to the metal instance > (and > clearly we already warned against it as tenants should start using > the > classic ec2 instances - large enough but different thread), so while > these ec2 nodes are entering the duffy pool, they are 'given' to > tenants > while cloud-init is still updating these. > > I don't mind disabling completely that "dnf update" step from our ec2 > config and so each project/tenant would start with such operation in > their ci/test workflow/pipeline > > Waiting for feedback from other tenants/projects and if so, it's just > a > git commit && git push operation at centos infra side and it will be > reflected for newly deployed ec2 nodes (for all, so not only bare- > metal > ones) I would like to hear from other tenants for any objections around the above suggestion. Many of our jobs performing `dnf update` or `dnf install` started failing in a more frequent manner which feels bad looking at their respective statuses. If I don't get to hear any objections my recommendation would be to disable `dnf update` from cloud-init on EC2 instances. Thanks, Anoop C S.