[openstack-dev] [ironic][nova][neutron][qa] Injecting code into grenade resource create phase

Sam Betts (sambetts) sambetts at cisco.com
Thu May 12 11:02:04 UTC 2016


Its easy enough to setup devstack today to use a flat neutron network
instead of faking it using the tenant networks which we don¹t support, I
do it in my third party CI for real hardware, if we can make it work for
fake BM VMs too would it solve this issue, or would grenade override that?

For reference these are the extra settings I have to add to make it work
for real hardware with no changes to the Ironic devstack plugin:

PUBLIC_INTERFACE={phys_interface}

Q_L3_ENABLED=False
Q_USE_PROVIDER_NETWORKING=True
OVS_PHYSICAL_BRIDGE=br-{phys_interface}
PHYSICAL_NETWORK=private # Because the ironic devstack plugin looks for a
network called "private"
PROVIDER_NETWORK_TYPE=³flat²

ENABLE_ISOLATED_METADATA=True


Sam Betts

On 12/05/2016 11:48, "Sean Dague" <sean at dague.net> wrote:

>On 05/11/2016 05:53 PM, Jim Rollenhagen wrote:
>> I've ran into a bit of a wedge working on ironic grenade tests.
>> 
>> In a normal dsvm run, the ironic setup taps the control plane into the
>> tenant network (as that's how it's currently intended to be deployed).
>> That code is here[0].
>> 
>> However, in a grenade run, during the resource create phase, a new
>> network is created. This happens in the neutron bits[1], and is used to
>> boot a server in the nova bits[2].
>> 
>> Since the control plane can't communicate with the machine on that
>> network, our ramdisk doesn't reach back to ironic after booting up, and
>> provisioning fails[3][4].
>> 
>> Curious if any grenade experts have thoughts on how we might be able to
>> set up that tap in between the neutron and nova resource creation.
>> 
>> One alternative I've considered is a method to have nova resource
>> creation not boot an instance, and replicate that functionality in the
>> ironic plugin, after we tap into that network.
>> 
>> I'm sure there's other alternatives here that I haven't thought of;
>> suggestions welcome. Thanks in advance. :)
>> 
>> // jim
>> 
>> [0] 
>>https://github.com/openstack/ironic/blob/95ff5badbdea0898d7877e6518939160
>>08561760/devstack/lib/ironic#L653
>> [1] 
>>https://github.com/openstack-dev/grenade/blob/fce63f40d21abea926d343e9cdd
>>d620e3f03684a/projects/50_neutron/resources.sh#L34
>> [2] 
>>https://github.com/openstack-dev/grenade/blob/fce63f40d21abea926d343e9cdd
>>d620e3f03684a/projects/60_nova/resources.sh#L79
>> [3] 
>>http://logs.openstack.org/65/311865/3/experimental/gate-grenade-dsvm-iron
>>ic/e635dec/logs/grenade.sh.txt.gz#_2016-05-10_18_10_03_648
>> [4] 
>>http://logs.openstack.org/65/311865/3/experimental/gate-grenade-dsvm-iron
>>ic/e635dec/logs/old/screen-ir-cond.txt.gz?level=WARNING
>
>Let me make sure I understand the crux of the issue: services may need
>to create additional custom networking in order for the rest of the
>resource flow to work correctly. Ironic definitely needs this because
>it's building up an interesting simulated network here for it's guests
>to live on.
>
>That feels like we need a new pre_create (or early_create) phase that
>ironic could hook into to do that same network create. I think the only
>question in my mind is whether neutrons network create here should move
>to early_create as well.
>
>Does ironic's ovs setup need to happen after the neutron create phase
>here, or does it just need to happen before nova?
>
>Does ironic need to overwrite the $net_id that gets passed to Nova later?
>
>	-Sean
>
>-- 
>Sean Dague
>http://dague.net
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list