On Tue, Jun 08, 2021 at 09:36:37AM -0400, Cleber Rosa Junior wrote: > On Tue, Jun 8, 2021 at 2:30 AM Philippe Mathieu-Daudé > wrote: Here are my thoughts. It's just my opinion based on experience running the old QEMU Buildbot infrastructure and interacting with our hosting providers. I'm not planning to actively work on the CI infrastructure, so if you have a strong opinion and want to do things differently yourself, feel free. > > Who has access to what and should do what (setup)? How is this list of > > hw managed btw? Should there be some public visibility (i.e. Wiki)? > > > > These are good questions, and I believe Alex can answer them about those > two machines. Even though I hooked them up to GitLab, AFAICT he is the > ultimate admin (maybe Peter too?). > > About hardware management, it has been suggested to use either the Wiki or > a MAINTAINERS entry. This is still unresolved and feedback would be > appreciated. For me to propose a MAINTAINERS entry, say, on a v7, I'd need > the information on who is managing them. Here is the wiki page that lists project resources (machines, etc): https://wiki.qemu.org/AdminContacts We can continue to use this page. > > Is there a document explaining what are the steps to follow for an > > entity to donate / sponsor hardware? Where would it be stored, should > > this hw be shipped somewhere? What documentation should be provided for > > its system administration? A document is needed that explains the process and the roles/responsibilities of the people involved. QEMU doesn't have a physical presence and we currently don't have a way to host physical machines. We also probably shouldn't get involved in that because it has a high overhead and puts the responsibility on the project to maintain the hardware. There are hosting providers like OSUOSL that offer non-x86 architectures, so I don't think we need to deal with physical hardware even for other architectures. If someone needs their special hardware covered, let them act as the sponsor and sysadmin for that machine - they'll need to figure out where to host it. > > In case an entity manages hosting and maintenance, can the QEMU project > > share the power bill? Up to which amount? > > Similar question if a sysadmin has to be paid. No, it's too complicated. QEMU does not have regular income that could be used for periodic expenses. We shouldn't spend time worrying about this unless there is a real need and plenty of funding. > > If the QEMU project can't spend money on CI, what is expected from > > resource donators? Simply hardware + power (electricity) + network > > traffic? Also sysadmining and monitoring? Do we expect some kind of > > reliability on the data stored here or can we assume disposable / > > transient runners? Sponsors provide access to internet-connected machines. They can designate a QEMU community volunteer to admin machines or they can admin the machine themselves. Sysadmins deal with keeping the machine online (security, network traffic, monitoring, etc). For simplicity it's best if sponsored machines are owned and paid for by the sponsor. Billing electricity, bandwidth, etc to QEMU will make things complicated and we don't have the admin infrastructure to support that. > > Should donators also provide storage? Do we have a minimum storage > > requirement? Sponsors provide storage. There is a minimum storage requirement that depends on the nature of CI jobs (I don't know what the exact amount is and it may change over time). > > Where is defined what belong to the project, who is responsible, who can > > request access to this hardware, what resource can be used? Machines belong to their sponsors, not to the QEMU project. They could go away in the future if the sponsor decides to withdraw them. Only the sysadmin has ssh access to the machine. The CI system provides access to logs so that ssh access to machines is not necessary for QEMU developers. If ssh access is needed then the developer can ask the sysadmin for help. Regarding resource usage, that's up to the sysadmin. If they want to apply resource limits to the CI environment they need to configure that. Stefan