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