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