16:00:41 <Sukhdev> #startmeeting ironic_neutron
16:00:42 <openstack> Meeting started Mon Jul 20 16:00:41 2015 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:02 <Sukhdev> Good morning and welcome to our weekly meeting
16:01:11 <Sukhdev> #topic: Agenda
16:01:16 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron
16:01:35 <Sukhdev> Anybody would like to add/change anything on the agenda?
16:01:58 <jroll> nope :)
16:02:04 <Sukhdev> #topic: Announcements
16:02:26 <Sukhdev> Liberty release schedule - https://wiki.openstack.org/wiki/Liberty_Release_Schedule
16:02:42 <Sukhdev> This gives us solid month and half to get our code in
16:03:13 <jroll> ironic doesn't do a traditional feature freeze any more
16:03:33 <Sukhdev> jroll: Neutron side will impose it
16:03:34 <jroll> but this is a large change, so I think it's still good to aim for early to mid september
16:03:37 <jroll> right, I know
16:03:40 <jroll> just a heads up.
16:04:13 <Sukhdev> As long as we get the Ironic-Neutron interface ironed out, we can continue to work on the Ironic side
16:04:34 <Sukhdev> Ironic Mid-Cycle - https://etherpad.openstack.org/p/ironic-liberty-midcycle
16:04:39 <Sukhdev> #link: https://etherpad.openstack.org/p/ironic-liberty-midcycle
16:05:14 <Sukhdev> I and mitch from Arista will be participating
16:05:36 * jroll will be there
16:05:46 <Sukhdev> Anybody has any other announcements?
16:05:59 <viveknarasimhan> Sudhhev: is this about mid-cycle participation?
16:06:13 <Sukhdev> viveknarasimhan: yes
16:06:15 <jroll> yes, ironic midcycle.
16:06:22 <viveknarasimhan> Sukhdev: ok. thanks.
16:06:27 <jroll> oh, also-
16:06:53 <jroll> I'll be at the nova midcycle this week, hoping to spend some time discussing baremetal networking things in general, and reviving the nova patches I have for this
16:07:15 <Sukhdev> jroll: fantastic
16:07:59 <Sukhdev> jroll: please get the network flip logic (in principal) blessed by the team
16:08:15 <jroll> will do what I can :)
16:08:31 <Sukhdev> Any other announcement?
16:08:48 <viveknarasimhan> Sukhdev:  We are pushing
16:08:48 <Sukhdev> #topic: Specs Under review
16:08:56 <Sukhdev> #undo
16:08:57 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xa7c3250>
16:09:15 <Sukhdev> viveknarasimhan: Please go on
16:09:23 <viveknarasimhan> Sukhdev: the mech-driver code-pieces under github.com/hp-networking/baremetal-network-provisioning
16:09:40 <viveknarasimhan> Sukhdev: we will bring them into Openstack namespace as per advise from armax
16:10:07 <Sukhdev> viveknarasimhan: I saw it, but, have not had a chance to review it carefully
16:10:31 <Sukhdev> viveknarasimhan: Do you have any ML2 driver already in place for VMs?
16:10:43 <viveknarasimhan> Sukhdev: Nope
16:10:52 <Sukhdev> #link: github.com/hp-networking/baremetal-network-provisioning
16:11:01 <viveknarasimhan> Sukhdev:  We do have for VMs with ESX deployments under openstack/networking-vsphere
16:11:38 <Sukhdev> viveknarasimhan: I see - otherwise, these changes for Ironic will be trivial enhancements to existing ML2 drivers :-):-)
16:12:04 <Sukhdev> Anything else?
16:12:07 <jroll> viveknarasimhan: question - is this meant to be an ml2 mech for all switch vendors, eventually, or only HP?
16:12:20 <viveknarasimhan> Sukhdev: Agree.. but HPN strategy has requested us to handle this separately in a different mech-driver. So we are pursuing this way
16:12:44 <Sukhdev> jroll: I guess not
16:12:55 <viveknarasimhan> jroll: Initially our focus is on HP ToR switches.  We will add code eventually for other vendor switches as well
16:13:02 <Sukhdev> jroll: this is HP specific
16:13:07 <jroll> viveknarasimhan: ok, interesting
16:13:11 <jroll> Sukhdev: it appears pluggable.
16:13:16 <jroll> anyway, let's move on?
16:13:34 <viveknarasimhan> jroll: It is pluggable..  we are defining it that way :)
16:14:00 <Sukhdev> viveknarasimhan: I will spend some time to review it and provide feedback
16:14:21 <Sukhdev> anything else?
16:14:28 <viveknarasimhan> Sukhdev: Please, welcome
16:14:48 <Sukhdev> #topic: Specs Under Review
16:15:03 <Sukhdev> We have one of the specs merged - yay!
16:15:07 <jroll> \o/
16:15:33 <Sukhdev> Second one is almost there - I was hoping we will get another Ironic core to +2 on it :-)
16:15:46 <lauramoore> :jroll good job :)
16:15:51 <jroll> yeah, I've been bugging people about the second
16:15:53 <Sukhdev> devananda had some questions
16:15:55 <jroll> thanks lauramoore :)
16:16:09 <devananda> o/
16:16:29 <Sukhdev> devananda: see if you are satisfied with the responses to your comments -
16:16:31 <lauramoore> there seemed to be 2 questions
16:16:48 <lauramoore> 1 about naming - i am thinking to go with portgroup
16:18:08 <Sukhdev> lauramoore: +1 on 1
16:18:12 <lauramoore> does anyone have an issue with that?
16:18:31 <jroll> fine with me
16:18:53 <lauramoore> ok, second point seemed to be about using multiple pxe addresses
16:19:06 <lauramoore> i'm not sure i completely followed this
16:19:12 <jroll> right, so
16:19:19 <lauramoore> my understanding was that we'd create a portgroup for a LAG'ed interface
16:19:24 <jroll> the concern seems to be the "pick one at random" part
16:19:26 <lauramoore> the portgroup would have 1 pxe address
16:19:48 <lauramoore> i was thinking we could just enforce the portgroup address in that case?
16:20:00 <lauramoore> the operator would set that address in the portgroup
16:20:17 <jroll> lauramoore: so I don't think anyone is arguing with that
16:20:21 <jroll> just the "If there are multiple ports choose one at random."
16:20:40 <jroll> if there are multiple ports with pxe_enabled, we could just set up pxe options for all of them
16:20:52 <jroll> and whichever the node boots from, it boots from
16:21:53 <amotoki> I think same as jroll.
16:22:21 <Sukhdev> correct - I think the wording is confusing the folks -
16:22:38 <lauramoore> so in the case that we have 2 ports both pxe enabled, both in a portgroup
16:23:07 <jroll> lauramoore: that case is clear, the portgroup is the only thing to boot from
16:23:25 <lauramoore> ok, so we go with portgroup and the pxe_address in portgroup, right?
16:23:27 <Sukhdev> lauramoore: port group is really one (logical) port -
16:23:35 <jroll> lauramoore: the unclear case is two ports (not in a group) or two portgroups, both with pxe enabled
16:24:00 <lauramoore> in that case we take all ports not in portgroups that are pxe_enabled
16:24:12 <lauramoore> we take all portgroups that are pxe_enabled
16:24:44 <lauramoore> is this what you also think?
16:24:52 <jroll> yes, and set dhcpboot options for all of them
16:24:59 <jroll> however the spec says choose one at random
16:25:02 <lauramoore> this was my understanding, but maybe the wording just needs fixed up to make it a bit clearer
16:25:40 <jroll> I think it should read "if there are multiple ports, set DHCPBOOT options for all ports"
16:26:47 <Sukhdev> Are we good with this?
16:27:13 <jroll> I am
16:27:17 <amotoki> looks good
16:27:18 <lauramoore> ok, i'll update this, thanks!
16:27:26 <jroll> thank you!
16:27:38 <Sukhdev> cool - looks like we have a closure on this
16:27:49 <Sukhdev> anything else on the specs?
16:27:50 <jroll> lauramoore: a new rev with all the weedback would be great, ping me when it's up and I'll review asap
16:28:18 <lauramoore> :jroll, thanks!
16:28:30 <lauramoore> will aim to do this later today
16:28:47 <Sukhdev> We already have approval from the neutron side - so, this should go smoothly
16:29:01 <jroll> on that note, I need to go catch a plane, sorry I can't stay for the rest of the meeting
16:29:28 <Sukhdev> jroll: we will try to miss you :-):-)
16:29:34 <Sukhdev> jroll: safe travells
16:29:36 <jroll> heh
16:29:42 <jroll> thanks everyone, see you later
16:29:59 <Sukhdev> Anything else on the specs before we move on?
16:30:26 <Sukhdev> #topic: Patches under review
16:30:33 <Sukhdev> #link: https://review.openstack.org/#/c/197774/1
16:30:48 <Sukhdev> I pushed this patch a while back as WIP -
16:31:00 <Sukhdev> this is to define the new vnic-type
16:31:22 <Sukhdev> this is to facilitate the filtering for ML2 drivers
16:31:56 <Sukhdev> I will remove the WIP from it - so that we can get this approved and merged
16:31:59 <viveknarasimhan> Sukhdev: useful patch.  can we merge this
16:32:26 <viveknarasimhan> Sukhdev: +1
16:32:34 <Sukhdev> viveknarasimhan: I wanted folks to have a chance to review it - since this will be used by the Ironic side
16:32:39 <amotoki> it itself looks good
16:33:04 <amotoki> where can we implement the validation for this vnic type? ml2 plugin? ml2 mech driver?
16:33:23 <Sukhdev> amotoki viveknarasimhan : I spent some time last week playing with binding profile to make sure we are good with the interface
16:33:37 <viveknarasimhan> amotoki: We have done it in mech-driver
16:33:54 <lauramoore> :sukhdev, thanks for posting this, it looks good to me too
16:34:12 <Sukhdev> amotoki: I think ml2 driver
16:34:13 <amotoki> Sukhdev: nice. i hope we have te validation logic in a common place.
16:34:26 <viveknarasimhan> Sukhdev: You can post teh binding_profile interface you have tested with. And we can correlate with ours we have used to develop.
16:34:55 <Sukhdev> viveknarasimhan: Oh - I did not get to finish my thought on my testing
16:34:58 <amotoki> it is from API perspective, but we can check it in a mech driver in the fist impl.
16:35:51 <Sukhdev> amotoki: I want to pick on your brain in terms of testing - in the Testing section - I have added a section to the Agenda -
16:36:13 <Sukhdev> so, hold off the testing part for a moment
16:36:30 <Sukhdev> So, coming back to my interface testing -
16:37:09 <Sukhdev> So, created a hacked up Nova patch (to be replaced by lauramoore's real patch) to verify the logic all the way back to ML2
16:38:00 <Sukhdev> The good news is that our ML2 framework is in real good shape and does not require any modification - other than the patch that I have pushed
16:38:15 <viveknarasimhan> Sukhdev: We observed the same too
16:38:41 <Sukhdev> we are in good shape - I was able to mess around on the nova side to push different values and they go in the correct place in the ML2 drivers
16:39:05 <Sukhdev> viveknarasimhan: excellent - so, double checking is great!!
16:39:15 <viveknarasimhan> Sukhdev: We did not change Nova, instead we played around with neutron port-create RESTful API during our development
16:39:27 <amotoki> no impl change is good for mech drivers.
16:39:46 <amotoki> a bad thing is there is no way to know the feature is supported from outside (like nova, horizon).
16:39:49 <Sukhdev> viveknarasimhan: either way is good - as long as we can mimic the behaviour
16:40:11 <viveknarasimhan> Sukhdev: Agree.
16:40:13 <Sukhdev> amotoki: you know from nova - but, not from horizon
16:40:41 <Sukhdev> amotoki: nova boot - knows when you are launching baremetal
16:40:46 <amotoki> Sukhdev: hehe.... it means we cannot implement a dashboard
16:41:01 <amotoki> it is a joke.
16:41:02 <Sukhdev> amotoki: correct - no horizon
16:41:45 <Sukhdev> So, I wanted to make a point that we are looking real good from the interface point of view -
16:41:56 <amotoki> from API perspective, nova networking interface (nova/network/neutronv2/api.py) checks if the feature is supported and then send request to neutron.
16:42:23 <Sukhdev> amotoki: correct
16:42:27 <amotoki> at now we need to send a request to neutron anyway to check baremetal vnic is supported.
16:42:34 <Sukhdev> amotoki: it uses ironic-driver
16:42:49 <devananda> if nova can tell that the feature is supported by querying neutronAPI, then, in principle, someone could add that check to horizon as well, right?
16:43:32 <viveknarasimhan> devananda:  yes
16:43:43 <amotoki> at now neutron does not support API micro-vesioning, so we need to use extension list to check a feature (ie, querying a fearture)
16:44:20 <amotoki> the current proposed change is an implicit change in the existing attribute (binding:profile) and there is no way to check it.
16:44:43 <devananda> also, wouldn't this be a cloud-wide feature, not something that needs to be checked on every request?
16:44:44 <Sukhdev> devananda: currently neutron API can not tell
16:45:01 <devananda> Sukhdev: oh ok, I misunderstood amotoki's comment then
16:45:25 <viveknarasimhan> amotoki:  can we provide a simple extension file for this feature (no overriding any neutron resource in that )
16:45:46 <amotoki> viveknarasimhan: it is what I start to think now.
16:46:15 <viveknarasimhan> amotoki: neutron ext-list validation should be sufficient for nova
16:46:27 <Sukhdev> viveknarasimhan: is it some thing trivial? can we pull it off in Liberty or shall we plan for M-release?
16:46:47 <viveknarasimhan> Sukhdev: It should be possible. we are still at Liberty-2
16:47:11 <amotoki> ideally it is better to define new attributes, but ml2 driver maintainer seem to want not to change ML2 driver interface and continue to use binding:profile.
16:48:19 <Sukhdev> amotoki: I would like to explore viveknarasimhan's idea about this
16:48:32 <Sukhdev> that may be a low hanging fruit
16:48:58 <Sukhdev> amotoki: your thought?
16:49:41 <amotoki> Sukhdev: I am okay, but I would like to avoid implicit changes as API person.
16:49:46 <amotoki> can we mention the API interface may be changed in Mitaka release?
16:50:36 <Sukhdev> amotoki: sounds good to me
16:50:50 <viveknarasimhan> amotoki:  ok
16:51:13 <amotoki> I could not upload neutron devref last week. I try to cover the potential change in it.
16:51:44 <Sukhdev> anything else? since we are touching on documentation - that is our next topic
16:51:45 <viveknarasimhan> amotoki: cool. thanks
16:51:55 <Sukhdev> #topic: Documentation
16:52:16 <Sukhdev> amotoki and I discussed about the documentation plan for this interface
16:52:48 <Sukhdev> amotoki graciously agreed to document this in the devref
16:53:09 <Sukhdev> so, he has already provided the update on it :-)
16:53:19 <Sukhdev> amotoki: do you want to add anything more to it?
16:53:39 <amotoki> nothing at now
16:53:42 <lauramoore> :amatoki, nice one, thankyou!
16:54:28 <Sukhdev> We will need another set of document from the Ironic side
16:54:43 <Sukhdev> perhaps I will add to the agenda for next week
16:55:17 <Sukhdev> The second part of the documentation will address the operator side - i.e. how to configure LAG/MLAGs
16:55:45 <Sukhdev> port channels, etc.. i.e. how to use the new Ironic API called out by lauramoore's spec
16:56:10 <Sukhdev> anything else on documentation?
16:56:16 * Sukhdev time check 4 min
16:56:27 <Sukhdev> #topic: Testing
16:56:41 <Sukhdev> I wanted to talk a bit about testing this feature -
16:57:05 <Sukhdev> there are two parts to the testing - end-to-end functionality
16:57:12 <Sukhdev> and, the API interface
16:57:30 <Sukhdev> amotoki: I want to pick on your brain regarding API testing
16:57:47 <Sukhdev> Since, we are tight on time - perhaps we can discuss this in next meeting
16:57:57 <amotoki> we have two new API: ironic side and neutron side.
16:58:05 <amotoki> Sukhdev: which part in your mind?
16:58:18 <Sukhdev> amotoki: the neutron side
16:59:01 <Sukhdev> amotoki: i.e. how to verify the switch-id, port groups, etc…
16:59:14 <amotoki> Sukhdev: I see.
16:59:15 <Sukhdev> amotoki: we do not have any tests that we can leverage from
16:59:37 <amotoki> doesn't  port binding test help?
17:00:15 <Sukhdev> amotoki: I am going to explore it - I discussed this in ML2 meeting last week -
17:00:29 <Sukhdev> amotoki: it seems that may not be sufficient -
17:00:42 <Sukhdev> amotoki: lets plan on discussing this next week
17:00:43 <amotoki> Sukhdev: I can explore too. time is over..
17:00:57 <Sukhdev> Yes, time is up folks -
17:01:09 <Sukhdev> Thanks for attending  - it was a good discussion
17:01:12 <Sukhdev> bye
17:01:17 <Sukhdev> #endmeeting