16:00:41 <Sukhdev> #startmeeting ironic_neutron
16:00:41 <openstack> Meeting started Mon Apr 11 16:00:41 2016 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:45 <openstack> The meeting name has been set to 'ironic_neutron'
16:01:05 <Sukhdev> #topic: Agenda
16:01:11 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_April_11.2C_2016
16:01:23 <Sukhdev> #topic: Announcements
16:01:43 <Sukhdev> Folks Mitaka is out and Newton is open for business
16:02:02 <Sukhdev> We have one more meeting before we all head out to summit
16:02:11 <jroll> morning
16:02:15 <sambetts> o/
16:02:18 <Sukhdev> jroll : GM
16:02:44 <Sukhdev> we discussed about 4 patches last week
16:03:04 <Sukhdev> I reviewed them over the weekend - they look good
16:03:30 <Sukhdev> any chance we can get them some core love and get them merged within April?
16:04:11 <Sukhdev> devananda : you have been busy testing them as well - any thoughts?
16:04:32 <devananda> Sukhdev: I've found a few issues with the network driver patch, and posted comments last week
16:04:41 <devananda> I see there are new patches up, which I need to retest this week
16:05:12 <Sukhdev> devananda: I will try to give them a spin as well
16:06:12 <devananda> as far as the hardware tests I've been doing - the environment is up but some kinks are still being worked out with our deployment. I'm hoping by EOW, and no later than the summit, we'll have some significant testing done against it
16:06:55 <Sukhdev> devananda : that will really nice
16:07:15 <Sukhdev> devananda: are you testing with OVN?
16:08:37 <Sukhdev> anybody else is testing these patches as well?
16:09:17 * sambetts hasn't had a chance to rebase his out of driver driver since the network interface to driver change
16:09:32 <sambetts> out of tree
16:10:19 <devananda> Sukhdev: yes, with OVN
16:10:24 <Sukhdev> sambetts : I am also in the same dilemma - my setup is running 2-3 weeks old pathes
16:11:04 <Sukhdev> devananda : cool - so, the neutron-ironic interface is working just fine for you
16:11:58 <Sukhdev> sambetts : I am thinking about updating my setup with latest patches
16:12:13 <devananda> unsure - we were at that point in the build last week, and I haven't sync with the team yet today
16:12:46 * jroll bbiaf
16:13:09 <Sukhdev> devananda: ah I see - if you need any help, feel free to ping me
16:13:21 <sambetts> I think its in a fairly stable state now, its probably at a point where I can confidently rebase my interface and not have to worry about having to drastically change it again
16:13:55 <vdrok> yep, updates during the last 2 weeks were mostly  unittests
16:13:55 <Sukhdev> :-)
16:14:14 <devananda> sambetts: well, there's one major issue in it
16:14:42 <devananda> I left feedback on p31
16:15:00 <devananda> * on review 285852 patch 31
16:15:15 * Sukhdev looking
16:15:20 <devananda> two issues:
16:15:39 <devananda> - network drivers are loaded at instantiation of the Node object, but should be loaded when the Conductor starts
16:15:59 <devananda> - upgrade path requires a CONF change, and not doing so breaks ironic-conductor silently
16:17:00 <sambetts> First issue solved by ensuring that enabled_network_drivers is processed at conductor start
16:17:05 <sambetts> right?
16:17:44 <devananda> yes, except the new interface isn't loaded there
16:17:50 <devananda> so it may take some refactoring - -I'm not sure
16:17:54 <sambetts> second by having a check in the init for the network drivers if cleaning is enabled: ensure conf is there
16:19:25 <devananda> if enabled_network_drivers were instantiated within CondctorManager.__init__, that would address the first one
16:19:44 <devananda> it would also cause the second one to result in an error message and Condcutor's refusal to start today
16:19:52 <devananda> which would be better than a silent failure, but also, I htink the wrong solution
16:20:08 <devananda> I'd like to ask -- do we actually need to define the cleaning_network_uuid for the FlatNetworkDriver ?
16:21:07 <sambetts> devananda: https://review.openstack.org/#/c/285852/36/ironic/drivers/modules/network/flat.py its needed for add_cleaning_network
16:21:16 <Sukhdev> devananda : hasn't this been the case before?
16:21:20 <devananda> as this patch stands, it adds a new requirement to Ironic -- all deployments must set a Neutron Network UUID
16:21:30 <devananda> even if they do not have Neutron in the environment
16:21:37 <devananda> because flat networks worked just fine without Neutron before
16:21:42 <devananda> ie, in the case of a stand-alone ironic
16:21:44 <jroll> devananda: we do, that's a thing today
16:21:46 <devananda> or a private single-tenant cloud
16:21:48 <jroll> afaik
16:21:49 <devananda> jroll: no, it's not
16:22:02 <jroll> how are cleaning ports created then?
16:22:04 <vdrok> devananda: yep, before it was required only when neutron dhcp is used and cleaning is enabled
16:22:11 <jroll> right, that
16:22:12 <devananda> vdrok: exactly
16:22:15 <vdrok> s/before/now
16:22:33 <devananda> so if I'm using bifrost (with no neutron) I don't need to set this
16:22:43 <jroll> so yeah, I guess it might need a refactor so that only happens if neutron dhcp is in use
16:22:44 <devananda> after this patch, I have to pass in a fake UUID for this variable
16:22:52 <devananda> s/variable/CONF option/
16:23:00 <sambetts> we just need an if statement in https://review.openstack.org/#/c/285852/36/ironic/drivers/modules/network/flat.py L36 that checks if cleaning enabled right?
16:23:03 <jroll> nod
16:23:10 <devananda> cool
16:23:31 <jroll> sambetts: well, it should be able to work without that config, if noop dhcp provider is used
16:23:38 <jroll> "it" being cleaning
16:23:57 <jroll> clint was also requesting that the config accept a name
16:24:06 <jroll> but idk if he put that in the review
16:24:11 <sambetts> while we're hacking adding the cleaning network via the dhcp provider
16:24:49 <sambetts> once that is deprecated and we're calling the network provider for cleaning networks directly then is cleaning enabled is your only flag for disabling it right?
16:25:00 <vdrok> jroll: he did not, and idk if it's worth adding this too right now, lots of stuff there already, we could change it later if needed
16:25:17 <jroll> vdrok: sure
16:25:32 <jroll> sambetts: well, it actually depends on the dhcp provider really :/
16:25:52 <jroll> maybe we shouldn't be moving that, hrm
16:26:10 <sambetts> personally I think that the dhcp should be moved inside the network driver
16:26:15 <jroll> or perhaps we need to fold dhcp provider things... yeah
16:26:33 <jroll> I feel like we can do that after all of these things, with the one catch being this config
16:27:11 <vdrok> the easiest thing would be to meove the cleaning net check inside cleaning methods instead of init right?
16:27:43 <devananda> vdrok: or into the conductor's __init__ ?
16:27:53 <sambetts> but then it fails during runtime and I'd love to have it just blow up the conductor at the start if i've got an invalid config
16:28:19 <Sukhdev> sambetts +1
16:28:25 <devananda> sambetts: yes
16:28:40 <devananda> DriverLoadError will only abort the conductor if raised during __init__
16:29:05 <devananda> so if we don't check this during conductor init, it will just get logged over and over again (which is what I'm seeing right now)
16:29:07 <sambetts> having an if CONF.cleaning_enabled in the FlatProviders init would allow it to work if they are using the Ironic config correctly
16:29:43 <devananda> sambetts: IFF we also instantiated FlatNetworkProvider during ConductorManager.__init__ -- which we don't today
16:29:43 <sambetts> (I'm assuming that these drivers will be loaded at conductor load)
16:29:49 <devananda> :)
16:29:53 <sambetts> which I really want them to be
16:30:00 <devananda> ++
16:30:02 <jroll> fwiw, I'm surprised the drivers aren't loading at conductor init, they look like they should be already
16:30:26 <vdrok> driver_factory.NetworkInterfaceFactory() in init_host?
16:30:43 <jroll> ^ yeah, that's what's needed
16:31:00 <jroll> ah, that isn't done today
16:31:02 <jroll> my mistake
16:32:55 <Sukhdev> it seems like simple fix, but, will require good amount of testing -
16:35:15 <Sukhdev> Anything else on this patch?
16:35:21 <devananda> Sukhdev: that's it for me
16:36:09 <Sukhdev> devananda : thanks for articulating the issue - when I saw the comments on p35, I thought your issue was addressed
16:36:39 <Sukhdev> #topic: VLAN aware servers
16:36:58 <Sukhdev> We discussed this last week, and I followed up in Neutron
16:37:07 <Sukhdev> thought I give a quick update
16:37:30 <Sukhdev> So, OVN has this implemented
16:37:55 <Sukhdev> the author who was looking for OVS got pulled into something else
16:38:12 <Sukhdev> hence, it has not been getting much attention in the neutron side -
16:38:28 <Sukhdev> but, last week I raised the priority because of Ironic need
16:39:02 <Sukhdev> We are looking into separating out the OVS implementation from the API -
16:39:28 <Sukhdev> this means, the basic core API will be implemented so that who ever has need for it can use it
16:39:40 <Sukhdev> which works best for us for Ironic integration
16:40:37 <Sukhdev> I am also trying to get a design session on this topic so that we can all discuss
16:41:30 <Sukhdev> as you know neutron is one of the biggest project, and, the number of sessions tend to be tight -
16:41:55 <Sukhdev> but, I will continue to hope and push for one :-)
16:41:58 <jroll> oh! we did get the cross-project session for this on tuesday
16:42:00 <sambetts> ++ for generic API, my concern with the existing API is that they define a translation between what comes out of the VM and what is carried on the neutron network, which of course doesn't work for most BM cases because we can't run anything between the node and the switch
16:42:27 <Sukhdev> jroll : cool - thanks for sharing this news
16:42:39 <sambetts> \o/
16:42:43 <jroll> np, almost forgot :)
16:43:12 <devananda> jroll: woot!
16:43:43 <sambetts> Neutron summit session ideas are here: https://etherpad.openstack.org/p/newton-neutron-summit-ideas
16:44:00 <sambetts> Ours is L34
16:44:38 <sambetts> Sukhdev: any idea when the decision will be made for neutron?
16:44:41 <Sukhdev> sambetts : correct, present proposal was by OVN (and OVS team) - hence, very VM centric
16:45:29 <Sukhdev> sambetts : I think the deadline for the session schedule is 4/17 -
16:45:31 <sambetts> Sukhdev: Yeah, we (Cisco) have an interest for making in more generic for SRIOV too, because that has the same problem as BM
16:45:43 <sambetts> making it*
16:46:12 <sambetts> Sukhdev: So we should know by next meeting then
16:46:19 <sambetts> awesome :)
16:46:22 <Sukhdev> sambetts : yup
16:47:21 <Sukhdev> BTW, I saw rosella replied on ML that she will pick up the work on VLAN aware VMs - she was driving it earlier
16:47:33 <Sukhdev> this means we will get traction on this -
16:47:49 <sambetts> Great!
16:48:21 <Sukhdev> What I am trying to do is to pull all the players in a room so that we can all lay out the requirements and work together so that duplicated work can be avoided
16:48:55 <Sukhdev> so that it is VLAN aware server (not just VMs)
16:49:20 <Sukhdev> Anything else on this?
16:49:42 <sambetts> Sort of related, I've added by patches to glean to add support for bonding and multiple vlans
16:49:48 <sambetts> to the midcycle ehterpad
16:50:21 <Sukhdev> sambetts : yes, I saw them - thanks
16:50:30 <sambetts> https://etherpad.openstack.org/p/ironic-neutron-mid-cycle L73
16:51:45 <sambetts> when I get a moment I hope to try to chase the same for cloudinit also
16:52:12 <sambetts> glean was an easy first target though
16:53:17 * Sukhdev time check - 7 min
16:53:29 <Sukhdev> anything else on this?
16:53:45 <Sukhdev> #topic: Open Discussion
16:54:11 <Sukhdev> Any body wants to discuss anything?
16:54:42 <sambetts> Nothing from me
16:54:58 <Sukhdev> silence is golden
16:55:04 <jroll> :)
16:55:11 <Sukhdev> shall we call it a day?
16:55:31 <sambetts> +1
16:55:41 <Sukhdev> OK
16:55:55 <Sukhdev> thanks folks - it was a great discussion
16:55:55 <jroll> thanks y'all :)
16:56:00 <Sukhdev> bye
16:56:14 <sambetts> Thanks everyone
16:56:17 <Sukhdev> #endmeeting