On 26 July 2016 at 10:52, Sam Betts (sambetts) <sambe...@cisco.com> wrote: > On 26/07/2016 09:32, "John Garbutt" <j...@johngarbutt.com> wrote: > >>On 22 July 2016 at 11:51, Vasyl Saienko <vsaie...@mirantis.com> wrote: >>> Kevin, thanks for reply, >>> >>> On Fri, Jul 22, 2016 at 11:50 AM, Kevin Benton <ke...@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 <vsaie...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
