On 10/08/2014 12:53 PM, Robert Collins wrote: > On 9 October 2014 06:26, Ben Nemec <openst...@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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
