15:01:13 <armax> #startmeeting neutron_drivers
15:01:13 <openstack> Meeting started Tue Nov 24 15:01:13 2015 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:15 <mestery> armax: You need MOAR COFFEE
15:01:16 <kevinbenton> hi
15:01:17 <openstack> The meeting name has been set to 'neutron_drivers'
15:02:03 <armax> mestery: tons of it, I just fell out of bed
15:02:10 <mestery> armax: slacker ;)
15:02:40 <armax> ok, let’s try to squash the triaged list a bit
15:02:44 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
15:03:20 <armax> or do we want over the list of comments that amotoki put together on the wiki page?
15:03:31 <armax> and HenryG
15:03:34 <mestery> armax: Lets start with amotoki's comments
15:03:35 <mestery> and HenryG
15:03:39 <mestery> Since they put the time in :)
15:03:47 <armax> sounds good
15:03:53 <mestery> #awesomesauce
15:04:08 <HenryG> should go quick, just double-check our work
15:04:49 <kevinbenton> armax: link to wiki?
15:05:00 <amotoki> https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
15:05:03 <mestery> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
15:05:12 <armax> let’s start with bug 1373660
15:05:12 <openstack> bug 1373660 in neutron "[RFE] An in-use dhcp port can be deleted" [Wishlist,Triaged] https://launchpad.net/bugs/1373660
15:06:36 <armax> I think the issue here is: some ports should not be deleted
15:06:53 <armax> manually by the tenant
15:07:24 <kevinbenton> why? it's their network
15:07:53 <amotoki> the problem is that dhcp-agent runs but a user can delete the port
15:08:08 <armax> and the port will be recreated by the agent
15:08:09 <dougwig> as long as we're consistent api-wide, and either cleanup the resources behind the port, or refuse to delete it until those resources have been deleted/unassigned, i'm happy.
15:08:18 <Administrator__> as I know, dhcp-agent will recreate a new dhcp port
15:08:33 <kevinbenton> yes, the agent should try to recreate the port
15:08:40 <russellb> dougwig: +1
15:08:43 <armax> I’d rather not special case the treatment of certain ports
15:08:52 <dougwig> kevinbenton: then it's just kinda silly to let them delete it in the first place, isn't it?
15:09:07 <kevinbenton> dougwig: no, it's their network. do what they want
15:09:16 <russellb> meh, it's not a user managed port though
15:09:17 <kevinbenton> otherwise we have to special case the port
15:09:24 <amotoki> I think you all are interested in this. more comments to the bug would be appreciated.
15:09:33 <mestery> amotoki: ++
15:09:36 <armax> then special ports should be invisble to them
15:09:47 <kevinbenton> and now we have to check user context in the API for deleting ports
15:09:48 <russellb> imo, it's weird that this port is visible, yes
15:10:05 <dougwig> kevinbenton: if you delete it and it magically reappears, then we're not giving "their network" any special delete powers. :)
15:10:05 <amotoki> we have several possible approaches. let's comment!
15:10:08 <kevinbenton> it would be stranger to have an invisible IP address that you contact for DNS
15:10:10 <armax> let’s start from the fact that the problem is not well stated to be honest
15:10:23 <Administrator__> armax, I agree with you that special ports should be invisble to user and not consume port quota
15:11:02 <dougwig> hiding it would cause real problems. i've lost count of the times that dhcp has failed and it's come down to an agent race startup condition and the dhcp port is just down, and needed flapping.
15:11:05 <HenryG> Administrator__: can you id yourself please?
15:11:24 <kevinbenton> this port is like any other network participant. it's wired by the agent, it gets its IP from IPAM, etc
15:11:28 <mestery> dougwig: ++
15:11:35 <armax> dougwig: if the system worked correctly you wouldn’t even need to know about it
15:11:37 <armax> dougwig: come on
15:11:38 <Administrator__> sorry, I will change
15:11:47 <amotoki> :)
15:11:48 <mestery> armax: Huh? That sounds just plain silly
15:11:51 <dougwig> armax: sure, but...
15:12:01 <mestery> We're gonna hide and it and make it harder to debug issues?
15:12:05 <mestery> Because it should just work?
15:12:08 <kevinbenton> if we hide it, then the same logic should be used to hide all router interfaces as well
15:12:08 <armax> dougwig: no, I am not saying that
15:12:10 * mestery hands armax more coffee
15:12:23 <armax> I am just saying that preventing deletion is equivalent to hiding them
15:12:28 <amotoki> agree with mestery and kevinbenton
15:12:37 <armax> and that’s bad
15:12:42 <russellb> showing them leaks the backend implementation a bit, but *shrug*
15:12:55 <dougwig> armax: no, because you can still see status, make it up/down, notice that it's part of your topology. it's always seemed obvious that it should be listed to me.
15:12:58 <mestery> We need to make this thing easier to use and operate, not harder
15:12:58 <mestery> Hiding things doesn't help
15:13:01 <mestery> dougwig: ++
15:13:04 <carl_baldwin> I tend to think this is pretty low priority.
15:13:06 <amotoki> from my comment: One idea is to clear device_id/owner of a port before allowing to delete the port. It achieves a kind of "force delete".
15:13:06 <kevinbenton> russellb: same can be said for router interfaces
15:13:09 <neiljerram> FWIW, preventing deletion seems to me different from hiding
15:13:16 <russellb> kevinbenton: agree..
15:13:31 <russellb> but that ship has sailed :)
15:13:45 <armax> same can be said for all ports that are used to do crazy stuff
15:13:48 <armax> like subports
15:13:50 <armax> :)
15:14:06 * mestery waits for this meeting to devolve to tags
15:14:11 <armax> dvr, floating ips, etc
15:14:23 <russellb> i think that one is a bit different actually, but let's stay off topic here
15:14:23 <armax> if this bug reads like: prevent the deletion of service ports
15:14:43 <amotoki> yes. it is not specific to dhcp ports. we need to discuss as a whole.
15:14:45 <amotoki> armax: ++
15:14:45 <armax> oh I forgot ha ports
15:14:54 <dougwig> it's like the port where IT has said, "don't touch this one".  it's obvious that it's there, it will cause serious pain if you pull the wire, and it makes things go.  you can't hide it. and if the user pulls it, bad stuff happens, but hey, people are people. now do we try to duct tape over it, or lock it in, or...?  my analogy-foo is weak this morning.
15:14:55 <kevinbenton> and lbaas ports
15:15:20 <mestery> dougwig: You're making sense to me, you must have had a few redbulls this morning already
15:15:55 <armax> in the case of dhcp the port is reprovisioned
15:16:00 <armax> so the system is resilient to failures
15:16:04 <ihrachys> I guess the whole hiding discussion could be postponed to after we don't experience any issues with the implementation :)
15:16:06 <carl_baldwin> dougwig: I agree with that.  There are all kinds of things that are necessary for operation and we don't babysit them all.
15:16:44 <mestery> Is anyone in favor of hiding?
15:16:45 <mestery> Because if not
15:16:46 <armax> I personally vote to “wont-fix”, ports have been exposed since the beginning
15:16:47 <mestery> Lets just move on
15:16:52 <mestery> armax: Right, +1
15:16:54 <armax> that’s how we work
15:16:55 <carl_baldwin> armax: +1
15:16:58 <dougwig> armax: +1
15:16:58 <amotoki> can we use #action to remember what still need to be visited/discussed in the next meeting.
15:17:11 <hanzhang> +1
15:17:12 <armax> amotoki: I usually take action right after the meeting
15:17:16 <amotoki> I think it is worth discussed for better UX.
15:17:25 <armax> amotoki: I think it’s a waste of time
15:17:28 <mestery> armax: No do #agreed here
15:17:29 <mestery> So we can lock it in
15:17:30 <mestery> lol
15:17:31 <asadoughi> has it been considered to allow this to be enforced by poicy.json?
15:18:28 <armax> #action armax to follow up on bug 1373660
15:18:28 <openstack> bug 1373660 in neutron "[RFE] An in-use dhcp port can be deleted" [Wishlist,Triaged] https://launchpad.net/bugs/1373660
15:18:29 <armax> next
15:18:41 <armax> bug #1416179
15:18:42 <openstack> bug 1416179 in neutron "[RFE] API to set & get list of provider network types" [Wishlist,Incomplete] https://launchpad.net/bugs/1416179
15:18:44 <russellb> i don't think this should be configurable for interop reasons.  i also think "this is the way it has always been, waste of time to discuss changing it" is a good point.
15:18:52 <mestery> russellb: ++
15:19:21 <amotoki> russellb: agree on 'set' side.
15:19:26 <armax> I believe this bug is also another time waster, unless something else happens first
15:19:42 <amotoki> on the other hand, I think 'get' side is useful
15:19:44 <mestery> armax: ++
15:19:45 <dougwig> i'm not seeing a use case listed.
15:19:45 <amotoki> that's all
15:19:55 <dougwig> just "we want to get".
15:19:56 <dougwig> why?
15:20:10 <dougwig> don't need to list it here.
15:20:11 <amotoki> dougwig: see my comment in the bug.
15:20:13 <russellb> amotoki: i was actualyl referring to the last one about dhcp heh
15:20:30 <armax> we’re talking about bug 1416179
15:20:30 <openstack> bug 1416179 in neutron "[RFE] API to set & get list of provider network types" [Wishlist,Incomplete] https://launchpad.net/bugs/1416179
15:20:31 <armax> now
15:20:39 <russellb> get is useful if it's different per backend
15:20:41 <mestery> lol
15:20:48 <dougwig> amotoki: right. why is horizon maintaining that list? what's it doing in the UI?
15:20:56 <russellb> if it's hard coded then meh
15:21:05 <ihrachys> armax: on the other side, it is also a no brainer assuming we have folks to tackle it.
15:21:07 <armax> provider networks are provisioned ahead of time
15:21:20 <amotoki> dougwig: horizon has a network creation form for admin. we need provider net type list.
15:21:27 <armax> unless we make their management entirely dynamic
15:21:33 <russellb> +1
15:21:41 <kevinbenton> this sounds fine to me, especially since it's different in different ML2 deployments, let alone other plugins
15:21:42 <armax> I can’t see what retrivieving them does
15:21:46 <russellb> optimizing this thing which is largely very static doesn't seem like a good use of time
15:22:00 <mestery> russellb: ++
15:22:19 <kevinbenton> there is no way to discover enabled type drivers IIRC
15:22:22 <dougwig> amotoki: you can't just offer a list of names, and if the operator wants to expose their backend, they can do it there?
15:22:37 <armax> the use case of making provider networks dynamic is not an easy thing to do
15:22:43 <hanzhang> for provider network, I think it should support paging list
15:23:13 <kevinbenton> not even paging or filtering, just a plain list should be plenty
15:23:18 <kevinbenton> get-only
15:23:38 <hanzhang> agree
15:23:48 <kevinbenton> it's going to be like 1-5 items
15:24:04 <amotoki> it is not exposed to users, so it is not so important, but we have similar requests several times so far. I am okay with either in this case.
15:24:28 <kevinbenton> yeah, exposed to admins though
15:24:30 <amotoki> I can just say neutron team rejected to expose it to horizon team.
15:24:39 <armax> just so that we’re clear
15:24:48 <kevinbenton> no, not reject!
15:24:51 <armax> are we saying we should expose the networks that are currently hard coded here:
15:24:52 <armax> https://github.com/openstack/neutron/blob/master/etc/neutron/plugins/ml2/ml2_conf.ini#L62
15:25:02 <armax> the physnet ones?
15:25:21 <kevinbenton> armax: no. i thought this was to expose which types are avialable: https://github.com/openstack/neutron/blob/master/etc/neutron/plugins/ml2/ml2_conf.ini#L6
15:25:32 <amotoki> sorry for misunderstanding.
15:26:27 <armax> kevinbenton: ok so the type drivers supported
15:26:32 <kevinbenton> i think this has some value for admins needing to configure provider networks
15:26:35 <kevinbenton> armax: yes
15:26:49 <kevinbenton> just makes it a little easier for horizon or other guis
15:26:56 <armax> not all type drviers can be applied to provider networks
15:27:12 <neiljerram> It seems to me there's a general move from implementation config into the API (e.g. also bridge_mappings).  Is that really right?
15:27:16 <kevinbenton> armax: provider networks are just networks
15:27:16 <armax> frankly I think it’s another waste of time
15:27:22 <kevinbenton> armax: of course they can
15:27:45 <armax> kevinbenton: I have never seen a vxlan provider network, but sure
15:27:46 <kevinbenton> neiljerram: in ML2 the type is in the API already
15:27:56 <armax> kevinbenton: it’s just a network
15:28:03 <neiljerram> Yes, that also seems not obviously right, to me
15:28:15 <kevinbenton> neiljerram: file a bug
15:28:29 <kevinbenton> neiljerram: the entire provider network workflow is based on it
15:28:51 <armax> setting type drivers doesn’t make sense either
15:28:58 <armax> as they are stevedore entrypoints
15:29:00 <neiljerram> kevinbenton, it possibly means I haven't understood one of the meanings of the API....
15:29:11 <kevinbenton> armax: i agree setting via the API is not necessary
15:29:27 <armax> why would we want to ever prevent certain types to be used I don’t understand
15:29:30 <amotoki> agree settings is unnecessary
15:29:42 <armax> to me this bug is a classic example of overenginering for the sake of it
15:29:44 <armax> bah
15:29:50 <armax> I do need coffe
15:29:52 <armax> coffee
15:30:04 <kevinbenton> neiljerram: http://docs.openstack.org/networking-guide/scenario_provider_ovs.html#create-initial-networks
15:30:14 <neiljerram> it's potentially worse than that, as it will also constrain us in future
15:30:25 <dougwig> amotoki: can you maybe include a screenshot of what you're trying to accomplish? i just fired up a juno horizon and can't see it on the create network dialog.
15:30:40 <kevinbenton> neiljerram: these are already in the API under the network
15:30:43 <amotoki> dougwig: sure tomorrow.
15:30:48 <armax> we’d be going through the trouble of creating an api endpoint, etc etc just to expose a list type drivers
15:30:48 <kevinbenton> dougwig: make sure you are on the admin network API
15:30:53 <kevinbenton> dougwig: not the tenant one
15:31:08 <armax> now granted that the ones chosen may depend by the deployment
15:31:15 <armax> so get Horizon to have a config option as well
15:31:22 <armax> and the admin must know to set both
15:31:23 <armax> done
15:31:35 <armax> can we move on pleasE?
15:31:40 <russellb> no!
15:32:03 <armax> (facepalm)
15:32:07 <kevinbenton> dougwig: admin network API = admin network page
15:32:14 <njohnston> facepalm +1
15:32:20 <dougwig> at 15 minutes per bug, we should be done with this meeting about... oh, is that the turkey burning?
15:32:22 <armax> russellb: it’s a no with a reason? or no, that’s it
15:32:24 <kevinbenton> next bug
15:32:28 <russellb> (yes)
15:32:28 <dougwig> kevinbenton: thanks, but i'm not seeing it there either?
15:32:36 <kevinbenton> this RFE is ML2 specific
15:32:42 <kevinbenton> we can discuss it there
15:32:45 <kevinbenton> on the bug report
15:32:49 <mestery> ML2 ILLUMANTI!
15:32:54 <mestery> I knew it
15:33:02 <armax> #action armax comment on bug 1416179 to mark it won’t fix
15:33:02 <openstack> bug 1416179 in neutron "[RFE] API to set & get list of provider network types" [Wishlist,Incomplete] https://launchpad.net/bugs/1416179
15:33:04 <armax> ok?
15:33:09 <ihrachys> configdb would help here.aye
15:33:16 <mestery> Did we just spend almost 20 minutes on that last bug? Wow.
15:33:20 <ihrachys> sorry, disregard ^
15:33:31 <ihrachys> let's move on
15:33:53 <armax> #link 1513144
15:33:56 <armax> bug 1513144
15:33:56 <openstack> bug 1513144 in neutron "[RFE] Allow admin to mark agents down" [Wishlist,Incomplete] https://launchpad.net/bugs/1513144
15:34:01 <armax> #undo
15:34:01 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x9077c50>
15:34:04 <kevinbenton> (that was a good example of why ML2 should be a different project)
15:34:06 <armax> #nundo
15:34:09 <armax> #undo
15:34:10 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x94b3f50>
15:34:26 <armax> #link https://bugs.launchpad.net/neutron/+bug/1513144
15:34:28 <mestery> kevinbenton: Your thinly veiled plot at a power grab with ML2 is noted
15:34:40 <armax> I see two meetings going on here
15:34:51 <amotoki> we have only <30mins. please check it after the meeting. I think it is good now.
15:35:02 <armax> amotoki: what is?
15:35:20 <amotoki> sorry for confusing comment.
15:35:51 <amotoki> i just want to say let's check bug  later 1513144
15:36:27 <armax> amotoki: ok
15:36:33 <kevinbenton> amotoki: still working out the use case?
15:36:40 <dougwig> so they want to be able to mark an agent down, so things don't get scheduled to that node, and an operator can look into it manually later
15:36:41 <armax> amotoki: yours was a long comment, I need time to read it
15:36:50 <dougwig> ?
15:36:54 <kevinbenton> dougwig: not quite. admin_stte_false already does that
15:37:08 <dougwig> then i failed to grok the use case yet again. can someone ELI5 it?
15:37:22 <kevinbenton> dougwig: they need to  mark down to force rescheduling or other failover IIUC
15:37:39 <kevinbenton> dougwig: because admin_state_up=False prevents future scheduling
15:37:44 <dougwig> so it's a "down, but do some extra goo" action?
15:37:57 <kevinbenton> "mark dead"
15:38:03 <kevinbenton> would be a short description i think
15:38:06 <amotoki> kevinbenton: but it prevents manual scheudling for agent with admin-state-down...
15:38:07 <armax> let’s follow amotoki’s suggestion
15:38:24 <armax> have a look at the bug report offline and make sure we’re prepared for the conversation next week
15:38:28 <kevinbenton> +1
15:38:47 <armax> #action drivers to look at https://bugs.launchpad.net/neutron/+bug/1513144 offline
15:38:47 <openstack> Launchpad bug 1513144 in neutron "[RFE] Allow admin to mark agents down" [Wishlist,Incomplete]
15:38:48 <armax> next
15:38:59 <armax> next: bug 1464793
15:38:59 <openstack> bug 1464793 in neutron "[RFE] Add a driver for isc-dhcpd" [Wishlist,Triaged] https://launchpad.net/bugs/1464793 - Assigned to Shraddha Pandhe (shraddha-pandhe)
15:39:18 <mestery> Is that within scope for Mitaka?
15:39:19 <kevinbenton> can that be completely developed as a sub-project?
15:39:31 <kevinbenton> or is that overkill for a subproject
15:39:32 <mestery> kevinbenton: ++
15:39:41 <neiljerram> dhcp_driver config should allow that, I believe
15:39:43 <armax> kevinbenton: it’s possible, but there might be adjustement to the dhcp interface
15:39:45 <dougwig> why would we block that if someone was willing to do the work?
15:39:49 <ihrachys> kevinbenton: + dhcp agent is pluggable so far
15:39:54 <armax> having said that, would I promote such an efforrt?
15:39:54 <amotoki> I think we need high level decision on this. perhaps subproject.
15:40:07 <kevinbenton> dougwig: nobody to review
15:40:09 <armax> personally I wouldn't
15:40:14 <mestery> Rigth
15:40:19 <mestery> If no one reviews, why give them false hope?
15:40:28 <mestery> Also, have you seen what is already on the list for reviewing?
15:40:31 <kevinbenton> so i'm leaning towards subproject
15:40:34 <armax> because running processes to deliver network services is problematic
15:40:38 <armax> and we all know that
15:40:38 <mestery> We're gonna collapse under our own weight if we're not careful
15:40:57 <dougwig> i like the subproject idea.
15:41:03 <armax> I don’t :)
15:41:13 <kevinbenton> armax: why not. it's a pluggable interface?
15:41:14 <dougwig> haha. pistols at dawn!
15:41:14 <mestery> I with dougwig on that one
15:41:18 <armax> not until we fix the stadium
15:41:19 <ihrachys> I believe we should be happy to review infra changes for dhcp agent pluggable interface for the subproject
15:41:30 <mestery> That's a bigger discussion armax
15:41:36 <armax> right
15:41:38 <armax> it is
15:41:45 <mestery> It's not as dire as you frame it, but meh
15:41:49 <dougwig> which part of the stadium are you referring to? the co-gate nastiness? or something else?
15:41:50 <kevinbenton> #topic demolition of the stadium :)
15:41:50 <armax> but I wouldn’t want to promote anyone to go on a time water
15:41:51 <armax> waster
15:42:06 <armax> dougwig: all of the above and beyond
15:42:15 <kevinbenton> armax: so what do you propose?
15:42:23 <armax> kevinbenton: for this bug?
15:42:26 <kevinbenton> yes
15:42:39 <armax> won’t fix :)
15:42:47 <kevinbenton> what's wrong with a subproject?
15:42:58 <armax> because no-one should use it?
15:43:08 <kevinbenton> nobody should use subprojects?
15:43:14 <armax> having centralized dhcp services is bad as it is
15:43:17 <armax> thank you very much
15:43:41 <dougwig> ok, we've got two religious objections going on here. can we table the stadium one, unless we make that the main topic and tackle it?
15:43:51 <kevinbenton> i have a wild list of opinions about many of our subprojects but I don't think they should be blocked :)
15:43:56 <ihrachys> armax: technically, how is it different from current dnsmasq implementation?
15:44:00 <armax> dougwig: no, I am not objecting the statidum right now
15:44:20 <armax> I am only saying that we should promote healthy initiatives that benefit the project as a whole
15:44:27 <dougwig> so is it that you don't like how dnsmasq is doing dhcp and don't want another one? or you just hate freedom of choice?  :-)  what's your ideal of how we do dhcp?
15:44:32 <armax> having another driver for dhcp, doesn’t seem like that useful
15:44:54 <armax> especially if it promoted a usage pattern that is gonna cause more trouble than it’s worth
15:45:06 <ihrachys> armax: should we kill pluggable interface then? if we don't allow folks to use it, then there is no reason to keep it.
15:45:09 <mestery> I don't understand the usage pattern that a new DHCP dirver in a sub-project would cause
15:45:12 <mestery> ihrachys: ++
15:45:17 <armax> we should either invest in distributed dhcp or moving away from the model of running dhcp process altoghether
15:45:40 <dougwig> armax: isn't that just another dhcp driver, though?
15:45:42 <armax> ihrachys: they can use it, I just don’t want to endorse it
15:46:00 <garyk> with distributed DHCP there is the issue of metadata proxies
15:46:02 <dougwig> armax: why would we pick and choose for them? isn't that the point of the stadium? letting folks do their own thing if they want?
15:46:11 * mestery is really confused
15:46:11 <ihrachys> armax: is a comment suggesting there is a pluggable interface for them to use if they feel like an endorsement?
15:46:13 <neiljerram> My suggestion: "feel free to experiment with implementing this, but not clear yet if and how it will be integrated into core Neutron"
15:46:36 <armax> then this ties to the shape the stadium currently is
15:46:47 <mestery> armax: What are you talking about?
15:47:10 <armax> nm
15:47:26 <kevinbenton> next bug. i think that should be tabled until we define the stadium requirements
15:47:27 <armax> #action approve yet another dhcp driver
15:47:35 <armax> whatever
15:47:40 <mestery> We have the stadium requirements defined
15:47:45 <mestery> I tend to think people are not happy with them
15:47:48 <mestery> Which is fine
15:47:49 <dougwig> mestery: if i understand, he's suggesting that the current model of dhcp is wonky and we should be fixing that, instead of adding another driver doing the same brokennness.
15:48:05 <mestery> dougwig: That part I understood
15:48:10 <armax> bug 1457556
15:48:10 <openstack> bug 1457556 in neutron "[RFE] [LBaaS] ssh connection timeout" [Wishlist,Triaged] https://launchpad.net/bugs/1457556 - Assigned to Reedip (reedip-banerjee)
15:48:19 <garyk> are you guys talking about the agent or the dhcp pluggable driver
15:48:38 <garyk> cause the dnsmasq is pluggable and that can be replaced
15:48:52 <neiljerram> garyk, I think that has already been said
15:49:05 <kevinbenton> dougwig: i'll defer to you on that one
15:49:09 <kevinbenton> dougwig: it sounds reasonable
15:49:31 <amotoki> I just want to pass bug 1457556 to dougwig :-)
15:49:31 <openstack> bug 1457556 in neutron "[RFE] [LBaaS] ssh connection timeout" [Wishlist,Triaged] https://launchpad.net/bugs/1457556 - Assigned to Reedip (reedip-banerjee)
15:49:35 <armax> #action move bug 1457556 to rfe-approved
15:49:48 <dougwig> it sounds reasonable to me, except not as just exposing haproxy options directly.
15:50:02 <kevinbenton> dougwig: +1
15:50:04 <armax> dougwig: right, they would need to be abstracted
15:50:08 <amotoki> dougwig: good point. do we suggest a spec?
15:50:27 <dougwig> agree to approve. i don't need a spec, just a clarifying comment on the bug, similar to what blogan suggested.
15:50:35 <armax> sounds good
15:50:38 <armax> next
15:50:41 <amotoki> +1
15:50:52 <armax> bug #1496705
15:50:52 <openstack> bug 1496705 in neutron "[RFE] A common description field for Neutron resources" [Wishlist,Confirmed] https://launchpad.net/bugs/1496705 - Assigned to Li Ma (nick-ma-z)
15:51:28 <russellb> the tags proposal accomplishes the same thing imo
15:51:45 <armax> weird I thought I had commented on this one
15:51:47 <armax> hang on
15:51:52 <armax> I think we have a duplicate here
15:52:01 <dougwig> russellb: spoken like a dev. :)
15:52:08 <armax> https://bugs.launchpad.net/neutron/+bug/1483480
15:52:08 <openstack> Launchpad bug 1483480 in neutron "[RFE] Allow annotations on Neutron resources" [Wishlist,Triaged]
15:52:11 <dougwig> i'm pretty sure they want something wordier than a tag.
15:52:20 <ihrachys> do tags have attributes attached? if not, it's not completely the same.
15:52:22 <russellb> dougwig: make a wordy tag?
15:52:26 <armax> we should have the conversation in one place
15:52:34 <armax> we can’t afford to talk twice :)
15:52:42 <armax> I think tags != descriptions
15:52:49 <kevinbenton> yeah, they explicity say they think tags suck because you don't know which one is the description
15:52:50 <ihrachys> maybe it's easier to come up with a tag prefix concept
15:52:57 <dougwig> russellb: let's remove all the db columns and do it all with tags then?  :)
15:53:04 <russellb> dougwig: sure why not
15:53:14 <russellb> but fair ... description = human readable thingy
15:53:16 <russellb> fair enough.
15:53:16 <armax> let’s have one giant table
15:53:26 <dougwig> JSON STORE!
15:53:27 <ihrachys> like 'description:Whatever nice text you may want to add' tags
15:53:38 <armax> and return the entire content in a single API response
15:53:47 <armax> done
15:53:49 <kevinbenton> 'GET /neutron_state'
15:53:57 <armax> kevinbenton: get /all
15:53:59 <dougwig> i feel the pacific timezone affecting my snark level.  :)
15:53:59 <amotoki> :)
15:54:05 <armax> jokes aside
15:54:09 <garyk> i think that tags are super useful and helpful
15:54:14 <armax> I think we have a duplicate here
15:54:35 <kevinbenton> right, i don't think anyone is saying tags don't work
15:54:41 <armax> I marked https://bugs.launchpad.net/neutron/+bug/1496705
15:54:41 <openstack> Launchpad bug 1483480 in neutron "duplicate for #1496705 [RFE] Allow annotations on Neutron resources" [Wishlist,Triaged]
15:54:43 <armax> duplicate
15:54:44 <kevinbenton> what they want is a named field for the description though
15:54:49 <armax> of https://bugs.launchpad.net/neutron/+bug/1483480
15:54:50 <openstack> Launchpad bug 1483480 in neutron "[RFE] Allow annotations on Neutron resources" [Wishlist,Triaged]
15:54:50 <dougwig> garyk: this is not a tag discussion. this is a discussion of whether other new fields are new fields are just specialty tags, which i don't tend to agree with.
15:54:59 <dougwig> /are just/or just/
15:55:01 <armax> I think adding a description field may be handy
15:55:05 <dougwig> armax: +1
15:55:06 <russellb> desc seems fine
15:55:08 <ihrachys> then should we define tags as attributes with no value attached?
15:55:14 <amotoki> armax: +1
15:55:15 <kevinbenton> armax: then why did you mark as duplicate?
15:55:18 <armax> because as a user I may want to add my grocery shopping list to my dhcp port in use
15:55:33 <armax> becasue it’s two of them that are saying the same thing?
15:55:36 <armax> kevinbenton: ^
15:55:41 <dougwig> armax: lol
15:55:41 <neiljerram> not a good idea if the port is then deleted
15:55:49 <armax> neiljerram: oh right
15:55:53 <garyk> dolphm:
15:55:56 <kevinbenton> armax: no, one was saying they still need description even with tags
15:56:02 <armax> kevinbenton: right
15:56:20 <armax> kevinbenton: we have two bugs that both are about description
15:56:30 <garyk> dougwig: yeah, i got that. i just think that if we do go down the road for tags and defer or duplicate other stuff in favor of that then we should make sure that have the correct priority for tags
15:56:31 <armax> #action make description the new black
15:56:39 <kevinbenton> armax: oh, whoops. i thought you made description a dup of tags
15:57:02 <armax> btw I think from now on
15:57:07 <armax> we should review bugs in order of submission
15:57:16 <armax> from the oldest to the youngest
15:57:22 <kevinbenton> armax: +1
15:57:29 <armax> just an opinion
15:57:30 <njohnston> what is the current ordering?
15:57:30 <kevinbenton> and this meeting should be extended to 4 hours
15:57:45 <armax> njohnston: it depends
15:57:46 <dougwig> we should timebox each bug at like 5 minutes.
15:57:46 <ihrachys> I also think if drivers don't keep up in 1h, maybe 2h per week would be a better deal.
15:58:03 <kevinbenton> we hardly get the paint out before it's over
15:58:04 <mestery> njohnston: The current order is defined by a user pluggalbe scheduler, today's scheduler plugin was from amotoki and HenryG
15:58:04 <armax> ihrachys: let’s have a week retreat in the caymans
15:58:14 <ihrachys> armax: you pay
15:58:24 <ihrachys> amotoki: sleeping time is overrated
15:58:27 <njohnston> armax: got it, thanks
15:58:32 <armax> ihrachys: I thought you’d cover with the gift card I gave you yesterday
15:58:50 <kevinbenton> we need a pluggable drivers meeting scheduler that receives vectors of RFE attribute weights and...
15:58:57 <armax> ok, folks thanks for the very entertaining discussion, I love you all
15:58:58 <ihrachys> armax: I will, virtual caymans with that virtual card
15:58:59 <armax> #endmeeting