Re: [openstack-dev] [TripleO] QuintupleO Update
On Wed, Oct 8, 2014 at 12:07 PM, Ben Nemec wrote: > On 10/08/2014 12:53 PM, Robert Collins wrote: >> 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. :-) To recap what Jan and I talked about for a wider audience... An ipmi-listener that translates to other things (openstack, libvirt, or what ever) would be very useful for testing the contracts that Ironic makes with hardware, and also ensuring that our functional tests are actually testing all of the same code paths we use in production (which they're not today, because no one should be using the SSH power driver in production). Once we have such an ipmi-listener, I think we could (and should) remove the SSH power driver from Ironic. -Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] QuintupleO Update
On 10/08/2014 12:53 PM, Robert Collins wrote:
> On 9 October 2014 06:26, Ben Nemec 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
Re: [openstack-dev] [TripleO] QuintupleO Update
On 9 October 2014 06:26, Ben Nemec 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
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] QuintupleO Update
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 It's a bit long, so as a tldr here's the summary of the status from the end of the post: "With these changes it would theoretically be possible to use QuintupleO for the TripleO CI environment. The biggest issue I'm aware of would be the fact that the Ironic code in the images would not be OpenStack-aware, so we would need to cherry-pick my changes in every image build. That's something we typically prefer to avoid, so I think a final version of the Ironic OpenStack driver should be the top priority right now. The other changes could be applied to a CI OpenStack installation and largely left alone without affecting any of our testing. Long-term, of course, we want to get all of this functionality enabled in the respective projects by default. That will need to happen before TripleO development in a public OpenStack cloud can happen. And that's pretty much the state of QuintupleO from my perspective. I would love to have some more discussions about short and long-term plans for this either in Paris or before, if possible." Any comments or questions, you know where I idle in IRC. :-) -Ben ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
