Re: State of new hardware and nesting

----- Original Message ----- > From: "Fabian Deutsch" <fabiand(a)redhat.com&gt; > To: "Eyal Edri" <eedri(a)redhat.com&gt; > Cc: infra(a)ovirt.org > Sent: Thursday, September 12, 2013 1:47:22 PM > Subject: Re: State of new hardware and nesting > > Hey Eyal, > > Am Donnerstag, den 12.09.2013, 06:22 -0400 schrieb Eyal Edri: > > Hardware is now setup, but might still be missing additional resources > > to spawn new vms. > > First - Nice that the new hardware is up! > > > So your code will create the vms it needs via restapi/sdk? > > Currently our code can use libvirt to spawn additional VMs (and remove > them afterwards) for testing. > We could also look if we add an Engine backend to our code so we can > directly speak to engine and spawn the VMs there. (But see below). > > As for the VMs: They are short-lived (~5min) and should be equipped with > ~2CPUs and ~2GB RAM. > We can also limit the number of concurrent VMs, e.g. we could limit it > to one VM at a time, so we don't exhaust all available resources. unfortunately, currently we can't allocate a bare-metal host solely for these tests we currently don't have any available (existing ones are used as hosts for all jenkins slaves). so the only option as i see it is using nested vm. we'll have to wait and see if it's working, then we'll be able to allocate on vm to you. (at least for testing at first) hopefully we'll know if it works by the end of the week

> > > nested vms might be ready soon, after a major bug was fixed on kernel, > > we currently test its functionality again and we'll update once(if) it's > > verified and working. > > That would be awesome! Is there a bug which tracking this I could > subscribe too? https://bugzilla.redhat.com/show_bug.cgi?id=902012 > (i) If nesting was possible I'd suggest that we run our own libvirt > instance inside our VM and use that libvirt instance to spawn the > additional VMs. > > (ii) If that's not possible I would look into adding a additional > backend to Igor which then can speak directly to Engine to spawn the > additional VMs. But note that this will imply that Igor will create a > new for and is uploading an ISO to Engine for each test run. That's > basically not a bad thing (tm) but a lot of interaction with Engine.\ i'm not sure i like the idea of a test/job in jenkins creating new vms on a production engine that runs the rest of jenkins slaves, sounds risky and might lead to problems. > > (i) is IMHO safer and more practical as it is self-contained. Surely the > nested VMs won't be to powerful, but that's okay. > But (ii) is also a way to go if nesting is not possible. > > fabian > > > ----- Original Message ----- > > > From: "Fabian Deutsch" <fabiand(a)redhat.com&gt; > > > To: infra(a)ovirt.org > > > Sent: Thursday, September 12, 2013 12:05:07 PM > > > Subject: State of new hardware and nesting > > > > > > Hey, > > > > > > to run functional tests with ovirt-node we still need a possibility to > > > spawn VMs. > > > The solution which got discussed a couple of weeks (months?) back was to > > > enable nesting to allow a setup like: > > > > > > Host > > > +-> Test Automation (Igor) VM > > > +-> Test Instance (spawned on demand by Igor) > > > +-> Test Instance (spawned on demand by Igor) > > > > > > Back then the new hardware wasn't setup and not ready. > > > My question is if the hardware is now setup? > > > And if it allow nesting? > > > > > > Greetings > > > fabian > > > > > > _______________________________________________ > > > Infra mailing list > > > Infra(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > >