16:00:42 <Sukhdev> #startmeeting ironic_neutron
16:00:43 <openstack> Meeting started Mon May 16 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:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:47 <openstack> The meeting name has been set to 'ironic_neutron'
16:01:06 <Sukhdev> #topic: Agenda
16:01:10 <hshiina> o/
16:01:17 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_May_16.2C_2016
16:01:19 <sambetts> o/
16:01:53 <Sukhdev> #topic: Announcements
16:02:11 <Sukhdev> I got no announcement - anybody else does?
16:02:36 <sambetts> Nothing that isn't covered by follow topics :)
16:02:43 <sambetts> following*
16:02:50 <jroll> \o
16:03:19 <Sukhdev> #topic: VLAN Aware Instances
16:03:34 <Sukhdev> sambetts: thanks for pushing updated spec
16:03:48 <sambetts> thanks for the comments :)
16:03:49 <Sukhdev> #link: https://review.openstack.org/#/c/277853
16:04:10 <Sukhdev> Overall it looks good
16:04:25 <Sukhdev> needs some beefing up and some cleanup
16:05:49 <Sukhdev> One thing is not very clear in my mind - that is, are we going to ask the operators to create the trunk ports in some case or not
16:05:58 <sambetts> no, operators != users
16:06:19 <Sukhdev> OK - I mean admins
16:06:32 <sambetts> that'd be like saying that admins should pre-create ports for users today
16:07:23 <sambetts> which isn't a thing that happens as far as I know is it? An admin creating an un-bound port for a tenant to use?
16:08:15 <Sukhdev> not port, but, shared networks, Yes
16:08:41 <Sukhdev> if a network needs to be shared by tenants, admin creates it
16:08:59 <sambetts> right, a port can't be shared though
16:09:39 <Sukhdev> so, we are saying ironic driver will always create the trunk ports
16:10:22 <sambetts> no, they can be created by a user
16:11:10 <Sukhdev> so, that was my original question - for BM deployments, when do we expect users to do it, and when do we create automatically
16:11:18 <Sukhdev> that is a bit fuzzy
16:11:23 <sambetts> thats all covered in my examples
16:12:24 <Sukhdev> examples cover how nova boot will be issued - I thinking more from the use-case point of view
16:13:08 <Sukhdev> say I want to use BM as a cache server (or for containers) - and will be shared by many tenants -
16:13:29 <sambetts> a nova instance shared by multiple tenants?
16:14:18 <jroll> O_o
16:15:06 <Sukhdev> ilke a hypervisor -
16:15:15 <Sukhdev> shared by many tenants
16:15:33 <sambetts> well that would be a instance owned by a single tenant in the undercloud
16:15:34 <Sukhdev> instead of compute resource, it is a service resource
16:17:31 <Sukhdev> I was thinking manila type deployment - where a BM is running a shared file system
16:17:59 <sambetts> So the use cases I've drawn out in my examples are:
16:18:14 <sambetts> A user who hasn't precreated any neutron ports
16:18:22 <sambetts> a user who has precreated neutron ports
16:18:32 <sambetts> a user who has precreated neutron trunks
16:19:41 <sambetts> If your talking about an instance plumbed into a shared network by an admin, so that multiple tenants can access it, then it could be any one of those cases depending on the workflow of the admin
16:19:47 <Sukhdev> but, how does user know for what use case he needs to create ports?
16:19:57 <sambetts> thats down to the user to decide
16:20:04 <sambetts> just as it would be today with a VM
16:21:01 <Sukhdev> yes, so, you just pointed a use-case, where the admin has to create the trunk port -
16:21:20 <jroll> not "has to", "chooses to"
16:23:01 <Sukhdev> jroll: so, that is what I think is bit fuzzy, and we should clarify (in spec or documentation) - when it is required and when it is done automatically
16:23:23 <jroll> Sukhdev: it should never be required
16:23:32 <jroll> all you should need to boot a server is a network
16:23:37 <jroll> no matter what the server is
16:23:45 <jroll> (virt, bare metal)
16:23:52 <jroll> (one nic, twenty nics)
16:25:15 <Sukhdev> so, you are saying boot a server to a network and ironic driver will figure out, it is trunk port, sub-port, etc...
16:25:21 <jroll> now, if folks want to fancy things moving ports or trunks or whatever around, we should try to enable that
16:25:31 <jroll> yes, ironic/nova will create ports and such as needed
16:26:01 <sambetts> Example case 1: nova boot --nic net-id=<uuid>
16:26:38 <Sukhdev> OK then it makes sense -
16:27:11 <Sukhdev> sambetts : somehow I got the sense by reading spec that some times admins do things and other times it is done automatically
16:27:19 <Sukhdev> what jroll said makes sense
16:27:54 <sambetts> might just a be poor explaination by myself XD jroll could you do a proof read?
16:28:06 <jroll> sure
16:28:13 <Sukhdev> Lets circle back when others have chance to review the spec as well
16:28:23 <sambetts> :) cool
16:28:27 <Sukhdev> Moving on....
16:28:40 <Sukhdev> #topic: Critical patches and merge plan
16:29:25 <Sukhdev> I saw Ruby's comment on one of the patches they are (at least one) is being broken down
16:29:55 <Sukhdev> in response to hshiina's comment
16:30:17 <hshiina> yes
16:30:31 <Sukhdev> anybody has any update on this?
16:30:46 <Sukhdev> We came this far and now we seem to be stuck :-):-)
16:31:50 <sambetts> So I added a point to the Agenda that could also cause the portgroups stuff to be stuck for a little while longer while we do some digging, sorry :(
16:33:03 <Sukhdev> I guess Vasyl is working on that patch
16:33:10 <sambetts> Seems like my problems with the network driver data migrations have been addressed, I'd like devananda to maybe try it out for us as I know he was running dhcp_provider=None
16:33:17 <Sukhdev> sambetts : I tricked you by switching the order :-)
16:33:24 <sambetts> Sukhdev: ;)
16:35:01 <Sukhdev> So, I take it we do not have any update and I do not see vasyl here -
16:35:15 <Sukhdev> so, lets go back to sambetts's agenda item then
16:35:55 <vsaienko1> o/
16:36:45 <Sukhdev> vsaienko1: thanks for joining  - any update?
16:37:34 <vsaienko1> Sukhdev, I'm sorry for late, yes I'm splitting network driver's patch https://review.openstack.org/#/c/285852
16:38:13 <Sukhdev> vsaienko1 : cool - thanks for jumping in to help out
16:38:28 <vsaienko1> Sukhdev, not sure if all knows but we had a green job for multitenancy at the gates
16:39:01 <sambetts> \o/
16:39:15 <vsaienko1> but it was some time ago https://review.openstack.org/#/c/296432
16:40:06 <vsaienko1> that is all from side
16:40:47 <Sukhdev> jroll : we are OK with the other three patches as-is - just the one needs to be broken up, right?
16:41:22 <jroll> Sukhdev: the two big ones
16:41:26 <jroll> er
16:41:32 * jroll wonders how big the portgroup patch is
16:41:55 <jroll> yeah, I think just the one is fine
16:42:17 <Sukhdev> cool - thanks
16:42:23 <Sukhdev> vsaienko1 : thanks for the update
16:43:08 <Sukhdev> #topic: Rumor about boding support for virt
16:43:17 <Sukhdev> sambetts: want to elaborate?
16:44:19 <sambetts> Ok, so basically johnthetubaguy was discussing with us in the ironic channel that there seems to be work going on to support bonding for all instances, including virt
16:45:01 <Sukhdev> hmm...any pointers, links to work?
16:45:11 <sambetts> to support bonding for all instances we should model it in neutron instead of doing it behind neutrons back
16:45:26 <sambetts> Sukhdev: this was the spec he'd pointed us at https://review.openstack.org/#/c/182242/14/specs/newton/approved/user-controlled-sriov-ports-allocation.rst
16:45:33 <sambetts> although I'm not sure :/
16:45:56 <sambetts> If we decide to model bonding in neutron, there is no longer a need to model it in ironic \
16:46:28 <Sukhdev> oh - I see this is nova spec
16:46:32 <sambetts> therefore if that is truely going to happen I think we should hold of merging the portgroups API, as it'll be made redundant
16:46:47 <sambetts> and be hard to remove after
16:47:16 <Sukhdev> Let me follow up in the neutron side and dig up and see if anything like this is happening and more importantly in what time frame
16:47:40 <Sukhdev> #link: https://review.openstack.org/#/c/182242/14/specs/newton/approved/user-controlled-sriov-ports-allocation.rst
16:48:11 <Sukhdev> #action: Sukhdev to check on the neutron side if there is any work going on to support bonding
16:48:54 <Sukhdev> anything else on this?
16:49:20 <Sukhdev> #topic: Ironic interface attach API
16:49:27 <Sukhdev> sambetts: back to you
16:49:31 <sambetts> Me again :D
16:49:55 <Sukhdev> #link: https://bugs.launchpad.net/ironic/+bug/1582188
16:49:56 <openstack> Launchpad bug 1582188 in Ironic "[RFE] Add interface attach API" [Wishlist,Confirmed] - Assigned to Sam Betts (sambetts)
16:50:22 <Sukhdev> sambetts : well that is the price of putting it on the agenda, dear :-):-)
16:51:10 <Sukhdev> sambetts: I have not looked at it - what is this about?
16:51:27 <sambetts> Ok, so basicly we'll soon have pluggable network interfaces in Ironic, this is all well and good, except that we can't modify the port mapping process without writing a new nova virt driver, and this process also might be different per network interface, which can then be different per node
16:52:35 <sambetts> as an example my out of tree network driver, did port mapping a lttle differently to support our use case and because of that I had to have a nova driver too
16:53:21 <sambetts> this RFE proposes moving the port mapping/interface attachment logic out of the virt driver down into Ironic into the network interface, under an API
16:53:48 <sambetts> which could be called by nova at the point we do the port-update with vif_port_ids today
16:54:55 <sambetts> this hides the implementation details from the nova virt driver, and would allow us to iterate faster too, e.g. to support my VLAN spec we wouldn't need to to modify the plug_vifs logic, only the network interface
16:56:11 <Sukhdev> Oh I see - in the very early days when we kicked off ironic-neutron integration work, that was one of the things we considered, but, we chose not to follow that path
16:57:19 <Sukhdev> this is an interesting idea though
16:58:01 <Sukhdev> Let circle back on this in next meeting
16:58:24 <Sukhdev> hshiina had a item on the agenda, we could not get to it last week as well
16:58:54 <hshiina> we need to get nova patches merged after ironic and ironc client pathces.
16:59:09 <hshiina> nova's deadline is earlier than usual.
16:59:34 <Sukhdev> jroll is usually on top of nova side
16:59:43 <hshiina> i listed nova's patch for confirmation.
17:00:51 <Sukhdev> I am so sorry - I kind of lost track and we are out of time again
17:01:00 <hshiina> are these 2 pathces all?
17:01:18 <Sukhdev> jroll : can you please look at this offline?
17:01:31 <jroll> Sukhdev: look at what
17:01:52 <Sukhdev> jroll : two patches that hshiina is referring to on the agenda
17:02:11 <Sukhdev> sorry - folks we are out of time - have to clear the channel
17:02:17 <Sukhdev> thanks for attending the meeting
17:02:21 <Sukhdev> bye
17:02:21 <hshiina> ok. thanks.
17:02:23 <sambetts> Thanks for giving me the time
17:02:25 <sambetts> :)
17:02:31 <Sukhdev> #endmeeting