Open Stack

On 10/08/2014 12:53 PM, Robert Collins wrote:
> On 9 October 2014 06:26, Ben Nemec <openstack at nemebean.com> wrote:
>> So things have been pretty quiet on the QuintupleO front since the
>> mid-cycle, but I have finally had a chance to set up an environment to
>> do some experimentation with it.  I don't have anything ready for
>> primetime, but I was able to do an Ironic deploy of the undercloud image
>> from a devtest-built seed image, all in a modified Devstack install.
>> I've written up the details in a blog post:
>>
>> http://blog.nemebean.com/content/quintupleo-status-update
> 
> Cool.
> 
> +        if ((CONF.libvirt.virt_type == "qemu" or
> +             CONF.libvirt.virt_type == "kvm") and
> +             flavor.extra_specs.get('libvirt:pxe-first')):
> +            guest.os_boot_dev = ['network'] + guest.os_boot_dev
> 
> Might be better as:
>     ...CONF.libvirt.virt_type in ('qemu', 'kvm') ...
> in the short term. Medium term I think we want to be able to control
> that on a per instance basis.

Good point.  My excuse is that I copy-pasted that from somewhere else in
the driver. :-)

I'll have to double-check, but I think the general consensus in the Nova
discussions I've seen was that there should be a more generic "select
boot device" feature added to Nova.  I don't see a spec for it yet
though, so that's something I'll have to follow up on.

> 
> Ironic actually polls things till they worked, at least in the IPMI
> codepaths, so we should be able to do something there. However,
> Devananda was very concerned about having an openstack driver, but was
> ok with an IPMI->openstack proxy, which jang volunteered to write.

Yeah, this was just a quick port of my old nova-bm ssh driver to Ironic
so I could prove the concept works.  I included Jan in the To list in
the hopes that he'll chime in on this. :-)

> 
> The neutron one we need to be able to do on a per-port basis. I think
> its definitely one of the changes that needs Neutron design input -
> e.g. a spec there. Off the top of my head the acl logic will need to
> be something like (for dhcp answering)
>  - does the network permit tenant nodes to be dhcp servers
>  - if yes and this user owns the network permit them to control this setting
> 
> For spoofing something similar:
>  - does the network permit ports to be enabled for spoofing
>  - if yes and this user owns the network permit them to control this setting
> 
> Then we'll want to tunnel that setting via either heat (and specific
> port requests in the templates) or nova (and an attribute on the
> server request in heat).
> 
> At a minimum, to be able to deploy your patches to the tripleo-ci
> clouds, I think we'll need the attribute on the network object
> specifying whether this is permitted or not: we can then create
> dedicated networks per test run with that set, so even if v1 of the
> patches just turn it on for every port on such a network, we'd be set.

Okay, that's good to know.  I haven't looked too closely at what it
would take to make this more granular, but I believe there's similar
(same?) functionality needed for NFV in Neutron so I'm hoping maybe I
can piggy-back on that work.

So yeah, lots of follow-up to do before we can say this is complete, but
I think now I have a much better handle on exactly what we need to
happen to enable this.

> 
> Overall though, its fantatic you have something working. And I for one
> welcome OoOoO.
> 
> -Rob
>