16:02:48 <Sukhdev> #startmeeting ironic_neutron
16:02:49 <openstack> Meeting started Mon Jun  8 16:02:48 2015 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:52 <openstack> The meeting name has been set to 'ironic_neutron'
16:03:03 <Sukhdev> #topic: Agenda
16:03:09 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Agenda
16:03:14 <lazy_prince> hi all...
16:03:19 <jlvillal> o/
16:03:23 <Sukhdev> Folks we have a very concentrated agenda this morning
16:03:47 <Sukhdev> #topic: Announcements
16:03:51 * devananda lurks
16:04:00 <Sukhdev> We have couple of specs out
16:04:32 <Sukhdev> We should set a goal to get these reviewed and finalized to a point so that we can move forward with implementation
16:04:53 <Sukhdev> that leads me to my question:
16:05:27 <Sukhdev> I know we have lots of people here who are in listen only mode - are there folks who are willing to jump in and help with the implementation?
16:05:35 <Sukhdev> We can use volunteers
16:05:53 <lazy_prince> I would be happy to help..
16:06:09 <Sukhdev> lazy_prince: cool - thanks
16:06:22 <Sukhdev> anybody else?
16:06:45 <Sukhdev> #topic: Specs for review
16:06:50 <lazy_prince> I think many ppl forgot about the meeting itself..
16:07:08 <yushiro> Sukhdev, Hi, I want to help about that
16:07:12 <Sukhdev> lazy_prince: I am suspecting that is the case :-)
16:07:22 * jroll will of course be helping
16:07:27 <Sukhdev> yushiro: cool - thanks
16:07:46 <Sukhdev> Lets go through the specs and then you can tell us which area would you like to participate
16:07:56 <Sukhdev> We have two specs out - thanks to jroll  and BertieFulton
16:08:13 <Sukhdev> Lets go through them one at a time -
16:08:29 <Sukhdev> First start with - https://review.openstack.org/#/c/188528/
16:08:35 <Sukhdev> I see lots of good comments
16:09:18 <Sukhdev> I think there are two critical points that need answered which can move us into the implementation, while the spec is being cleaned up
16:09:42 <Sukhdev> 1) Agreement on the dict contents that needs to go to Neutron -
16:09:57 <Sukhdev> Look at the line 114 comments
16:10:18 <Sukhdev> This has to do with LAG/MLAGGed ports - there are several questions
16:11:01 <Sukhdev> we need to be able to specify anywhere from one port to all the way 4 ports - that a BM could be connected with
16:11:25 <lazy_prince> yup..
16:11:36 <Sukhdev> I made a suggestion - did you folks have any opportunity to review it?
16:11:49 <Sukhdev> any agreements/disagreements/screems?
16:12:15 * Sukhdev waiting
16:12:27 <amotoki> is it specific to ML2? I think we are discussing a general model among neturon/ironic/nova.
16:13:01 <jroll> this spec in particular is around what the ML2/ironic interaction and data model looks like
16:13:03 <Sukhdev> amotoki: correct - but, this has to do with how do we want to represent ports - i.e. port channels, etc
16:13:39 <Sukhdev> amotoki: ML2 will be the ultimate consumer of this information
16:13:42 <amotoki> Sukhdev: agree.  it is on how we describe a port.
16:13:51 <jroll> Sukhdev: so just one thing, I think the reply's to morgabra's question there are a different thing than what he's asking
16:14:02 <Sukhdev> Hence, we need a concrete agreement - so that implementation can move forward
16:14:14 <jroll> Sukhdev: say we have two port groups. we want to connect two networks
16:14:28 <jroll> is there a plan for picking which group connects to each network?
16:15:17 <Sukhdev> jroll: yes, in this case, Ironic add_network() method (called out in your spec) will invoke neutron port_create() with one port-channel group only
16:15:34 <Sukhdev> and will repeat port-create for each network
16:15:38 <lazy_prince> yes but which one..?
16:15:41 <jroll> Sukhdev: how does the user decide? (or do they decide at all)
16:15:46 <jroll> right
16:16:27 <jroll> how do I, as a user, tell ironic that I want port(group) A to connect to network Z, and port(group) B to connect to network X
16:16:29 <Sukhdev> Look at line 185 - API proposal that i have
16:16:34 <jroll> and not the other way around
16:16:39 <lazy_prince> I could have a one groups with two nics with 10Gb and another with two nics with 1Gb
16:16:44 <Sukhdev> they will pick the port group that they would have created
16:17:35 <jroll> Sukhdev: when I do 'nova boot' how do I decide what ports should connect to what network?
16:17:38 <Sukhdev> Line 185 comment was going to be my second critical point which requires agreement - so, you walked me right into it :-)
16:17:40 <amotoki> We need to agree is how to represent a port. A port may be a single port, aggregated port like lag, port-channel.
16:18:01 <amotoki> we can reprensent a port as either name or port number.
16:18:16 <Sukhdev> jroll: Good question -
16:18:50 <jroll> amotoki: that has been mostly decided; the spec outlines what we've generally agreed on
16:18:51 <viveknarasimhan> ironic should create networks for its port
16:18:51 <viveknarasimhan> before creating the ports
16:18:53 <viveknarasimhan> themselves
16:18:59 <Sukhdev> amotoki: jroll has a good question as to how to decide which port to connect to which network
16:19:28 <amotoki> Sukhdev: yes
16:19:45 <viveknarasimhan> there should be user-input to ironic interface (REST API ) which user provides information
16:20:08 <jroll> viveknarasimhan: ironic is an admin-only api. what about users that only interact with nova and don't have access to the ironic api?
16:20:09 <rkukura> It seems to me that connecting a single NIC to multiple networks depends on neutron implementing trunk ports first. Am I missing something?
16:20:13 <Sukhdev> jroll, amotoki : can we not pick any port - as long as the BM is connoted to correct network -
16:20:32 <lazy_prince> viveknarasimhan: networks will be managed by Neutron... and network details are provided when performing nova boot..
16:20:48 <jroll> Sukhdev: technically, yes. in reality I might have a 10g nic that I want in a certain network, and a 1g nic I want in another network
16:20:51 <viveknarasimhan> then the nova user has to use a pre-created neutron network when port-create is done for ironic port
16:21:27 <jroll> viveknarasimhan: sure, how does ironic know *which port* to attach to *which network*?
16:21:31 <Sukhdev> jroll: Does nova allow today to pick a nic/port to specified at the nova boot time?
16:21:45 <jroll> Sukhdev: no, because all virtual nics are created equal :)
16:21:50 <amotoki> I think we can know which interfcace/port group is connected to which network. It is a part covered by a process of discovery.
16:22:13 <lazy_prince> rkukura: correct.. but here, we need to decide access mode for port groups when multiple port groups are available..
16:22:28 <amotoki> woops..... which port is connected to which SWITCH PORT/NAMED PORT.
16:23:02 <Sukhdev> jroll: So, I see two ways to address this - 1) Ironic picks without any user input 2) we add an option to mova boot to specify nic/port
16:23:59 <jroll> Sukhdev: right. I think (2) is the most useful, but as we'll need to fall back to (1) in the case of "I don't care", maybe we do (1) first and build on that
16:24:02 <Sukhdev> amotoki: once we know the ports (through discovery), how do we know the wish of user that which port he wants to connect to which network - that is jroll's point
16:24:24 <jroll> Sukhdev: I just don't want to lose track of (2) while we're doing (1)
16:24:26 <Sukhdev> jroll: I am in favor of 1) for now
16:24:49 <amotoki> if there is no input from users, can't we pick up any port?
16:24:57 <lazy_prince> can we first focus on functionality and then tailor it for specific use cases like pin pointing the network to a nic/port group..?
16:25:03 <Sukhdev> jroll: agree - we can make a note of 2) in the spec (I can add to wiki as well) for long term items to track
16:25:12 <jroll> lazy_prince: +1
16:25:16 <Sukhdev> amotoki: that will be option 1)
16:25:29 <Sukhdev> lazy_prince: +1
16:25:36 <morgabra> Sukhdev: jroll: another concerning thing I just heard: We should certainly allow the same port/port group to attach to multiple networks, there's no reason the neutron plugin could not trunk multiple networks over the same port
16:25:59 <morgabra> in fact, we do that with our hacky plugin today
16:26:01 <jroll> agree
16:26:24 <Sukhdev> morgabra: that work is in progress in neutron - but, not yet available - we will allow that as soon as it becomes available in neutron
16:26:48 <Sukhdev> morgabra: This was discussed in Summit during design - it is documented on the ehterpad
16:26:51 <lazy_prince> yup.. lets focus on simple use cases like 1 nic to 1 network...
16:27:16 <Sukhdev> Lets get back to the point where we started from
16:27:45 <Sukhdev> Lets go back to line 114 comments - i.e. how do we want to represent the ports to neutron
16:28:04 <viveknarasimhan_> checking connectivity to webchat server - ping
16:28:11 <Sukhdev> Please see my comment - and see if you agree/disagree or want to screem :-)
16:28:30 <Sukhdev> viveknarasimhan_ ?
16:28:33 <jroll> viveknarasimhan_: 1 packets transmitted, 1 received, 0% packet loss, time 0ms
16:28:35 <jroll> :)
16:28:58 <viveknarasimhan_> Sukhdev: i missed your comment , was punted out of room :)
16:29:14 <viveknarasimhan_> Sukhdev: can you please post your comment again
16:29:14 <Sukhdev> viveknarasimhan_: see my comment on line 114
16:30:02 <jroll> Sukhdev: so your proposal is a list of ports, which may or may not be a list of port groups?
16:30:13 <Sukhdev> viveknarasimhan_: as to how do we represent the physical ports to neutron - morgabra and lauramoore had raised a concern, I sort of made a proposal there
16:30:19 <viveknarasimhan_> list of local _link_information
16:30:32 <jroll> I'm not sure I understand this proposal
16:30:44 <Sukhdev> jroll: It is a list of port groups - and port group is a list of ports
16:31:09 <Sukhdev> jroll: so this gives you ability to pass anywhere from 1 to 4 ports - or more port groups
16:31:31 <jroll> it's port groups all the way down then?
16:32:02 <viveknarasimhan_> Sukhdev:  i see that you propose a list of local_link_information for LAG Ports
16:32:11 <viveknarasimhan_> Sukhdev: that is fine with me
16:32:26 <Sukhdev> jroll: sorta - this gives you all possibilities - and see keeps things consistent and simple - unless anybody has a creative way
16:32:40 <Sukhdev> s/see/still
16:33:32 <jroll> I don't see why a port group needs to be a maximum of two ports, personally
16:34:17 <Sukhdev> jroll: it does not have to be - but, most of the times, I have seen it that way -
16:34:35 <lazy_prince> why not keep all available port in same port group for now...
16:34:45 <Sukhdev> jroll: but, this proposal does not limit you to only 2 - I only used it as an example
16:34:45 <jroll> +1
16:34:56 <jroll> a port group defines a single logical connection
16:34:59 <lazy_prince> and relook at it when thhings start working..
16:35:02 <viveknarasimhan_> Sukhdev:  Neutron would come to know
16:35:43 <Sukhdev> jroll: port-group is really a list of ports - its does not limit to only 2 - it can be 1 or more ports
16:35:47 <viveknarasimhan_> Sukhdev: Or would neutron need to know if its being passed a port group at all
16:36:26 <lauramoore> i don't see a reason to have to have a limit either
16:36:26 <lazy_prince> probably it would.. as neutron will need the MAC ID for the port group..
16:36:28 <Sukhdev> viveknarasimhan_: Neutron will be given a list of port-groups - if there are more items in the list, it assumes a port-group otherwise, it is a single port
16:36:36 <jroll> Sukhdev: so it should be [port.local_link_information for port in port_group.ports]
16:36:41 <viveknarasimhan_> Sukhdev: This port and port-group terminology is maintained purely in Ironic side, right?  We see only neutron port with network information as many of them equal to side of list of local_link_information
16:37:08 <Sukhdev> jroll: yup - something like that
16:37:10 <lauramoore> i agree with jroll suggestion
16:37:13 <amotoki> I am confused with the terminology...
16:37:26 <viveknarasimhan_> Sukhdev:  Ok, the list size of local_link_information
16:37:28 <Sukhdev> viveknarasimhan_: correct
16:37:35 <viveknarasimhan_> determines for neutron if its a port-group or just a port
16:37:40 <viveknarasimhan_> Sukhdev: Ok clear!
16:37:47 <jroll> Sukhdev: perhaps the wording of your proposal is confusing me, then, I don't understand "list of port groups"
16:37:54 <jroll> ok, I see
16:38:30 <jroll> does neutron care if it's a port group vs a port? (i.e. are there special things configured for a LAG on the switch)
16:38:30 <rkukura> Sukhdev: Can you clarify whether “port-group” is a list of neutron ports or a list of switch ports?
16:38:36 <Sukhdev> jroll: if we are in agreement on the concept, I will work with Bertie lauramoore to get the terminology all cleared up
16:38:57 <Sukhdev> rkukura: one neutron port maps to  one port-group
16:38:58 <jroll> rkukura: list of ironic ports, which correspond 1:1 with physical nics / switch ports
16:39:21 <viveknarasimhan_> rkukura:  a port-group is a list of switch ports not Neutron ports
16:39:42 <pshige> rkukura: I can't see some characters
16:39:42 <viveknarasimhan_> rkukura:  It is a LAG of which all switch ports will belong to the same network and so same segment
16:39:49 <Sukhdev> We are running out of time - lets start summarizing things
16:40:02 <rkukura> thanks
16:40:12 <Sukhdev> So, I assuming, we are in general good with line 114 comments -
16:40:34 <Sukhdev> lets quickly talk about line 185 comments - this is API modification
16:40:43 <viveknarasimhan_> Sukhdev: +1 from me on port-group terminology for LAG ports
16:41:02 <Sukhdev> I threw it out there as straw man proposal for API modification -
16:41:14 <Sukhdev> viveknarasimhan_: thanks
16:41:34 <jroll> Sukhdev: seems mostly good to me... API impact should be fairly easy, add keys to the json body for create/update
16:41:47 <Sukhdev> jroll: correct
16:41:52 <jroll> Sukhdev: I don't think there's much to debate there, we just need to list what's changing
16:42:07 <jroll> seems like more of a "need time to do this" rather than "let's decide what this looks like"
16:42:11 <viveknarasimhan_> Have a query on Sukhdev comment L 185
16:42:18 <lauramoore> we should have this in the next patch in the next day or two
16:42:26 <Sukhdev> jroll: correct - but, we need closures so that implementation can begin while the spec is being cleaned up
16:42:56 <Sukhdev> Now on to my question - who would like to jump in to implement this?
16:43:37 <Sukhdev> yushiro, lazy_prince - any one of you want to take a crack at it?
16:43:41 <jroll> Sukhdev: it's just a rest api. I think people can figure it out while the spec gets tidied up :)
16:44:08 <lazy_prince> i could take a look at the rest api..
16:44:11 <lauramoore> Sukhdev, i'm also interested in giving this a go
16:44:21 <Sukhdev> jroll: that is my point - so that we can start to move forward with API changes
16:44:36 <viveknarasimhan_> Well, I guess Sukhdev requests about Ironic side REST API feeding information
16:44:49 <viveknarasimhan_> Sukhdev: can  you please let us know if am i right ?
16:45:02 <Sukhdev> Cool - we have two people - can lauramoore and lazy_prince work out on this one
16:45:23 <Sukhdev> #action: lauramoore and lazy_prince to come up with a patch for API modification
16:45:27 <jroll> Sukhdev: sure, I just don't think there's much to debate about a rest api. it's a json representation of the object. just update it to add the new fields
16:45:34 <jroll> Sukhdev: though we need to add it to the spec
16:45:38 <Sukhdev> lazy_prince, lauramoore : I gave you action to work on a patch
16:45:47 <lazy_prince> cool..
16:45:54 <lauramoore> sure
16:46:03 <Sukhdev> jroll: +1
16:46:13 <Sukhdev> #topic: the second spec
16:46:15 <lauramoore> but i will aim to update the spec first
16:46:17 <jroll> the api changes need to be based on top of the db changes, fwiw, or else they won't work at all :P
16:46:35 <Sukhdev> Now lets dive into the next spec -
16:46:57 <lazy_prince> we only have 14 minutes..
16:46:57 <viveknarasimhan_> Sukhdev: Neutron side changes in ML2 plugin, do you foresee any effects there , based on the bind_requested flag?
16:47:17 <Sukhdev> jroll: correct - I am assuming lauramoore and lazy_prince will figure it out - and shout for help, if needed, we are here every week to help/address issues
16:47:29 <Sukhdev> viveknarasimhan_: not really -
16:47:33 <jroll> yep
16:47:40 <viveknarasimhan_> Sukhdev: Ok
16:47:43 <jroll> #link https://review.openstack.org/#/c/187829/1/specs/liberty/network-provider.rst
16:47:53 <Sukhdev> lazy_prince: thanks for reminder - that is why I am rushing through :-)
16:47:59 <jroll> are there any major concerns in here we must hash out during the meeting?
16:48:19 <Sukhdev> I see the second spec is in a good shape - I had only one critical issue with it
16:48:40 * Sukhdev - looking for my comment
16:49:05 <rkukura> I’m a bit concerned about the bind_requested flag, but need to read the spec more closely. Note that ML2 already has a way to control whether binding is requested - setting the binding:host_id attributes. Any chance ironic could simply set binding:host_id to empty when it doesn’t want the port bound?
16:49:26 <Sukhdev> jroll: my comment on line 185
16:49:39 <jroll> rkukura: AIUI that will set the port to "binding failed", which isn't really great from an ops perspective
16:49:47 <jroll> Sukhdev: ok, there's two reasons for this
16:50:10 <jroll> 1) I'd like this to be a pluggable layer such that someone could write a plugin for a network provider that is not neutron, if they wish
16:50:12 <rkukura> jroll: Setting binding:host_id to empry should result in binding:vif_type being “unbound”
16:50:14 <Sukhdev> rkukura: yes, that can be used - we thought there is no reason to overload it
16:50:46 <rkukura> Sukhdev: I wouldn’t consider this to be overloading it, since that’s already what it does.
16:50:48 <jroll> 2) see Om Kumar's comment, I agree here. though maybe per-port would be better. either way we need the option, whether it's a db field or a config option
16:51:09 <viveknarasimhan_> Sukhdev: agree with rkukura, to reuse host_id field
16:51:10 <lazy_prince> hmm.. That Om kumar is me.. :)
16:51:21 <jroll> can we keep this to one topic please?'
16:51:24 <lazy_prince> wanted to check of that comment makes sense..
16:51:28 <jroll> lazy_prince: TIL! :)
16:51:29 <Sukhdev> rkukura: perhaps then we can use it - this is a minor modification - I will work with you offline on this and get it incorporated - if that makes sense
16:51:30 <viveknarasimhan_> Sukhdev: in lieu of adding a new field bind_requested
16:51:58 <jroll> lazy_prince: I like the idea behind per-port config for that
16:52:08 <Sukhdev> jroll: sorry
16:52:40 <Sukhdev> jroll: so, I see the following issue - Perhaps it is my thinking which is skewed here  - bear with me for a sec
16:53:02 <jroll> Sukhdev: let me put it this way, there are people using ironic without neutron today.
16:53:13 <jroll> Sukhdev: and those folks wish to continue to do so.
16:53:25 <jroll> we don't want to force neutron (or any openstack services) on ironic users
16:53:26 <Sukhdev> in order for ironic to connect a port to the network, neutron needs to know about this network - i.e. somebody needs to do neutron net-create before it can be used
16:53:59 <lazy_prince> Ironic can work as a standalone app too
16:54:04 <jroll> ^
16:54:15 <pshige> :)
16:54:17 <jroll> ironic has a clear goal of being useful without any of the rest of openstack
16:54:37 <Sukhdev> and, when a network is created, that is when a VLAN is associated with the network - which will be used to plumb the ports
16:54:52 <Sukhdev> so, in my mind that creates a chicken-n-egg problem
16:55:04 <lazy_prince> it could also happen that some drivers may want to do deployment without changing the network.. in which case this pluggable model helps..
16:55:23 <Sukhdev> jroll, lazy_prince : so I see your use case - looks like we have two use cases to address then
16:55:38 <amotoki> what is assumed when ironic is in a standalone mode? what network model is expected?
16:55:42 <jroll> Sukhdev: it's not *my* use case, it's an explicit goal of the ironic project
16:55:46 <jroll> amotoki: flat
16:55:48 <amotoki> flat network?
16:55:53 <jroll> static dhcp etc
16:56:17 <amotoki> sounds reasonable
16:56:27 <jroll> Sukhdev: what's the problem with neutron being optional?
16:57:12 <Sukhdev> jroll: there is no problem - however, when we want to use neutron for plumbing, we need to provide it the information it needs to plumb things correctly
16:57:13 <killer_prince> foo now, its flat.. but it does not have to be flat always..
16:57:34 <killer_prince> s/foo/for/
16:57:44 <jroll> Sukhdev: right, so we make a pluggable layer with the right methods. the other option is 'none' or something, which will just ignore those calls
16:58:08 <Sukhdev> jroll: OK now we are on to something
16:58:19 <killer_prince> more precisely, we would like to controll it from ironic..
16:58:33 <jroll> Sukhdev: lines 39-48 or so
16:58:37 <Sukhdev> jroll: but, I am interested in covering the case when neutron is in play - we want to make sure we have things in correct order so that it will work
16:58:48 <pshige> lots of princes :)
16:59:05 <Sukhdev> pshige, we need kings :-)
16:59:20 <killer_prince> 1min left..
16:59:27 <jroll> Sukhdev: sure, but this spec should also cover the pluggability, from an ironic perspective
16:59:57 <Sukhdev> jroll: I was not aware of the stand alone use case - let me go back and re-review in this light
17:00:21 <jroll> Sukhdev: it also means we need to think about the "uses neutron but not nova" case, which may be painful
17:00:29 <Sukhdev> moreover, we are out of time - lets add comments on the spec and take it from there - jroll I will catch you on ironic irc for questions
17:00:36 <jroll> I guess we're out of time now... I'm in ironic and neutron channels if anyone wants to continue :)
17:01:01 <pshige> thanks!
17:01:02 <Sukhdev> OK folks thanks for attending - this was a very productive discussion
17:01:07 <Sukhdev> thanks and bye
17:01:11 <Sukhdev> #endmeeting