In Fedora CoreOS we're currently running our build pipeline for x86_64 in the OpenShift instance. There is no aarch64 OpenShift instance so we need to run our builds elsewhere. The most simple approach that we've come up with is to run them via podman so the machine would need podman and minimally /dev/kvm access.
podman
/dev/kvm
We could request nodes using duffy but we'd really like to operate on top of a Fedora (or Fedora CoreOS in the future) base. Is it possible to grab Fedora machines using duffy?
duffy
Do you have a recommended path forward for us to acquire and use hardware for this purpose?
hi @dustymabe , if that's Fedora CoreOS and that you need to build on top of Fedora (that we don't provide in the CentOS infra) , was wondering if it would make sense to ask in fedora-infrastructure about having aarch64 access there ?
@arrfab - indeed it could make sense to do that, but we'll be transferring a lot of data back and forth between this node and the openshift instance in CentOS Ci. Would it be best to keep it local to CentOS CI in that case?
Metadata Update from @arrfab: - Issue priority set to: Waiting on External (was: Needs Review) - Issue tagged with: need-more-info
@lgriffin, @cverna : this ticket was tagged as "Need more info" during stand-up as it's not clear. CentOS CI infra wasn't supposed to be used to build official pkgs/artifacts, but more to run validation tests from pkgs built on https://cbs.centos.org (so CentOS SIGs) What do we want to do with such requests ?
CentOS CI infra wasn't supposed to be used to build official pkgs/artifacts, but more to run validation tests from pkgs built on
What does that mean in concrete terms ? Are there risks associated into building articfacts on that infra ? Currently x86 FCOS is built on CentOS CI infra so it would be good to know.
The risk is the same as any of the CPE remit, it's best effort. So our recommendation to any team is to not base mission critical tasks there and have it as a compliment. If that system has down time and we have other priorities it will stay down kind of thing.
If a team wishes to still proceed and we have the hardware and capacity to take them on then I'm ok with that
@dustymabe , @cverna : as @lgriffin said, the infra on which CI is actually running has no SLA/SLE (and see the recent issue with now all openshift storage running on very low entry-level sata storage, with no warranty anymore . So if that works for you, we can proceed .. :) Actually we only deploy bare-metal CentOS 7/8/8-stream on x86_64. For aarch64 and Power, as we're really low on resources (and again, nothing mission critical and no warranty anymore), we only provide Virtual Machines. @siddharthvipul1 is working on #4 to let CI tenants ask Cloud images, so WIP. As you need /dev/kvm access, I don't know if a VM would fit your needs though.
When you mentioned "acquire hardware", had you in mind you buying a aarch64 node that we'd host for you next to our openshift cluster (same rack[s]) but dediced to Fedora CoreOS usage ? (so bare-metal). In the mean time we can already have a VM, the same way you can ask for a bare-metal node (see https://wiki.centos.org/QaWiki/CI/Multiarch but @siddharthvipul1 had to correct the flavors as we lost some nodes so we have less resources available so only one flavor iirc)
Metadata Update from @arrfab: - Issue assigned to arrfab
@dustymabe : this morning I had a quick chat with @cverna about this and I tried the nested-virt option, in case you'd be able to consume a aarch64 VM and run your operation from inside a VM. But I'm afraid that it wouldn't work for you. Can you confirm that it wouldn't work from a VM ? IF so, the only option would indeed for you to bring a aarch64 bare-metal host that we can install/manage in the CentOS CI infra. Worth also seeing with eventually @kevin if they have a spare lenovo/ampere box that can be shipped to RDU2c ?
Nested virt should be fine assuming the performance wasn't horrible. I think we have plans to get everyone together soon and try to come up with the best path forward.
per email thread, closing as duplicate of https://pagure.io/fedora-infrastructure/issue/8370
Metadata Update from @arrfab: - Issue close_status updated to: Duplicate - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.