16:00:47 <Sukhdev> #startmeeting ironic_neutron
16:00:48 <openstack> Meeting started Mon Jun 22 16:00:47 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:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:52 <openstack> The meeting name has been set to 'ironic_neutron'
16:01:14 <Sukhdev> #topic: Agenda:
16:01:20 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron
16:01:39 <Sukhdev> If you would like to add anything to agenda, feel free to do so
16:01:58 <Sukhdev> #topic: Announcements:
16:02:06 <Sukhdev> I have couple of announcements -
16:02:47 <Sukhdev> 1) Please be sure to see the Long Term Items on our wiki - I am capturing all the items that we discuss here in this meeting in that sub-section
16:03:21 <Sukhdev> based upon discussions so far, I have added three items there - feel free to add
16:03:49 <Sukhdev> 2) there is a initiative in Neutron "Give me a Network"
16:03:53 <amotoki> Sukhdev: nice idea.
16:04:19 <Sukhdev> amotoki: brought it to my attention last week - it is cool - so I thought I let folks know about it
16:04:31 <Sukhdev> amotoki: got it thanks - feel free to add
16:04:47 <Sukhdev> https://review.openstack.org/#/c/184857/
16:05:06 <amotoki> I haven't understand how "get me a network" neutron spec is related to ironic-neutron integration. could you elaborate it more?
16:05:35 <Sukhdev> It is kind of like what we are doing - create neutron networks ahead of time and then later just use the pre-created ID
16:05:46 <jroll> I was just going to ask the same question
16:06:00 <jroll> I'm not sure this affects us
16:06:20 <Sukhdev> we will be creating networks ahead of time and then use the pre-created network IDs for our placements
16:06:49 <jroll> and?
16:06:58 <amotoki> "get me a network" spec discusses how we can get a network without calling Neutron API (i.e. being aware of Neutron)
16:07:09 <Sukhdev> I do not want to derail this discussion in favor of that spec - but, thought there was a similarity in terms of need - hence, I thought I announce it here - just as FYI
16:07:39 <amotoki> but I think it is not directly related to Ironic-neutron integration.
16:07:45 <jroll> amotoki: agree.
16:08:02 <amotoki> what I can say is if you have interested in it, please join it. it is nova-network vs neutron context.
16:08:06 <Sukhdev> amotoki: correct - it is not directly related at all - it was just an FYI...:-)
16:08:32 <amotoki> everyone in the same page now, let's move on.
16:09:06 <Sukhdev> Anybody has any announcement before we dive into the specs?
16:09:39 <Sukhdev> #topic: Specs under review:
16:10:11 <Sukhdev> jroll: I saw you uploaded latest versio
16:10:14 <Sukhdev> version
16:10:17 <jroll> correct
16:10:32 <jroll> the major change there was the network driver being per-node now, rather than per-port
16:10:32 <Sukhdev> jroll: I was ready to vote - but, had one question
16:10:44 <jroll> per-port makes it very complex and I don't think it's something we need right now.
16:11:21 <jroll> Sukhdev: yes?
16:11:34 <Sukhdev> jroll: I noticed in the apis- you changed from ports to nodes
16:11:44 <Sukhdev> the question I had was as follows:
16:12:10 <jroll> #link https://review.openstack.org/#/c/187829
16:12:15 <jroll> (for those following along)
16:12:21 <Sukhdev> a port (or port-group) will connect to a given network, node can connect to multiple networks
16:12:43 <Sukhdev> jroll: thanks for the link - I was looking :-)
16:13:19 <Sukhdev> jroll: I am talking about line 148
16:13:49 <jroll> right, so let's think about it in terms of what the network driver api needs to do. we want to do one of three things: 1) connect a node to a provisioning network; 2) connect a node to cleaning networks; 3) configure existing tenant neutron ports for a node.
16:14:15 <jroll> there may be one or more NICs involved for that node; there may be one or more networks involved.
16:15:07 <jroll> each method should do whatever needs to happen for that method. in case (3) for example this could involve attaching many port (groups) to many networks. having the node gives us all the info we need to do this.
16:15:11 <jroll> does that make sense?
16:15:50 <Sukhdev> jroll: Oh I see
16:16:11 <jroll> tl;dr configure_tenant_networks() will look like: for port_or_group in node: connect(port_or_group)
16:17:43 <amotoki> can we assume some predefined interface to connect provisioning/cleaning network if a node has multiple interfaces?
16:17:53 <Sukhdev> OK - I see - I was hung up on the fact that this method was gong to connect on port-group to one network - your explanation helps clarify it for me now
16:18:24 <jroll> amotoki: I think we'll call neutron once for each interface
16:18:47 <lazy_prince> each interface/port group..
16:19:13 <jroll> right
16:19:15 <amotoki> jroll: agree (3) step.
16:19:29 <amotoki> * for step (3).
16:19:34 <Sukhdev> amotoki: this method will invoke neutron's port-create for each port (or group) that needs to connect to a given network
16:19:53 <jroll> Sukhdev: port-update in the (3) case. but yes.
16:20:26 <Sukhdev> jroll: thanks for correcting me :-)
16:20:38 <Sukhdev> This makes sense
16:20:49 <Sukhdev> Is it clear to everybody else?
16:21:10 <Sukhdev> jroll: Other than that I was good with it - ready to vote on it
16:21:19 <jroll> so at this point I think we need the ironic folks in the room to get up and review it :)
16:21:20 <Sukhdev> devananda: are you here?
16:21:23 <amotoki> makes sense to me so far, though I have to read the spec
16:21:41 <lauramoore> it makes sense to me too
16:21:47 <Sukhdev> devananda: if you would, please review the spec as well
16:22:04 <Sukhdev> devananda jroll: we need Ironic cores to bless
16:22:13 <Sukhdev> bless it
16:22:15 <jroll> Sukhdev: yep, I'll poke people
16:22:29 <Sukhdev> Anything else on this spec?
16:22:41 <amotoki> can we approve the change only with moving from kilo to liberty and then discuss the actual changes? by doing so we can highlight what is changed?
16:22:57 <amotoki> I know it is up to ironic cores.
16:23:40 <Sukhdev> amotoki: good point - jroll, can you please deal with the logistics
16:23:41 <jroll> amotoki: a lot of it has changed since then, and nothing was implemented in kilo
16:23:55 <jroll> amotoki: I think it's worth a full re-review, with my ironic-specs core hat on :)
16:24:15 <amotoki> jroll: thanks for clarifying. if so, it makes sense.
16:24:27 <Sukhdev> lets move on
16:24:38 <Sukhdev> #topic: Physical Connectivity spec
16:25:04 <Sukhdev> #link: https://review.openstack.org/#/c/188528/
16:25:11 <jroll> 85 comments. might need an update :)
16:25:26 <Sukhdev> lauramoore: any update?
16:25:30 <lauramoore> yes, i'm working on an update :)
16:25:41 <lauramoore> i should have it up on the next day or two
16:25:52 <Sukhdev> This one looks good as well
16:26:22 <lauramoore> it looked to me like there wasn't anything too major
16:26:52 <Sukhdev> vivek had brought up a requirement for filtering on Ironic ports (from the neutron side) -
16:27:02 <amotoki> in my understanding, this spec discusses and concludes what procedure and what information are requried for ironic-neutron integration
16:27:12 <lauramoore> sukhdev and vivekandandan - thanks for coming to agreement on binding profile
16:27:19 <Sukhdev> I suggested we use host-id (like Bob had originally proposed) - other than that it looks good
16:27:23 <amotoki> and we will define the detail in neutron spec. is it right?
16:27:49 <Sukhdev> amotoki: we are not planning on having neutron spec for this
16:28:06 <Sukhdev> amotoki: we plan on using these two specs for this feature
16:28:28 <amotoki> so this spec needs to figure out the full picture for neutron impl?
16:29:08 <Sukhdev> amotoki: actually, with these changes, there is nothing really changes in the neutron side - other than the ML2 drivers
16:29:20 <Sukhdev> amotoki: we will need proper documentation -
16:29:45 <Sukhdev> amotoki: I have a sample ML2 driver implementation which can be used as a reference
16:30:31 <Sukhdev> amotoki: port binding directly flows to ML2 drivers via port context - this is all in play already
16:30:48 <amotoki> Sukhdev: correct in general. Only what I concern is a messy area of binding:profile... we can improve it in the future release, but hopefully in Liberty.
16:30:59 <Sukhdev> amotoki: ML2 drivers which support Ironic feature can use it - others continue to ignore it
16:31:11 <selvakumar> sukhdev:Could you please let us know the review id for the sample driver implementation ? is this one ):  https://review.openstack.org/#/c/181592/1/neutron/plugins/ml2/drivers/arista/mechanism_arista.py?
16:31:30 <sambetts> Sukhdev: is their much that might need to change in order to re-use an existing driver? Or are we going to need special drivers for this?
16:31:55 <amotoki> Sukhdev: and also concern ML2 will have a original interpretation of binding:profile.
16:32:09 <Sukhdev> selvakumar: No, this one does not use port-binding
16:32:18 <amotoki> it is because other monolithic plugin can support the same.
16:32:41 <Sukhdev> selvakumar: I have a different one which is much simpler and cleaner - will push it later
16:32:59 <selvakumar> Sukhdev:sure thanks
16:33:06 <BertieFulton> amotoki: When I checked binding:profile in the code base only the NEC OpenFlow controller plugin was using it
16:33:24 <amotoki> BertieFulton: and mellanox mech driver?
16:33:26 <Sukhdev> sambetts: this solution makes it very simple for the ML2 drivers to support ironic -
16:33:42 <Sukhdev> sambetts: not much changes will be needed (ideally speaking)
16:33:57 <sambetts> Sukhdev: that's good to hear :)
16:34:31 <amotoki> BertieFulton: honestly I don't care of nec pluign though i am a maintainer of it. I am just thinking from Neutron API perspective.
16:34:32 <BertieFulton> amotoki: was a while ago so I could have missed the mellanox - do you envisage problems with it?
16:35:59 <amotoki> BertieFulton: I don't see any exact problem. what in my mind is binding:profile is a free area and if we define cross-project API it is betetr to have specific fields.
16:36:21 <Sukhdev> BertieFulton: right, even I saw only one - PCI driver
16:36:50 <BertieFulton> amotoki: I think when Sukhdev checked with the Neutron guys they seemed to think that this is the kind of thing they had in mind for binding:profile. Sukhdev is this correct?
16:36:51 <Sukhdev> amotoki: I understand your point, and it was discussed during design summit as well -
16:36:59 <jroll> amotoki: I guess I don't see this as a cross-project api - just an api to connect hardware networking instead of software networking.
16:37:34 <amotoki> sorry that "cross-project APi" is misleading. I just want to mention it affects multiple projects.
16:37:46 <Sukhdev> amotoki: port-binding was added for cross project support (between Nova and neutron) to plumb the ports to the network
16:38:08 <amotoki> Sukhdev: yes.
16:38:33 <amotoki> Ideally we can define new attributes in port-binding ext.
16:39:10 <amotoki> let me ask. can we move new attributes in the next release if we have a consensus?
16:39:20 <Sukhdev> amotoki: I captured this under Long Term Items in our wiki so that we can revisit it, if needed
16:39:25 <amotoki> it will brings backward-compat problem.
16:40:03 <Sukhdev> amotoki: I do not see any backward compatibility issue, but, I could be missing something - care to elaborate?
16:40:20 <amotoki> I mean migration from Liberty to Mxx.
16:40:54 <amotoki> but it may be a small issue.
16:41:16 <Sukhdev> amotoki: I do not see migration issues as well - that is the beauty of using dicts - we are going to create new fields in the dict, which do not exist - we are not re-using anything
16:41:40 <Sukhdev> amotoki: let me post a link to sample patch using this -
16:41:45 * Sukhdev looking
16:42:18 <amotoki> Sukhdev: okay. it wil be more productive.
16:42:37 <jroll> amotoki: if we want to move things around we can support both for a while if needed, I don't tend to think it will be a difficult migration
16:42:47 <Sukhdev> sorry - having connectivity issue - can not connect to etherpad -
16:42:54 <jroll> I have an open discussion item if there's time for it btw
16:43:07 <Sukhdev> amotoki: it is posted on the ehtherpad that I used during design summit as an example
16:43:08 <amotoki> jroll: Sukhdev: agree.
16:43:21 <amotoki> Sukhdev: will check
16:44:06 <Sukhdev> lauramoore: do you have anything to add before we move on - regarding your spec?
16:44:20 <lauramoore> no, i will post an update to it in the next day or so
16:44:33 <lauramoore> and thanks to all for commenting and reviewing
16:44:43 <Sukhdev> cool - looks like we are done with the specs -
16:44:45 <Sukhdev> lets move on
16:44:53 <Sukhdev> #topic: Open Discussion
16:44:59 <Sukhdev> jroll: floor is yours
16:45:10 <jroll> so, there's some nova changes involved here
16:45:19 <jroll> and nova spec submission closes tomorrow
16:45:30 <jroll> is anyone working on a nova spec or should I get on top of that today?
16:46:05 <Sukhdev> jroll: I have been counting on you to take care of that :-)
16:46:28 <Sukhdev> jroll: do we need a spec for it ?
16:46:33 <jroll> ok.
16:46:42 <jroll> I'm not sure, we'll surely at least need a short blueprint
16:46:46 <lauramoore> jroll, i thought same as sukhdev, and so i also have not started on a nova spec,
16:46:53 <jroll> ok
16:46:57 <jroll> that's fine, just checking
16:47:05 <jroll> submission freeze is earlier than I expected
16:47:07 <lauramoore> jroll, i'm also ok to help on this today if you want?
16:47:44 <jroll> lauramoore: ok, I'll ping if I need help -- also working on another nova spec today
16:47:45 <lauramoore> also happy for you to work on  it, if you let me know what works best for you
16:47:56 <jroll> it should be small
16:48:01 <lauramoore> yes
16:48:16 <lauramoore> i agree, it should be fairly small
16:48:20 <jroll> I need to make sure we're in agreement on everything involved, I think we are
16:48:25 <lauramoore> ok, ping me if you'd like some support with it
16:48:32 <jroll> awesome. thanks!
16:48:53 <Sukhdev> jroll, lauramoore: Initially I thought we were not going to submit a spec for nova, but, a patch - but, if you feel spec is needed, it may be prudent not to miss it
16:49:13 <Sukhdev> I mean miss the deadline
16:49:15 <jroll> Sukhdev: well, we need to at least figure out if nova wants one now, while we have time to submit onwe
16:49:23 <amotoki> Sukhdev: it is allowed in Nova process?
16:49:23 <lauramoore> but please bear in mind i'm in uk time so not too late :)
16:49:38 <jroll> I don't want to start coding in a few weeks and find out it won't make liberty because it needs a spec
16:49:48 <lauramoore> jroll: i agree with that!
16:49:59 <Sukhdev> jroll: +1
16:50:17 <jroll> :P
16:50:40 <Sukhdev> Anybody wants to discuss anything else?
16:50:56 * Sukhdev waiting
16:51:12 <lauramoore> i don't have anything on my side
16:52:01 <jroll> I'm good
16:52:05 <Sukhdev> BTW, there is L2 GW meeting coming up next on this channel - anybody interested in that topic may want to hang around :-)
16:52:20 <Sukhdev> cool - looks like we are done -
16:52:28 <Sukhdev> thanks folks
16:52:33 <Sukhdev> #endmeeting