Re: [Xen-devel] [PATCH OSSTEST 2/4] Toolstack: Add OpenStack as a toolstack.

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Fri, Jul 17, 2015 at 04:58:16PM +0100, Ian Campbell wrote:
> On Thu, 2015-07-16 at 12:18 +0100, Anthony PERARD wrote:
> > Having a separate toolstack help to configure the host specificly for
> 
> "specifically"
> 
> > OpenStack, and also helps to have a separate flight.
> 
> Will any of the die()s here ever become real commands? I think not
> because that's not how OpenStack works? i.e. how it is driven doesn't
> fit into Osstest::Toolstack's model of the world at all.

The main issue would be create an instance from a config file. The
Toolstack.create() would need to parse the cfg, extract the image that we
want to boot, upload it to Glance, extract other parameter, update the
image in Glance, prepare a flavor (disk size, ram, ..) and boot that image
with that flavor via Nova.

I think that would be possible since everything can be done from the
command line but it would not be as easy as with libvirt.

Or not...
I've look at the doc to create a new image and it's basicly use libvirt to
install an OS, install cloud-init in it, and upload the result to Glance.

So, it's look like you're right, Osstest::Toolstack does not fit well with
OpenStack.

> Given that and given that you introduce your own recipe to sg-run-job
> which doesn't/can't/won't try to do any of the usual stuff, I can't see
> any reason not to simply go with toolstack=libvirt for these test cases.
> That it is the most accurate reflection of what we want and if some
> openstack test case did want to talk to the underlying toolstack for
> some reason libvirt would be it.

Ok, I'll just have to find another way to get more RAM into dom0.

> That would also save duplicating the functionality of libvirt.pm's new
> function, which would normally call for a subclass of some sort (e.g.
> how xend is a subclass of xl). Please don't do this though ;-)

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel