#4200 Provisioning "rpm-ostree" on a physical server
Closed: Fixed None Opened 10 years ago by walters.

Hi,

So "rpm-ostree" does two major things now:

1) Commits RPM content to an OSTree repository, so clients can download it
2) Does automated server side testing using qemu

The issue is that #1 works perfectly fine inside a cloud environment. But for #2, we get into nested virt, and right now with the Fedora OpenStack, it's 100 times slower than running the code locally on my laptop in baremetal.

In order to do extremely fast testing, I really need baremetal. This is similar to what I have for gnome-continuous in the GNOME infrastructure.

It wouldn't have to be beefy hardware - even just 4 cores/16GB of ram would be enough to start.


I'm not sure we can easily help you here.

We have no machines with that few cpus/memory. Servers we get we use for virthosts, so they are running many instances on them. I guess we could see if there's one we are decomissioning that we could extend warentee on or something.

Also, see:

https://fedoraproject.org/wiki/Request_For_Resources

For the process for getting a new thing deployed in production. In particular, we want to know that there's more than a single person who knows how to debug/fix the item, that it's setup so we know where to report bugs, that it's maintainable over the long term, etc

Can you perhaps open a discussion on the infrastructure list?

What tests would this be running? How does it fit in with the qa folks taskotron? Perhaps taskotron could be made to use ostree?

Hi,

I don't need "production" hardware - rather something where I can collaborate with a few people and demo what I've done, and prove its value.

As for how it fits in with taskotron...well, this is a complex subject. rpm-ostree is perhaps closest to beaker - except it's also a deployment mechanism. Basically the model I am going for looks like this:

build -> deploy -> test -> more testing

Whereas traditional RPM goes like:

build -> rpm %check (may be slow) -> release as rpms -> maybe later provision a system and test it (very slow)

What I am aiming for honestly is quite disruptive - but also brings greater benefits.

Concretely, I can get the time for test-booting updated systemd RPMs down to minutes. This kind of speed and reliablity is very hard with the RPM model today - I'll need to make some optimizations there.
Without RPM improvements though, I can still be much faster than beaker.

So...should taskotron use rpm-ostree? Well...I need to be able to efficiently demo what I have, and that will help us evolve more closely together.

If I was able to request resources from Red Hat sufficient for a new physical server, would that help? If the project isn't successful, at worst you'd have a new physical server to use =)

A server would be useful, but after a lot of problems with Red Hat groups gifting us servers we couldn't use outside of the short term need of the project, we need to be able to select what it is [We have had several boxes that work great if they are underneaths an engineers desk or are in a lab you can go physically to.. but completely useless in a remote location.] Which then ends up being production hardware.

My apologies for being strict on this but our rack space is limited and ending up hardware which can't be useful outside of a limited occasion makes for a bad situation for everyone.

Makes sense, I had been assuming that the server would be ordered to spec. It'd actually be very useful for me if the server was similar in specifications to a virtualization host you currently use.

Sure, for a proof of concept one if you could get hardware we could probibly set it up in our QA network.

Can you work with smooge out of ticket on specs and such?

Budget was allocated but I'm not sure how soon it's going to happen. For now I'm just going to end up using an internal Fedora QA server inside the RH firewall, and then just rsync out the content to the the public instance.

Should I just reopen this ticket when the budget comes through?

Login to comment on this ticket.

Metadata