16:02:13 <sambetts> #startmeeting ironic_neutron
16:02:14 <openstack> Meeting started Mon Sep 26 16:02:13 2016 UTC and is due to finish in 60 minutes.  The chair is sambetts. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:19 <openstack> The meeting name has been set to 'ironic_neutron'
16:02:28 <sambetts> o/
16:03:38 <sambetts> Hi all, unfortunatly I've been unable to create a new agenda this week because of OpenID issues so we'll use 12/09/2016s agenda again
16:03:41 <sambetts> #link https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_September_12.2C_2016
16:04:06 <sambetts> #topic Announcements
16:04:55 <sambetts> Ironic Newton has been cut, and Ocata development is now open
16:05:04 <mjturek> \o/
16:05:20 <mjturek> has the portgroups -2 been lifted?
16:05:23 * mjturek checks
16:05:23 <sambetts> jroll: I believe this means we can get on with the portgroups etc features right? ^^
16:05:41 <jroll> ohai
16:05:46 <jroll> sambetts: yes, yes we can :)
16:05:50 <sambetts> \o/
16:05:56 <mjturek> -2 is still there from jlvillal
16:06:21 * jlvillal will remove that!
16:06:26 <sambetts> jroll: Do you know if its the same for Nova/ironic client, or are we still blocked on that side?
16:07:39 <jroll> sambetts: nah, it's open
16:07:41 <mjturek> thanks jlvillal :)
16:07:49 <jlvillal> mjturek: Done
16:07:50 <jroll> er
16:07:52 <jroll> s/nah/yes
16:08:09 <sambetts> Full steam ahead then :D
16:08:45 <sambetts> any other announcements?
16:09:23 <Sukhdev_> Playing with IRC on my iPhone - it is cool
16:09:34 <sambetts> hey Sukhdev_
16:10:39 <Sukhdev> sambetts: thanks for running the meeting - I am on the road and just tried my iPhone - it actually worked pretty good :-)
16:10:59 <sambetts> I'll take silence as no other announcements, moving on:
16:11:02 <sambetts> #topic Security Groups for Baremetal depoloyments
16:11:17 <sambetts> Sukhdev: I'm not sure how much you can talk, but any updates here?
16:11:39 <jroll> we blocked that for newton, I believe it's in a landable state
16:11:48 <Sukhdev> sambetts: no update - the patch is good to go -it is good to go
16:11:49 <jroll> was just a bit late
16:12:36 <sambetts> #info Sec Group patch in landable state, Ocata now open, lets get some reviews on it
16:12:51 <Sukhdev> jroll sambetts: give it a review - I will be back in office on Thursday - if any comments, I can address then
16:13:07 <sambetts> Awesome thanks Sukhdev :)
16:13:10 <jroll> sure
16:13:24 <sambetts> anything else on this topic?
16:13:39 <sambetts> #topic Port Groups
16:14:40 <sambetts> So jlvillal has lifted his -2, I believe these are also in or close to a landable state?
16:14:56 <jroll> I have a (not so?) quick question on this
16:15:07 <jroll> apparently vdrok has a spec up about using portgroups on the tenant networks
16:15:25 <jroll> which implies that the current work is only about deployment networks
16:15:34 <jroll> that surprised me, is that true or am I missing something?
16:15:37 * jroll finds link
16:15:42 <sambetts> No thats not true
16:16:17 <jroll> https://review.openstack.org/#/c/278564/
16:16:21 <jroll> oh wow that's super old >.>
16:16:25 <sambetts> and in fact using portgroups in the deployment networks won't work for things like PXE
16:16:37 <jroll> right, that made me extra confused
16:16:43 <jroll> I can shut up now, thanks sambetts  :)
16:17:28 <sambetts> I believe there is still a peice of the puzzle missing right now with regards to the portgroups
16:17:41 <sambetts> the config drive
16:17:46 <sambetts> and the network_data.json
16:18:06 <jroll> right
16:18:08 <sambetts> without that we won't configure the bond inside the instance
16:18:24 <jroll> we need to get that rolling this cycle
16:18:29 <sambetts> ++
16:19:16 <sambetts> so I've done some work with regards to it, glean now has full support for network_data.json
16:19:26 <sambetts> but I believe cloud-init needs work
16:20:06 <jroll> probably, we may have some patches laying around for this
16:20:22 <sambetts> and I'm not sure my way of generating the information it on the nova side will fly very far even though it works
16:20:42 <jroll> yep
16:20:47 <jroll> neutron doesn't have bonds yet, right?
16:21:07 <sambetts> no, and when talking to people about it, there are no plans for it either
16:21:24 <sambetts> there was a rumour which turned out to be incorrect
16:21:24 <jroll> ah, right, only trunks
16:21:29 <Sukhdev> what do you mean by bond in neutron?
16:21:42 <jroll> Sukhdev: a model for bonded ports
16:22:10 <Sukhdev> customers use VMs with bonded interfaces
16:22:22 <Sukhdev> bonds are hypervisor (nova) thing
16:22:26 <Sukhdev> not neutron
16:22:32 <jroll> I understand
16:22:56 <jroll> if neutron had a data model for this, we could use it so that the nova model would be correct, rather than hacking up the metadata
16:23:00 <sambetts> Sukhdev: VMs with bonded interfaces or compute hosts with bonded interfaces?
16:23:03 <jroll> but it doesn't, we can move on :P
16:23:03 <Sukhdev> you can have a VM with multiple nicks and bonded in the hypervisor - neutron just sees it as a port
16:23:21 <Sukhdev> sambetts: VMs -
16:23:47 <sambetts> oh interesting, are they user defineable?
16:23:48 <vdrok> sambetts: jroll I'm afk at the moment, but yeah, looking at the configure tenant networks it does handle port groups, so the only thing is configdrive, have not updated this for a while
16:24:04 <sambetts> #link https://review.openstack.org/#/c/289412/1
16:24:42 <sambetts> ^ This is my code that creates network_data.json in the config drive, its based on portgroups + my VLAN aware stuff
16:24:55 <sambetts> but we could split it
16:26:13 <sambetts> the real question I have is how intergrated or not we want to be with Nova on this stuff, e.g. we can keep it all in the driver, or we can put some of it in the common nova metadata module
16:27:43 <jroll> I'd like to, for the sake of not being special, if nothing else
16:27:56 <jroll> I think we'll need a conversation with nova folks on this
16:28:01 <sambetts> ++
16:28:02 <jroll> maybe it's an os-vif plugin, dunno
16:29:30 <jroll> anyway, let's review what we've got and I'lll see if we can set something up with nova peeps
16:29:35 <sambetts> ++
16:30:26 <sambetts> Ok we people have no objections I'll move onto the next topic:
16:30:46 <sambetts> #topic Ironic Interface attach API
16:32:01 <sambetts> So I managed to get WIP/POC code up a week or so ago, I think this is something we might want to consider in the bigger picture as it changes the landscape with regards to things like the nova side patches for portgroups
16:33:41 <jroll> yeah, I'm a huge fan of this
16:36:43 <jroll> idk if there's anything else to say :P
16:36:44 <sambetts> because this spec + patches changes where the logic for vif to pif mapping occurs, I think we need to potentially consider it a prerequisit to the portgroups nova patches, because otherwise we'll be merging code to then just remove it again
16:37:34 <sambetts> jroll: WDYT about that? ^
16:37:52 <jroll> hmm
16:38:02 <jroll> I guess I definitely want to do portgroups in ocata
16:38:16 <jroll> so if we think we can do both, that's fine
16:39:21 <sambetts> i think it will make it easier/faster for work like portgroups/vlan aware etc as it moves much of that logic into Ironic, and under our control
16:39:24 <jroll> idk how much it helps though, it should be easy even if portgroups lands first
16:39:31 <jroll> ah yeah, nova side
16:40:02 <sambetts> yeah its the nova part that I don't want to merge the portgroups stuff to then remove it a week later
16:40:10 <jroll> ah right
16:43:37 <sambetts> I think we should see what people think of the patches out atm, they are linked in the agenda
16:44:35 <jroll> sure, makes sense
16:44:38 <jroll> is there a spec?
16:45:07 <sambetts> yeah https://bugs.launchpad.net/ironic/+bug/1582188
16:45:10 <openstack> Launchpad bug 1582188 in Ironic "[RFE] Add interface attach API" [Wishlist,In progress] - Assigned to Sam Betts (sambetts)
16:45:11 <jroll> okay
16:45:20 <jroll> let's see if you can drum up some support and then we can decide
16:45:22 <sambetts> the spec needs review
16:46:26 <jroll> okay
16:47:19 <sambetts> #topic VLAN aware Instances spec after aligning with Neutron/Ironic discussion
16:47:34 <sambetts> So this spec also needs review, it is linked in the agenda
16:47:47 <sambetts> #link https://review.openstack.org/#/c/277853
16:48:33 <sambetts> The trunk API merged in Neutron this cycle so it opens this up for development
16:48:37 <jroll> indeed, this one is really important
16:48:49 <jroll> sweet
16:50:15 <sambetts> I have added the attach/detach spec as dependent, because it adds a layer of abstraction we need to prevent us having to deal with nasty checks on the port.extra field
16:50:57 <jroll> okay, cool, I was wondering about that a bit
16:51:31 <sambetts> yeah, I'm think all the mapping part can be absracted behind the attach/detach interface APIs
16:51:36 <sambetts> thinking*
16:52:12 <jroll> awesome
16:52:54 <jroll> anything else here?
16:52:59 <jroll> I think it's just me and you sambetts :P
16:53:01 <sambetts> Nothing I can think of
16:53:10 <sambetts> #topic Open Discussion
16:53:40 <sambetts> I assume from the silence we're done here
16:53:43 <sambetts> :-P
16:53:52 <jroll> agree :)
16:54:04 <sambetts> thanks everyone, see you next week, same time, same channel
16:54:13 <sambetts> #endmeeting