On Wed, 2022-09-21 at 11:42 +0200, Fabian Arrotin wrote:
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.
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.
Fair enough.
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
Correct. What would be an ideal time period to get the base image updated? Quarterly? Or even monthly?
Thanks, Anoop C S.