Open Stack

On 26 July 2016 at 10:52, Sam Betts (sambetts) <sambetts at cisco.com> wrote:
> 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.

Ah, OK. I see why you want those to go to ironic.

I clearly need to go a re-read the plan we have for all that.

Thanks,
johnthetubaguy

>>
>>>>
>>>> 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
>
>
> __________________________________________________________________________
> 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