Hello!

I understand that the metal machines are expensive, and I'm not sure how many other projects are eventually going to migrate over to them, but I guess in the future some balance will need to be found out between the cost and available metal nodes. Is this even up to a discussion, or the size of the metal pools is given and can't/won't be adjusted?

We're looking to optimize resource usage with the recent changes to CentOS CI. From our side, the goal is to find a balance between adjusting to tenants' needs (there are adaptations we could do to have more nodes available with an increase in resource consumption) and adjusting projects workflows to use EC2.

I'd appreciate your suggestions on mitigating how to make workflows more adaptable to EC2.

Also, how much is this impacting critical deliveries on your side at the moment? My goal here is to understand whether we need a more urgent solution for you before going for deeper discussions. As I understand, we still have some bandwidth to find the best solution we can, as it could become more critical in the future. Is that assumption correct?

Thank you for reaching out about this,

On Fri, Aug 19, 2022 at 8:35 AM Evgeni Golov <evgeni@redhat.com> wrote:

Moin,

On Fri, Aug 19, 2022 at 1:21 PM František Šumšal <frantisek@sumsal.cz> wrote:

> After a couple of weeks of back and forth with the always helpful infra team I was able to migrate most of our (systemd) jobs over to the EC2 machines. As we require at least an access to KVM (and the EC2 VMs, unfortunately, don't support nested virt), I had to resort to metal machines over the "plain" VMs.

We (foreman) are in the same boat, our tests spawn multiple VMs, so we
require KVM access (metal or nested, with the latter sadly not
supported by EC2)

> After monitoring the situation for a couple of days I noticed an issue[0] which might bite us in the future if/when other projects migrate over to the metal machines as well (since several of them require at least KVM too) - Duffy currently provisions only one metal machine at a time, and returns an API error for all other API requests for the same pool in the meantime:
>
> can't reserve nodes: quantity=1 pool='metal-ec2-c5n-centos-8s-x86_64'
>
> As the provisioning takes a bit, this delay might stack up quite noticeably. For example, after firing up 10 jobs (current project quota) at once, all for the metal pool, the last one got the machine after ~30 minutes - and that's only one project. If/when other projects migrate over to the metal machines as well, this might get quickly out of hand.

Our tests run up to 8 parallel jobs, so yeah, I can totally see this
being a problem in the longer term for everybody.

We're currently investigating whether we can change our scheduling and
run multiple jobs on one metal host (it's big enough to host more than
the 3 VMs one job needs), but it doesn't seem too trivial right now.

Evgeni

--
Beste Grüße/Kind regards,

Evgeni Golov
Senior Software Engineer
________________________________________________________________________
Red Hat GmbH, https://de.redhat.com/, Registered seat: Werner von
Siemens Ring 14, D-85630 Grasbrunn, Germany
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

_______________________________________________
CI-users mailing list
CI-users@centos.org
https://lists.centos.org/mailman/listinfo/ci-users