Hi all CI tenants,
We got today a request to provide more powerful aarch64 ec2 instances for duffy (https://pagure.io/centos-infra/issue/1576) While I don't see a problem doing that, there are two ways to implement this : - either just change the ec2 instance type from c6g.2xlarge to c6g.4xlarge or c6g.8xlarge and then let the pool being drained and reprovisioned automatically with newer instance type (no change in current workflow) - or have a new duffy pool with limited number of provisioned instances and using these more powerful ec2 instances. (so tenants willing to use these ones would need to query a different pool name)
From a usage perspective, and fact that machines are pre-provisioned, I'd like to implement option 2, so that nothing would impact the actual pool and then propose another pool name for these other aarch64 machines (both for c9s and c10s). While AWS is sponsoring that infra, I'd like to keep "costs" at reasonable level, and so not deploying for all machines that would have an impact on "virtual budget" while tenants wouldn't even use the added vcpus/memory.
Ideas, opinions, thoughts ?
On 13/01/2025 16:20, Fabian Arrotin wrote:
Hi all CI tenants,
We got today a request to provide more powerful aarch64 ec2 instances for duffy (https://pagure.io/centos-infra/issue/1576) While I don't see a problem doing that, there are two ways to implement this : - either just change the ec2 instance type from c6g.2xlarge to c6g.4xlarge or c6g.8xlarge and then let the pool being drained and reprovisioned automatically with newer instance type (no change in current workflow)
- or have a new duffy pool with limited number of provisioned instances
and using these more powerful ec2 instances. (so tenants willing to use these ones would need to query a different pool name)
From a usage perspective, and fact that machines are pre-provisioned, I'd like to implement option 2, so that nothing would impact the actual pool and then propose another pool name for these other aarch64 machines (both for c9s and c10s). While AWS is sponsoring that infra, I'd like to keep "costs" at reasonable level, and so not deploying for all machines that would have an impact on "virtual budget" while tenants wouldn't even use the added vcpus/memory.
Ideas, opinions, thoughts ?
Not a lot of momentum but I had a quick look at Duffy usage (through zabbix stats) and it seems that aarch64 isn't as used as x86_64. For the last month, we only had a peak of 8 deployed ec2 instances (c9s) but average usage is pretty low. So I think that we can just go with the option 1, and that would be transparent for all tenants, and also satisfying the automotive SIG request (from ticket above).
I'll implement the needed change this week and I'll update both ticket and this thread
On 14/01/2025 15:51, Fabian Arrotin wrote:
On 13/01/2025 16:20, Fabian Arrotin wrote:
Hi all CI tenants,
We got today a request to provide more powerful aarch64 ec2 instances for duffy (https://pagure.io/centos-infra/issue/1576) While I don't see a problem doing that, there are two ways to implement this : - either just change the ec2 instance type from c6g.2xlarge to c6g.4xlarge or c6g.8xlarge and then let the pool being drained and reprovisioned automatically with newer instance type (no change in current workflow)
- or have a new duffy pool with limited number of provisioned
instances and using these more powerful ec2 instances. (so tenants willing to use these ones would need to query a different pool name)
From a usage perspective, and fact that machines are pre-provisioned, I'd like to implement option 2, so that nothing would impact the actual pool and then propose another pool name for these other aarch64 machines (both for c9s and c10s). While AWS is sponsoring that infra, I'd like to keep "costs" at reasonable level, and so not deploying for all machines that would have an impact on "virtual budget" while tenants wouldn't even use the added vcpus/memory.
Ideas, opinions, thoughts ?
Not a lot of momentum but I had a quick look at Duffy usage (through zabbix stats) and it seems that aarch64 isn't as used as x86_64. For the last month, we only had a peak of 8 deployed ec2 instances (c9s) but average usage is pretty low. So I think that we can just go with the option 1, and that would be transparent for all tenants, and also satisfying the automotive SIG request (from ticket above).
I'll implement the needed change this week and I'll update both ticket and this thread
Updated it today and returned ec2 instances for aarch64 are now :
"data": { "provision": { "ec2_instance_type": "c6g.4xlarge",
}, "nodes_spec": { "quantity": 1, "pool": "virt-ec2-c6g-centos-9s-aarch64" }
-
Fabian Arrotin