Open Stack

On 26/07/2016 09:32, "John Garbutt" <john at johngarbutt.com> wrote:

>On 22 July 2016 at 11:51, Vasyl Saienko <vsaienko at mirantis.com> wrote:
>> Kevin, thanks for reply,
>>
>> On Fri, Jul 22, 2016 at 11:50 AM, Kevin Benton <kevin at benton.pub> wrote:
>>>
>>> Hi,
>>>
>>> Once you solve the issue of getting the baremetal ports to transition
>>>to
>>> the ACTIVE state, a notification will automatically be emitted to Nova
>>>of
>>> 'network-vif-plugged' with the port ID. Will ironic not have access to
>>>that
>>> event via Nova?
>>>
>> To solve issues of getting the baremetal ports to transition to the
>>ACTIVE
>> state we should do the following:
>>
>> Use FLAT network instead of VXLAN for Ironic gate jobs [3].
>> On Nova side set vnic_type to baremetal for Ironic hypervisor [0].
>> On Neutron side, perform fake 'baremetal' port binding [2] in case of
>>FLAT
>> network.
>>
>> We need to receive direct notifications from Neutron to Ironic, because
>> Ironic creates ports in provisioning network by his own.
>> Nova doesn't know anything about provisioning ports.
>>
>>> If not, Ironic could develop a service plugin that just listens for
>>>port
>>> update events and relays them to Ironic.
>>>
>>
>> I already prepared PoC [4] to Neutron that allows to send notifications
>>to
>> Ironic on port_update event.
>>
>> Reference:
>> [0] https://review.openstack.org/339143
>> [1] https://review.openstack.org/339129
>> [3] https://review.openstack.org/340695
>> [4] https://review.openstack.org/345211
>
>I prefer Kevin's idea of Nova always getting the vif events.
>
>Can't the ironic virt driver can pass on the event to ironic, if required?
>
>In the libvirt case, for example, the virt driver waits to start the
>instance until the networking has been setup. It feels like we might
>need that in the Ironic case as well?
>
>Or is that likely to all end up too messy?
>
>Thanks,
>John

This is potentially possible for the nova user's network ports, but Ironic
creates its own neutron ports in the Ironic provisioning and cleaning
networks to perform provisioning and cleaning for a node. Nova is never
aware of these ports as they have nothing to do with the tenant¹s
requested connectivity.

Sam

>
>>>
>>> On Tue, Jul 12, 2016 at 4:07 AM, Vasyl Saienko <vsaienko at mirantis.com>
>>> wrote:
>>>>
>>>> Hello Community,
>>>>
>>>> I'm working to make Ironic be aware about  Neutron port state changes
>>>> [0].
>>>> The issue consists of two parts:
>>>>
>>>> Neutron ports for baremetal instances remain in DOWN state [1]. The
>>>>issue
>>>> occurs because there is no mechanism driver that binds ports. To
>>>>solve it we
>>>> need to create port with  vnic_type='baremetal' in Nova [2], and bind
>>>>in
>>>> Neutron. New mechanism driver that supports baremetal vnic_type is
>>>>needed
>>>> [3].
>>>>
>>>> Sync Neutron events with Ironic. According to Neutron architecture [4]
>>>> mechanism drivers work synchronously. When the port is bound by ml2
>>>> mechanism driver it becomes ACTIVE. While updating dhcp information
>>>>Neutron
>>>> uses dhcp agent, which is asynchronous call. I'm confused here, since
>>>>ACTIVE
>>>> port status doesn't mean that it operates (dhcp agent may fail to
>>>>setup
>>>> port). The issue was solved by [5]. So starting from [5] when ML2
>>>>uses new
>>>> port status update flow, port update is always asynchronous
>>>>operation. And
>>>> the most efficient way is to implement callback mechanism between
>>>>Neutron
>>>> and Ironic is like it's done for Neutron/Nova.
>>>>
>>>> Neutron/Nova/Ironic teams let me know your thoughts on this.
>>>>
>>>>
>>>> Reference:
>>>> [0] https://bugs.launchpad.net/ironic/+bug/1304673
>>>> [1] https://bugs.launchpad.net/neutron/+bug/1599836
>>>> [2] https://review.openstack.org/339143
>>>> [3] https://review.openstack.org/#/c/339129/
>>>> [4]
>>>> 
>>>>https://www.packtpub.com/sites/default/files/Article-Images/B04751_01.p
>>>>ng
>>>> [5]
>>>> 
>>>>https://github.com/openstack/neutron/commit/b672c26cb42ad3d9a17ed049b50
>>>>6b5622601e891
>>>>
>>>>
>>>> 
>>>>_______________________________________________________________________
>>>>___
>>>> 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
>>>>
>>>
>>>
>>> 
>>>________________________________________________________________________
>>>__
>>> 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
>>>
>>
>>
>> 
>>_________________________________________________________________________
>>_
>> 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
>>
>
>__________________________________________________________________________
>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