15:08:03 <mestery> #startmeeting neutron-drivers 15:08:04 <openstack> Meeting started Tue Aug 25 15:08:03 2015 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:08:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:08:08 <openstack> The meeting name has been set to 'neutron_drivers' 15:08:16 <mestery> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers Agenda 15:08:26 <kevinbenton> #topic vim or emacs 15:08:32 <mestery> #info kevinbenton amotoki and mestery are here, though I hope armax and russellb lurk as well 15:08:51 <sc68cal> kevinbenton: someone's feeling fiesty 15:08:51 <mestery> #topic Bug Review 15:09:00 <mestery> lol 15:09:02 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1486649 15:09:02 <openstack> Launchpad bug 1486649 in neutron "Enhance DHCP agent and IP library for networking-calico interface driver" [Undecided,In progress] - Assigned to Neil Jerram (neil-jerram) 15:09:07 <russellb> that was a very short 15 minutes 15:09:10 <mestery> neiljerram: This one is yours I believe 15:09:35 <neiljerram> Yes, just hoping for support for this to be approved for L-3. 15:09:41 <mestery> Looks like haleyb and carl_baldwin are both good with this. As L3 Lieutenants, I trust their judgement here. 15:09:41 <kevinbenton> neiljerram: you think this is non-invasive enough for l3? 15:09:48 <mestery> neiljerram: You have haleyb and carl_baldwin onboard, so you're good 15:09:52 <kevinbenton> ack 15:09:55 <mestery> kevinbenton: See ^^^ 15:09:57 <neiljerram> Code is all already there and has been through many cycles. 15:09:57 <kevinbenton> if they are good, i'm fine with it 15:10:03 <mestery> kevinbenton: But, please review and if you think otherwise, say so 15:10:16 <neiljerram> kevinbenton: Yes, I believe so, I've tried to be super-careful about that. 15:10:32 <amotoki> neiljerram: how many works do we need to complete the rfe? 15:10:41 <kevinbenton> neiljerram: do you have a link to the code reviews handy? 15:10:47 <neiljerram> Cedric and Oleg have been v helpful, too 15:10:53 <neiljerram> Yes... 15:11:05 <neiljerram> https://review.openstack.org/#/c/206077/ 15:11:20 <neiljerram> https://review.openstack.org/#/c/206078/ 15:11:35 <neiljerram> Note that I have some comments from Carl and Salvatore currently still pending. 15:11:35 * haleyb wonders if he got a promotion from 'core' 15:12:12 <mestery> haleyb: Would "private" be acceptable? ;) 15:12:23 <haleyb> pfc is fine 15:12:27 <mestery> lol 15:12:35 <mestery> I think we can move on from this. neiljerram, you're in good hands here I think 15:12:38 <neiljerram> But I will address those today, so they will hopefully be mer 15:13:01 <neiljerram> oops, didn't mean that one. But thanks, mestery 15:13:05 <kevinbenton> yeah, these don't look too invasive 15:13:05 <mestery> :) 15:13:11 <mestery> Cool 15:13:12 <mestery> NExt up 15:13:14 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1468366 15:13:14 <openstack> Launchpad bug 1468366 in neutron "RFE - Logging API for security group and firewall rules" [Undecided,Confirmed] - Assigned to Yushiro FURUKAWA (y-furukawa-2) 15:13:18 <kevinbenton> looks like a little agreement on abstraction is needed 15:13:19 <mestery> Logging API for SG and FWaaS rules 15:13:27 <mestery> sc68cal: This one you've been involved in 15:13:40 <mestery> And I believe sc68cal may have indicated this is likely a Mitaka thing 15:14:27 <sc68cal> yep 15:14:49 <mestery> sc68cal: Commented as such in the review itself 15:15:03 <sc68cal> Mostly because the spec continued to have only one implementation - that file logging - the api itself did not have flexibility about how the storage part of the API should be pluggable 15:15:18 <russellb> sc68cal: sounds like a critical piece to me 15:15:19 <sc68cal> logging packets on the compute node/network node is not cloudy 15:15:38 <kevinbenton> so we can marked it as shipped in Liberty but we only support logging to /dev/null 15:15:49 <russellb> if there's no info about how to make it seriously useful, no need to rush it 15:15:58 <sc68cal> plus there was a lot of churn in the specs repo - at one point there were 3 specs filed for the same RFE 15:16:06 <sc68cal> so they didn't make it easy to review. 15:16:21 <mestery> #info Logging API is a Mitaka item 15:17:37 <HenryG> My issue with it is that a logging API should be one spec, and logging for SG/FW should be a separate one 15:17:43 <mestery> #topic Open Discussion 15:17:48 <mestery> Those were the only specific ones on the agenda 15:17:50 <kevinbenton> hey! 15:17:53 <kevinbenton> skipped my bug 15:17:57 <mestery> #undo 15:17:58 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x9ebe3d0> 15:18:02 <kevinbenton> https://bugs.launchpad.net/neutron/+bug/1486882 15:18:02 <openstack> Launchpad bug 1486882 in neutron "ml2 port cross backends extension" [Undecided,Confirmed] - Assigned to Dong Liu (liudong78) 15:18:02 <mestery> kevinbenton: Please, post it here1 15:18:03 <amotoki> sc68cal: I hope to keep the rfe bug description to catch up with the ongoing discussion. 15:18:08 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1486882 15:18:22 <kevinbenton> i think this will be mitaka 15:18:36 <sc68cal> amotoki: thanks - although now they're baking rsyslog into the API for logging. :-\ 15:18:38 <kevinbenton> and am going to discuss it in the ML2 illuminati meetup in september 15:19:04 <kevinbenton> but the general idea is that we should make the tunnel endpoint a port binding property 15:19:10 <mestery> kevinbenton: Please don't tell me that ML2 is having a mid-cycle of their own 15:19:40 <kevinbenton> mestery: i wouldn't call it a mid-cycle. it's much more like a 3/4ths cycle :) 15:19:54 <yongshenggong_> ajo: sure 15:19:56 <mestery> kevinbenton: I'd argue 99/100 given when it is 15:19:57 <mestery> But ok 15:20:10 <russellb> ML2 as a separate group / meetup / whatever seems odd 15:20:17 <russellb> when it's a fundamental part of core neutron 15:20:18 <mestery> russellb: Very odd 15:20:25 <kevinbenton> it's not really a meetup 15:20:31 <kevinbenton> er midcycle 15:20:32 <mestery> *sigh* 15:20:38 <russellb> sprint? 15:20:46 <russellb> people in a room? 15:20:46 <amotoki> agree 15:20:49 <mestery> I wish the ML2 team actually communicated with the neutron team more 15:20:58 <mestery> I suspect we'll need to deal with that at some point 15:20:58 <russellb> i don't understand why it's a team exactly 15:21:04 <russellb> but ok :) 15:21:08 <amotoki> according to ml2 meeting logs, it seems a sprint for some specific topics. 15:21:09 <mestery> Me either 15:21:54 <mestery> #action mestery to encourage ML2 to use main Neutron meeting and communicate more with their overlords 15:22:03 <mestery> kevinbenton: You can be my trojan horse into ML2 for now 15:22:14 <russellb> ha 15:22:28 <HenryG> I think it's a carry-over from when it used to be all the driver maintainers in a meeting 15:23:02 <mestery> HenryG: It appears to now be a vacuum, which is never good 15:23:11 <mestery> Everytime this has happened, nothing good has come out of it 15:23:12 * mestery grumbles 15:23:14 <mestery> Anyways 15:23:16 <mestery> Lets move along 15:23:20 <mestery> vikram__ has one for us here today too 15:23:23 * mestery #link https://bugs.launchpad.net/neutron/+bug/1476527 15:23:23 <openstack> Launchpad bug 1476527 in neutron "RFE - Add common classifier resource" [Undecided,New] - Assigned to YujiAzama (azama-yuji) 15:24:04 <mestery> This one seems like a Mitaka item to me 15:24:14 <amotoki> totally agree 15:24:18 <sc68cal> +1 15:24:23 <mestery> amotoki: Feel free to comment in the bug please 15:24:26 <mestery> sc68cal as well 15:24:44 <amotoki> sure 15:24:54 <amotoki> i have another one bug 1472076. 15:24:54 <openstack> bug 1472076 in neutron "Add enable_new_agents to neutron server" [Undecided,Confirmed] https://launchpad.net/bugs/1472076 - Assigned to Hirofumi Ichihara (ichihara-hirofumi) 15:24:54 <vikram__> mestery: thanks for discussing this up:-) 15:25:02 <mestery> vikram__: yw :) 15:25:33 <amotoki> the spec review https://review.openstack.org/#/c/170774/ looks good and it would be small. 15:25:41 <amotoki> I was just asked from the author. 15:26:16 <mestery> amotoki: I agree with you here! 15:26:32 <russellb> seems reasonable 15:27:13 <amotoki> moved to Triaged 15:27:31 <mestery> amotoki: I just merged the spec 15:27:34 <mestery> Lets get this into Liberty! 15:27:58 <amotoki> hichihara: it's yours. now accepted. ^^ 15:28:10 <mestery> #topic Open Discussion 15:28:13 <hichihara> amotoki mestery russellb: thank you!! :) 15:28:19 <shihanzhang> I have anothor one bug 1468236, https://launchpad.net/bugs/1468236 15:28:19 <openstack> Launchpad bug 1468236 in neutron "enable neutron support distributed DHCP agents" [Undecided,Confirmed] 15:28:24 <russellb> i didn't do anything :) but you're welcome! 15:28:36 <shihanzhang> it is about distributed dhcp agent 15:29:31 <russellb> 22 comments on the spec and a couple of -1s 15:29:40 <mestery> shihanzhang: Looking 15:30:02 <amotoki> shihanzhang: there seems many comments and more discusssion looks needed. 15:30:16 <mestery> shihanzhang: I think this is Mitaka at this point 15:30:23 <amotoki> Early mitaka sounds good. 15:30:33 <mestery> cool 15:30:35 <shihanzhang> ok 15:30:40 <mestery> Anything else? 15:30:47 <kevinbenton> tags 15:30:54 <mestery> link? 15:30:56 <neiljerram> Is there some kind of knob I should twiddle, on https://bugs.launchpad.net/neutron/+bug/1486649, to indicate approved for L 15:30:56 <openstack> Launchpad bug 1486649 in neutron "Enhance DHCP agent and IP library for networking-calico interface driver" [Undecided,In progress] - Assigned to Neil Jerram (neil-jerram) 15:30:58 * mestery tags kevinbenton 15:31:03 <kevinbenton> shall we do them? 15:31:35 <neiljerram> (sorry to bring that up _again_....) 15:31:42 <mestery> kevinbenton: As long as they are opaque to the backend, I'm +1.5 15:31:49 <russellb> if it tries to be consistent with existing similar things (what nova did is as good as any), and is explicitly opaque to backends (at least in documented intent), then +1 from me 15:32:08 <kevinbenton> mestery: there is no realistic way to stop a backend from using them 15:32:12 <russellb> right 15:32:34 <amotoki> correct, but we can document for major tags. 15:32:58 <russellb> any backend officially a part of neutron should be due a wrist slap if they do 15:32:58 <kevinbenton> something i noticed is that nova tags don't look like key/value pairs 15:33:21 <russellb> kevinbenton: true, but the API consumer could just set the tag as "key=value" 15:33:24 <russellb> if that's what they wanted 15:33:35 <mestery> neiljerram: Targeted it to Liberty-3 15:33:35 <amotoki> glance and cinder have similar cencept called "metadata". 15:33:36 <russellb> it's just string blobs stored int he db and reflected back in the API 15:33:47 <neiljerram> mestery: thx! 15:33:59 <kevinbenton> russellb: yeah, only thing that sucks about that is you can't ask the API for a specific key 15:34:36 <russellb> yeah, but it'd be odd if someone had enough tags where asking for a specific one was important 15:34:55 <kevinbenton> so it will always be up to the client to parse all of the tags to find the one it's looking for 15:35:37 * russellb nods 15:35:45 <russellb> have to weigh that against cross-API consistency 15:35:59 <kevinbenton> right 15:36:10 <kevinbenton> amotoki: how to glance and cinder do it? 15:36:15 <kevinbenton> amotoki: are they key/value pairs? 15:36:26 <kevinbenton> amotoki: or just a list of strings? 15:36:30 <russellb> slightly different concepts though 15:36:44 <amotoki> kevinbenton: I haven't investigated them yet, but it seems key/valye from horizon impl. 15:36:45 <russellb> image metadata are defined things 15:37:06 <russellb> bits of info needed for nova to know how to interpret and consume the image 15:37:14 <russellb> not opaque user-only things 15:37:29 <russellb> you can use it for custom stuff too, but that's not the primary purpose 15:37:30 <russellb> IIRC 15:37:44 * mestery is in two meetings and 3 conversations right now so is having trouble 15:37:51 <amotoki> iirc glance image metadata has hypervisor-specific information 15:37:56 <russellb> right 15:38:01 <kevinbenton> ok 15:38:11 <russellb> not sure about the cinder one, i don't remember that 15:38:49 <amotoki> one important point is that it is visible for admin 15:39:22 <mestery> amotoki: That's a good point indeed 15:39:35 <russellb> which? 15:40:40 <mestery> russellb: these being visible to admin 15:41:09 <russellb> right, isn't everything? :) 15:41:23 <kevinbenton> russellb: i think admin-only is what amotoki meant 15:41:26 <mestery> yeah, true, like I said, in 2 meetings and 3 conversations, and failing at all of them 15:42:10 <russellb> kevinbenton: oh, for cinder and glance? 15:42:46 <kevinbenton> amotoki: was that for cinder or glance? 15:43:37 <kevinbenton> regardless, i guess the outcome is that we are okay with tags 15:43:42 <amotoki> kevinbenton: yes, but i need to check 15:44:02 <salv-orlando> re tags: the temptation of using them as a way for stashing everything you want in it will be too much for many devs 15:44:31 <kevinbenton> perhaps we can add a feature that randomly deletes them 15:44:42 <kevinbenton> to show how unreliable they are for devs :) 15:44:44 <salv-orlando> we can support them and they're a good thing to have, but we just can't stop plugins from using them to push info down to backends 15:44:54 <mestery> The issue for me here is that once that happens it's game over for the neutron API as an abstraction I guess 15:45:19 <russellb> it's something ot watch out for for things in the neutron stadium 15:45:30 <russellb> if someone is a bad actor, they should be asked to remove that 15:45:30 <mestery> Agreed 15:45:35 <russellb> (or be removed from neutron) 15:45:39 <russellb> if they're removed, they do what they want 15:45:48 <kevinbenton> but couldn't they do the same thing with the name field right now? 15:45:52 <russellb> and whatever, no sense worrying about that case 15:46:12 <salv-orlando> my opinion now is that you can't just stop that from happening 15:46:18 <russellb> sure, or port binding profile for ports at least 15:46:19 <amotoki> port binding is a chaos field :-( 15:46:21 <salv-orlando> and on the other hand tagging are a good thing to have 15:46:25 <mestery> salv-orlando: But we can force them out of the stadium 15:46:47 <russellb> there are standards, man! 15:46:48 <salv-orlando> mestery: I think we've there long enough to know that doing police work is just a waste of time 15:47:04 <mestery> salv-orlando: Yes, and haters gonna hate, and marketers gonna market 15:47:10 <mestery> MEh 15:47:13 <mestery> So, do we just allow this in? 15:47:24 <russellb> with caveats in the spec and code? wfm 15:47:25 <salv-orlando> fwiw I am ok with it 15:47:30 <kevinbenton> +1 15:47:48 <russellb> happy to review the impl :) 15:47:58 <salv-orlando> who knows this perhaps will stop several teams from pushing weird attribute extensions 15:48:18 <mestery> yay! 15:48:40 <mestery> Consensus on a good hearted and useful feature that will be used by evil people everywhere for nefarious purposes! 15:48:41 <mestery> :) 15:48:52 <russellb> yup 15:48:55 <mestery> Shall we close this meeting now or is there other things to discuss? 15:49:33 <mestery> I'll take that as a +1 from everyone then. 15:49:40 <mestery> Thanks for the discussion today! 15:49:41 <mestery> #endmeeting