State of new hardware and nesting

[Fabian Deutsch]

Am Sonntag, den 15.09.2013, 05:15 -0400 schrieb Eyal Edri:
> 
> ----- Original Message -----
> > From: "Fabian Deutsch" <fabiand at redhat.com>
> > To: "Eyal Edri" <eedri at redhat.com>
> > Cc: infra at 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

Okay. Nesting will be fine - if it works.
Please let me know if I can do anything to help.

I opened https://fedorahosted.org/ovirt/ticket/78 to track the issue.

Thanks
fabian


> > 
> > > 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 at redhat.com>
> > > > To: infra at 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 at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > > 
> > 
> > 
> >