16:00:42 <Sukhdev> #startmeeting: ironic_neutron
16:00:42 <openstack> Meeting started Mon Feb  8 16:00:42 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:46 <openstack> The meeting name has been set to '__ironic_neutron'
16:00:51 <Sukhdev> #topic: Agenda
16:00:55 * devananda lurks in two meetings at once
16:00:59 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_February_8.2C_2016
16:01:19 <Sukhdev> #topic: Annoucements
16:01:54 <Sukhdev> anybody wants to make any annoucement?
16:02:06 <Sukhdev> jroll is not available today
16:02:08 <davidlenwell> o/
16:02:12 <jroll> morning
16:02:16 <jroll> I'm kinda here
16:02:28 <Sukhdev> jroll : oh good
16:02:42 <Sukhdev> So, couple of things -
16:03:05 <Sukhdev> We got 4 patches merged last week
16:03:27 <Sukhdev> I have updated the etherpad to reflect this - https://etherpad.openstack.org/p/ironic-neutron-mid-cycle
16:04:11 <vsaienko> morning to all
16:04:19 <Sukhdev> there is network flip patch that still has few comments to be addressed, it will be nice to get that merged as well
16:04:43 <Sukhdev> https://review.openstack.org/#/c/206244/
16:05:32 <devananda> Sukhdev: that and the immediately-following patch are the only REST API changes needed, correct?
16:05:43 <devananda> *in Ironic
16:06:26 <Sukhdev> devananda : actually I made mistake - posted wrong link - hang on
16:07:05 <Sukhdev> I meant this one - https://review.openstack.org/#/c/139687/
16:07:15 <Sukhdev> network flip patch
16:07:47 <Sukhdev> and this one too - https://review.openstack.org/#/c/213262/
16:08:35 <devananda> ahh ok
16:09:33 <vsaienko> Sukhdev: I will update https://review.openstack.org/#/c/213262/ today according to Devananda's comments
16:09:51 <Sukhdev> vsaienko : cool - thanks
16:10:32 <Sukhdev> with these two merged, then we will be left with the API and devstack patches (and of course nova - which will land later)
16:11:04 <jroll> nova is waiting on the client patches as well
16:11:19 <Sukhdev> devananda: to answer your question, earlier patch that I posted is the only API (along with another client patch)
16:11:28 <Sukhdev> jroll : right
16:12:46 <devananda> Sukhdev: the second patch also has API changes, eg https://review.openstack.org/#/c/139687/58/ironic/api/controllers/v1/node.py
16:13:39 <Sukhdev> oh - :-)
16:13:45 <devananda> I'll try to rally folks around reviewing those first two ironic patches more this week, so we can nail down the REST API changes
16:14:12 <devananda> fwiw, most of the patches after those should be _much_ easier to land
16:14:23 <Sukhdev> devananda : that would really help
16:15:16 <Sukhdev> In terms of testing, these patches all seem to working fine in my setup
16:15:28 <Sukhdev> I have not tested portgroups -
16:15:42 <Sukhdev> Has anybody tested portgroups?
16:16:14 * devananda has not
16:16:16 <jroll> devananda: +1, that will let us unleash the client and then nova changes
16:16:52 <vsaienko> Sukhdev, I will try to add portgroup support to devstack
16:17:24 <devananda> vsaienko: where are we with an infra job to test all of this?
16:17:26 <sambetts> Has there been a discision made on how we're meant to be doing the host side PG config?
16:17:31 <sambetts> decision*
16:18:00 <sambetts> node side*
16:18:04 <vsaienko> Sukhdev: the patch is on review https://review.openstack.org/#/c/252814/
16:18:49 <vsaienko> Sukhdev, but I can't merge generic_switch code to openstack.org repo, until https://review.openstack.org/#/c/276200/ is merged
16:19:59 <Sukhdev> who needs to approve vsaienko's second patch?
16:22:42 <devananda> that should be an easy one for infra to land
16:24:28 <Sukhdev> vsaienko : does netmiko requirement belongs to global requirements or can it go into local repo?
16:24:39 <devananda> Sukhdev: must be in g-r
16:24:50 <devananda> so that it can be installed / used in the gate env
16:25:18 <Sukhdev> oh - I see
16:25:31 <vsaienko> I just paged folks at infra channel
16:26:32 <Sukhdev> OK - I will ping infra folks later as well - hopefully we will get folks attention on this
16:27:25 <Sukhdev> Anything else on the patches?
16:27:52 <Sukhdev> Actually there is one - https://review.openstack.org/#/c/269157/ - for tempest testing
16:29:31 <vsaienko> I will rebase  https://review.openstack.org/#/c/269157 on the top of https://review.openstack.org/#/c/265311/
16:30:12 <Sukhdev> vsaienko : that would be nice - thanks
16:30:59 <Sukhdev> that does it for all the patches - unless anybody has anything else
16:31:49 <Sukhdev> #topic: Open Discussion
16:32:05 <Sukhdev> Is there anything else we need to discuss?
16:32:24 <Sukhdev> Actually sambetts had asked a question -
16:32:39 <sambetts> Re: portgroups, what is the current plan for the bonding on the node side
16:33:21 <vdrok> as for this tempest patch - https://review.openstack.org/#/c/269157/ - it requires at least 2 "baremetal" vms to run (and currently it will be 3)
16:33:33 <vdrok> we still have only one right?
16:34:57 <Sukhdev> vdrok : did not understand your question
16:35:10 <jroll> sambetts: as in, pushing the config to the instance?
16:35:17 <vdrok> Sukhdev, IIUC in gate we have only one node to run instance on
16:35:23 <Sukhdev> I thought this test will launch the needed bms
16:35:32 <sambetts> jroll: yeah, configuring the bond on in the OS
16:35:39 <vdrok> that tempest test boots 2 instances
16:35:53 <devananda> vdrok:  we create 3 today
16:36:06 <vdrok> devananda, ah, ok then :)
16:36:11 <jroll> sambetts: yeah, so we'll need to do some work to push vlans and bonding metadata into nova's metadata about the instance, and then add to cloud-init etc if it isn't there already
16:36:16 <jroll> that'll have to be next cycle
16:37:00 <sambetts> jroll: so we can't really test the portgroup functionality until next cycle then
16:37:09 <sambetts> not with a full tempest anyway
16:37:11 <devananda> I believe cloud-init/simple-init can do bonding, but yea, we'll have to pass it through nova
16:37:25 <vsaienko> jroll, why instance should know about vlans? I think that is should know only which link aggeregation protocol is used (LaCP/Pagp) and mode
16:37:41 <devananda> vsaienko: instance should not know about vlan's, but it must know about port bonding
16:37:58 <jroll> sambetts: we can't test connectivity but we can test the apis and such
16:38:02 <devananda> jroll: oh. yea. we don't push VLAN data down to instance
16:38:12 <jroll> vsaienko: devananda: it... depends :)
16:38:28 <devananda> jroll: huh?
16:38:53 <jroll> instance needing to know about vlans depends (I think?)
16:39:08 <vsaienko> jroll, you are talking about case when Instance is connected to several networks right?
16:39:13 <jroll> vsaienko: correct
16:39:22 <sambetts> I'm working on putting together an RFE for unlocking the number of tenent networks by having vEths do the tagging in the tenant os
16:39:43 <sambetts> if anyone's interested
16:39:44 <jroll> sambetts: ++ that's how our deployment works
16:39:44 <vsaienko> I thought about it, I don't like current connection scheme. We connection all ports to single network which is not right
16:40:11 <jroll> vsaienko: yeah, I think we left "multiple networks on one physical connection" to next cycle
16:40:17 <vsaienko> we should connect only specific port to network. And left all other unplugged
16:41:52 <Sukhdev> vsaienko : see long term items on the meeting wiki page (at the bottom)
16:43:56 <Sukhdev> sambetts : I did not follow your point on RFE for multiple networks -
16:44:21 <Sukhdev> sambetts: are you taking about vlan aware vms?
16:44:43 <Sukhdev> connecting a port to multiple networks?
16:45:24 <sambetts> if you want to make a generic solution for baremetal that allows for more tenant networks than physical ports, unless you have some hardware magic you have to tag inside the os
16:45:50 <sambetts> so 1 physical port N number of tenant networks
16:46:10 <sambetts> or 1 lag N number of tenant networks
16:46:47 <Sukhdev> sambetts: there is an initiative in neutron called vlan aware vms - have you looked at that?
16:47:06 <Sukhdev> I do not have link handy -
16:47:17 <sambetts> No, I've not seen it, I've only been approaching it from the Ironic perspective
16:47:54 <Sukhdev> essentially, that provides the support for connecting a port to multiple networks -
16:48:33 <jroll> Sukhdev: are people finally working on that?
16:48:53 <Sukhdev> jroll : yes it is actively being worked on
16:49:12 <Sukhdev> I think they are trying to get it into mitaka
16:49:44 <Sukhdev> sambetts : unfortunately, I do not have link handy - ping me later and I will look it up for you
16:49:53 <sambetts> I think I've found it
16:49:58 <Sukhdev> there is a concept of port and sub-port -
16:49:59 <jroll> Sukhdev: cool, glad to hear it
16:50:29 <Sukhdev> port is access port (native vlan) and sub-port is tagged vlans
16:51:09 <sambetts> Sukhdev: thats very interesting! I wonder how they are dealing with the VM side
16:51:18 <devananda> sambetts: vlan-aware ironic instances is definitely interesting to some folks.
16:51:37 <jroll> very much so :)
16:51:48 <sambetts> yup :D
16:51:49 <Sukhdev> VM side is all OVS magic :-)
16:52:12 <jroll> right, for baremetal that will have to be magic in the switch
16:52:15 <sambetts> Sukhdev: if its not inside the VM itself then it won't work for BM
16:52:30 <devananda> Sukhdev: one of the things I hope to test in the next week or two is using OVN instead of ML2 with this work
16:52:35 <Sukhdev> there are many use cases for this - and it becomes very compelling for bare metal services -
16:52:58 * jroll looks at arista CVX and vlan->vxlan translation in the switch
16:53:28 <Sukhdev> devananda : yup Kyle is looking into it as well - he pinged me for it as well
16:53:32 <devananda> cool
16:53:33 <jroll> sambetts: they almost certainly inject the vlan info into the instance as well, if it's truly "vlan aware VMs"
16:53:46 <sambetts> I can't see anything in the spec about it though :/
16:53:51 <Sukhdev> devananda : let me know if you need any help with OVN - Ironic integration - will be glad to help
16:54:21 <jroll> sambetts: yikes, so maybe they're waiting til next cycle for the nova parts?
16:55:09 <sambetts> I need to read into it more, but yeah
16:55:46 <Sukhdev> sambetts : I would suggest you reach out to the implementor of that BP
16:55:51 <jroll> sambetts: https://review.openstack.org/#/c/213644/1/specs/mitaka/approved/trunk-port.rst
16:56:08 <jroll> so yeah, looks like next cycle
16:56:42 * devananda saves to read that later
16:57:05 <Sukhdev> jroll : there is counterpart on the neutron side as well
16:57:16 <sambetts> https://review.openstack.org/#/c/243786/11/specs/mitaka/vlan-aware-vms.rst
16:57:40 <Sukhdev> yup - that one -
16:57:47 <jroll> Sukhdev: I know, sam was asking about the instance side :)
16:58:14 <devananda> #link https://review.openstack.org/#/c/243786/11/specs/mitaka/vlan-aware-vms.rst
16:58:17 <devananda> #link https://review.openstack.org/#/c/213644/1/specs/mitaka/approved/trunk-port.rst
16:59:31 <sambetts> jroll: I hope to have a session about my RFE at the midcycle, I need to put my ideas together then I'll put it on the etherpad agenda
16:59:41 <devananda> jroll, Sukhdev: fwiw, I think glean (simple-init) already supports the network info structures that those propose to pass down to the instance
16:59:46 <jroll> sambetts: awesome, thanks
16:59:50 <jroll> devananda: woot
17:00:10 <sambetts> devananda: it doesn't but there are a few bits e.g. vlans missing unfortunatly
17:00:30 <Sukhdev> sambetts : when you write something up, please share with us
17:00:34 <devananda> sambetts: cloud-init doesn't? or simple-init doesn't?
17:01:11 <sambetts> devananda: simple-init, I was looking through the code this morning, although I might have missed something, I think its planned work
17:01:31 <Sukhdev> folks - sorry, we are out of time -
17:01:35 <sambetts> the cloud-init support is even worse I think
17:01:47 * devananda notes the time ...
17:01:56 <Sukhdev> sambetts : it will be nice if you can describe it in next meeting -
17:02:08 <Sukhdev> time is up
17:02:14 <sambetts> Sukhdev: sure I'll try to have something together by then
17:02:15 <Sukhdev> thanks for attending folks
17:02:20 <sambetts> thanks for the conversation
17:02:21 <Sukhdev> bye
17:02:31 <Sukhdev> #endmeeting