On Mon, 2022-11-28 at 08:39 +0100, Fabian Arrotin wrote:
On 28/11/2022 07:52, 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.
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.
As nobody said anything about it, I just pushed the change to remove the "dnf update -y" part from the cloud-init configuration. Ideally we'd let it there but if all tenants are starting themselves all their jobs with such dnf transaction, it's all good . Ideally we'd have refreshed centos 8s ami on regular basis and updating the ami id is just a git commit away for us (and Duffy then provisioning these new ones instead)
Thank you Fabian. I can confirm that our jobs are succeeding without any DNF errors.
Regards, Anoop C S.