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