On 21/09/2022 08:47, Anoop C S wrote: > 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. >> >> (Follow-up on the thread started on #centos-ci irc channel) >> >> 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) > > With updated EC2 cloud image available(and deployed) for CentOS Stream > 8 where do we stand w.r.t this request? As far as our project is > considered we haven't seen any mentioned DNF/RPM issues in our jobs > since the update to recent EC2 cloud image for CentOS Stream 8 on metal > instances. > > > Regards, > Anoop C S. > No other feedback received so far, but if updates "delta" to be applied by cloud-init is now really small, that can explain why nobody is suffering from the dnf lock behaviour. I'd (personally) like to keep it like that : provisioned instance is updated with $latest pkgs in the background. If nobody minds with that plan, that means nothing to change for now :) PS : but that still means ensuring that we have more up2date base image for CentOS Stream 8 and 9 and then it's only a matter of a config change to push in git for us to point to new AMI -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xA25DBAFB17F3B7A1.asc Type: application/pgp-keys Size: 12767 bytes Desc: OpenPGP public key URL: <http://lists.centos.org/pipermail/ci-users/attachments/20220921/25c1a0a8/attachment-0002.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/ci-users/attachments/20220921/25c1a0a8/attachment-0002.sig>