Re: Using oVirt VM pools in oVirt infra

Foreman was designed with a flow of learning about existing servers from the puppet reports they generate, this flow is so baked in to foreman it often breaks other flows where foreman is the one creating the hosts (indeed some of our issues with it are due to that). Given that, I would`nt want to go and invent our own Foreman registration flow. Also, keep i mind that Foreman was designed as a tool for _manual_ host classification, because Puppet opened the window for creating such tools by supporting ENCs (Indeed the good old Puppet dashboard, and Puppet Enterprise essentially do the same thing with hostgroups and all). For _automatic_ classification Puppet already has very good and reliable capabilities. There is nothing about slaves pools that prevents you from either using a vanilla template or a baked one. Having said that, I'm under the opinion that any configuration we do except enabling Jenkins to connect and us to manage and monitor it, is a change to the slave that may mask out deployment issues that real users will experience. I think we need to narrow down the configuration to the point that its runtime will be trivial. Also, slave creation time is important only if you have to make your tests wait for it. If we can make things so the slaves will become available to Jenkins only after all needed configuration was done, then ho long it takes becomes far less important. It seems that OpenStack had made people used to the style of thinking where you crate VMs and bring them up on the Fly, and then creation time is very important. But we are oVirt, we can think differently. Given a fixed pool of hardware resources, a fixed pool of VMs that are up and ready is a viable option. And in practice it will mean service time for the jobs will be faster. -- Barak Korren bkorren(a)redhat.com RHEV-CI Team