[openstack-dev] [TripleO] QuintupleO Update

Robert Collins robertc at robertcollins.net
Wed Oct 8 17:53:53 UTC 2014


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.

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.

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.

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

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list