16:01:27 <Sukhdev> #startmeeting ironic_neutron
16:01:28 <openstack> Meeting started Mon Jan 18 16:01:27 2016 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:33 <openstack> The meeting name has been set to 'ironic_neutron'
16:02:04 <lazy_prince> o/
16:02:24 <Sukhdev> #topic: Agenda
16:02:31 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_January_18.2C_2016
16:03:08 <Sukhdev> Today is MLK holiday in USA - lets see who is here?
16:03:17 <yhvh> o/
16:03:46 <vsaienko> \o
16:03:53 <Sukhdev> #topic: Announcements
16:04:01 <devananda> o/
16:04:26 <Sukhdev> I think M2 cutoff date is this week sometime
16:04:59 <Sukhdev> I do not have any announcements - does anybody have any?
16:05:26 <Sukhdev> #topic: Integration Testing Status
16:05:54 <Sukhdev> So, I tested most of the patches last week
16:06:22 <Sukhdev> other than one patch, all seem to work fine
16:06:24 <vsaienko> Sukhdev: I will upload new series of patches today, that contains small fixes
16:06:49 <lazy_prince> We also tested the patches and they seem to work fine..
16:07:51 <jroll> \o
16:07:53 <Sukhdev> vsaienko : one of the devstack patches was failing - I did not get an opportunity to test the updated version -
16:07:53 <jroll> sorry I'm late
16:07:57 <sambetts> o/
16:07:58 <Sukhdev> will test it later today
16:08:32 <vsaienko> sukhdev: thank you
16:08:54 <Sukhdev> vsaienko : I saw your comments on this https://review.openstack.org/#/c/139687
16:09:35 <Sukhdev> regarding local_link_connection being the list vs single port -
16:10:04 <Sukhdev> I felt your understanding was incorrect, so, posted updated comments to explain it better - please have a look
16:11:14 <vsaienko> hm... _get_node_portmap method returns all nodes ports
16:11:29 <vsaienko> please have look at line 54 https://review.openstack.org/#/c/139687/41/ironic/networks/neutron_plugin.py
16:11:50 <vsaienko> I thought that support of LAG/MLAG should be done with portgroups
16:12:56 <Sukhdev> correct
16:13:39 <Sukhdev> I was not paying attention to function _get_node_portmap - but, more to the need of single port vs. multiple ports in that list
16:14:07 <Sukhdev> as long as we are on the same page that it is a list of port, we are good -
16:16:47 <Sukhdev> sorry my session crapped out -
16:17:03 <devananda> where is default network state of the port determined?
16:17:32 <devananda> for instance, let's say that I want ports for nodes that are simply in "manageable" state to be on VLAN 6. How would I arrange that to happen?
16:18:52 <sambetts> devananda: you'd have to move their neutron counterparts I'd expect
16:19:10 <jroll> I believe you'd have to set up the provisioning network in neutron to use that vlan id
16:19:20 <jroll> and the ml2 thing would do it
16:19:59 <Sukhdev> correct - if I understand devananda's question correctly - here is how I see this happening
16:19:59 <jroll> that make sense devananda ?
16:20:18 <jroll> devananda: or are you saying, with no neutron ports attached, how that's determined?
16:21:17 <Sukhdev> 1) the ports that connect to the switch which needs to be attached to vlan 6 (provisioing network) needs to be grouped into local_link_information
16:21:42 <Sukhdev> 2) the provisioning network ID needs to be set in /etc/ironic/ironic_config
16:21:59 <Sukhdev> 3) create/update neutron port needs to be issued
16:22:12 <Sukhdev> that should do it - ML2 will take care of the rest
16:22:25 <devananda> tear_down() calls remove_provisoning_network()
16:22:37 <devananda> I'm not sure what network the node will be attached to after that
16:22:37 <Sukhdev> devananda: is that what you were asking?
16:22:47 <jroll> right, so the question is with no ports attached
16:22:55 <devananda> righ
16:22:57 <devananda> right
16:23:07 <jroll> devananda: so, that will depend on what config the ml2 mechanism lays down I guess
16:23:20 <vsaienko> devananda, probably you have to use other network provider than neutron_plugin
16:23:39 <devananda> vsaienko: can that be configured through neutron?
16:24:04 <jroll> so really there's two options here:
16:24:26 <jroll> 1) convince ml2 mech devs to put down a sane (configurable) config when no ports are attached
16:24:28 <vsaienko> devananda: as it was mentioned by Sukhdev, ML2 will update VLAN on the switch port when you call update/create port in neutron
16:24:51 <jroll> 2) don't remove provisioning net at tear down time, but rather keep it on the provisioning network all the time, except when it shouldn't be
16:25:00 <jroll> (2) is what we do downstream today
16:25:16 <jroll> and I feel like that isn't terrible
16:25:18 <devananda> jroll: gotcha. I actually want it to be on a *different* network sometimes
16:25:24 <vsaienko> I think that if you create port by hand with local_link_info ML2 should do the trick with VLAN
16:25:31 <devananda> but I agree that (2) isn't horrible
16:25:42 <jroll> devananda: well, you'd have to configure that network in neutron and manually port-create/port-update, I think
16:26:00 <vsaienko> jrol: right!
16:26:13 <jroll> I think (2) is a good start, and we can work on a good solution for "I want to go to arbitrary network in manageable"
16:26:23 <devananda> vsaienko: "create port by hand" -- how would I tell neutron to bind that port to these MACs, without involving Ironic?
16:26:45 <jroll> devananda: use the same api calls as ironic does
16:27:06 <devananda> jroll: oh. of course :)
16:27:14 <jroll> I am curious on the use case, but this seems like a valid case in general
16:27:36 <Sukhdev> devananda : neutron allows you to create ports on any (valid) network
16:27:53 <Sukhdev> and then you can issue update port to bind it
16:27:58 <devananda> jroll: enable network access from existing management systems on a static VLAN
16:28:05 <vsaienko> devanada: if you add local_link_information neutron will update VLAN on the switch
16:28:34 <vsaienko> http://paste.openstack.org/show/484169/
16:28:49 <devananda> jroll: but yea, I agree that (2) is a good start. sounds like this is easily doable downstream right now, and something we can work on next cycle
16:29:33 <vsaienko> if I as user can create a neutron port and pass fake local_link_info it can break connectivity to HW nodes
16:29:51 <devananda> vsaienko: oooh. that's a really good point
16:30:10 <jroll> devananda: yeah, here's an example of a thing we have to manually put something on the rescue network, for instance. parameters will be different from upstream stuff, but you get the idea: https://gist.github.com/jimrollenhagen/0b53c5e4f5f185a14594
16:30:13 <devananda> vsaienko: we want to allow end-users to define neutron subnets, but not affect the ports for these instances. yes?
16:30:26 <sambetts> What happens when there are no ports attached is something I've been thinking about for introspection too, because with inspection we might not even have ports yet
16:30:52 <devananda> jroll: cool
16:30:59 <devananda> sambetts: indeed
16:31:51 <devananda> sambetts: so telling neutron "by default, on switch S, put all switchports on provider net N" seems like a useful thing
16:32:37 <sambetts> thats the only solution we could think of
16:33:05 <sambetts> whether thats the provisioning vlan or a different one it
16:33:18 <sambetts> as long as there is a known vlan
16:33:57 <Sukhdev> devananda : you mean to say - issue neutron port-create to put these ports on net N, right?
16:34:57 <sambetts> its more like, when I delete the final neutron port on a specific switch port I want it to fall back to a specific known VLAN
16:35:10 <devananda> Sukhdev: not quite
16:35:27 <vsaienko> sambetts: I think it should be done on ML2 side
16:35:39 <devananda> sambetts: yes. also, if I don't yet know what is connected to some switchports, put that traffic on VLAN N
16:35:56 <vsaienko> I mean, when neutron delete/unbind port, ML2 should move it to some default VLAN
16:36:08 <sambetts> +1
16:36:16 <Sukhdev> devananda : neutron needs to be told explicitly as to which port should be connected to which network -
16:36:44 <devananda> I also didn't mean to sidetrack the meeting too much onto a feature request -- I wasn't sure if this was possible today, and ya'll have confirmed that it isn't
16:39:00 <Sukhdev> devananda : just a final thought on this - it seems like a network flip on the reverse side (i.e. on tear down)
16:39:07 <devananda> Sukhdev: yep
16:39:53 <Sukhdev> devananda : We should simply drive it the same way from ironic side -
16:41:04 <sambetts> Sukhdev: for our case (inspection) that wouldn't be so successful because we might not have any port information on the ironic side
16:42:05 <Sukhdev> sambetts : Interesting!! so, how will neutron know which ports to act on?
16:42:51 <sambetts> Sukhdev: exactly, thats why it might need to be built into neutron to have a fall back to this vlan action, when all ports are unbound from a switch port
16:44:03 <Sukhdev> sambetts: I think we are assuming too much here -
16:44:37 <Sukhdev> when a port is unbound, it is not plumbed (to my understanding) -
16:45:06 <Sukhdev> if port needs to be connected to any vlan (default or otherwise) it needs to be bound to a network
16:45:33 <Sukhdev> a network is a network - default or otherwise
16:46:06 <Sukhdev> somebody needs to issue port create/updates to bind the ports correctly to desired network
16:46:25 <Sukhdev> and I think that responsibly lies on the ironic side
16:46:44 <Sukhdev> or someone has to do it manually (like operator)
16:47:25 <Sukhdev> does it make sense?
16:47:56 <Sukhdev> Wow!! I did not realize the time - we have only 13 min left
16:48:08 <jroll> well, ml2 mechanisms could be written to by default put configs down to be on a configurable network
16:48:11 <jroll> but yeah, time
16:49:21 <Sukhdev> I wanted to cover one item which we left off last metting
16:49:55 <Sukhdev> #topic: Discussion regarding Ironic inspector to set the switch-id, switch-info
16:50:19 <Sukhdev> sambetts: you had brought up the issue in last meeting regarding the format of the switch-id
16:50:55 <Sukhdev> presently, the code expects switch-id to be of mac-address format
16:51:10 <Sukhdev> otherwise the CLI returns error
16:51:24 <sambetts> Yeah, so this was something that we (Cisco) have been discussing, because our ml2 driver uses the mgnt ip address of the switch to identify it, so limiting it to being just a mac address will lead us to ignore that field entirly
16:51:35 <Sukhdev> yhvh: please chime in
16:52:30 <yhvh> I spent a lot of time enforcing the switch-id format to be either mac or datapath-id
16:52:42 <sambetts> my understanding was that all the fields in local_link_information where going to be vendor specific because they are ml2 implemention specific
16:52:49 <yhvh> by request, design and spec
16:52:53 <Sukhdev> when we discussed this in Vancouver summit - folks wanted to use switch-info for management IP address not switch-id
16:53:30 <sambetts> I don't remember these discussions (I was in all the sessions) :/
16:54:12 <Sukhdev> sambetts : HP person (do not remember the name) walked through this scenario
16:54:26 <Sukhdev> sambetts : It may be captured somewhere on the etherpad
16:54:58 <sambetts> its also not in the spec :(
16:55:12 <Sukhdev> sambetts: lets make sure we address your concern
16:55:52 <Sukhdev> sambetts: so, you want to be able to identify the switch by IP, can it not be specified in switch-info field?
16:56:15 <sambetts> Sukhdev: it could but then the switch_id field is wasted in our implementation
16:57:00 <Sukhdev> sambetts : what happens if you have two different switches (say 3K and 9K) and use different config commands for the same port-update command?
16:57:17 <Sukhdev> how do you tell it is 3K or 9K? and hence, which configs to push?
16:57:39 <Sukhdev> sambetts : ofcourse, I am making up numbers to elaborate an example :-)
16:57:41 <sambetts> we can use the switch_info field for that
16:58:15 <sambetts> either that or its pre-setup in our .ini file
16:58:35 <Sukhdev> the idea is to automate as much as possible -
16:59:13 <sambetts> how does making it a mac address help this?
16:59:29 <Sukhdev> my understanding is LLDP will provide the ID in mac-address format
16:59:44 <sambetts> we can get the mgnt IP from LLDP
17:00:26 <Sukhdev> correct - mgmt IP can move from switch to switch - but, mac usually is tied to the chassis
17:00:44 <Sukhdev> the idea is switch-id is tied to the chassis -
17:00:55 <sambetts> our ML2 implementation still identifys switchs by IP though so it doesn't make a difference
17:01:57 <Sukhdev> hmm... sorry we are again out of time -
17:02:19 <Sukhdev> I will keep it on the agenda and try to get it closed by next meeting :-):-)
17:02:25 <sambetts> thanks
17:02:28 <yhvh> ty
17:02:32 <Sukhdev> yhvh : in the mean time, can you think about it as well -
17:02:38 <Sukhdev> Thanks folks
17:02:42 <Sukhdev> bye
17:02:53 <Sukhdev> #endmeeting