15:00:47 <armax> #startmeeting neutron_drivers
15:00:47 <openstack> Meeting started Tue Dec  1 15:00:47 2015 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:50 <dougwig> o/
15:00:51 <openstack> The meeting name has been set to 'neutron_drivers'
15:01:00 <armax> welcome back to some of you
15:01:01 <kevinbenton> \o
15:01:02 <mestery> o\
15:01:03 <carl_baldwin> o/
15:01:05 <njohnston> o/
15:01:07 <ihrachys> o/
15:01:18 <amotoki_> o/
15:01:28 * kevinbenton thinks mestery is doing yoga
15:01:38 <mestery> kevinbenton: That's one interpretation
15:01:57 <armax> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
15:02:01 <dougwig> welcome to the uncaffeinated drivers meeting!
15:02:16 <armax> indeed
15:02:32 <armax> we have 10 triaged bugs to go through and deliberate on
15:02:36 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe&orderby=datecreated&start=0
15:03:11 <armax> #bug 1023156
15:03:11 <openstack> bug 1023156 in neutron "[RFE] QuantumDbPluginV2 should support extended attributes on core resources" [Wishlist,Triaged] https://launchpad.net/bugs/1023156 - Assigned to Ihar Hrachyshka (ihar-hrachyshka)
15:03:36 <dougwig> can we timebox at max 5 mins per bug?
15:03:39 <armax> ihrachys: you care to comment on this one?
15:03:41 <armax> dougwig: we should
15:03:44 <ihrachys> armax: aye
15:03:48 <armax> dougwig: if we could
15:03:50 <shz> o/
15:03:53 <ihrachys> so the bug is to make ml2 extensions not ml2 specific
15:04:14 <ihrachys> to have some core resource extension manager that can consume extensions like ml2 extensions and can be integrated into any plugin
15:04:26 <ihrachys> integrate once, get more extensions automagically
15:04:39 <russellb> i like the goal, at least
15:04:40 <ihrachys> f.e. for now qos is ml2 specific for that reason
15:04:53 <russellb> that's been a problem for networking-ovn
15:05:00 <ihrachys> well, plugins can dup the code to support it, but it's not ideal
15:05:00 <dougwig> isn't this an end run around the ORM?
15:05:03 <armax> do we really want to ml2-fy the core plugins?
15:05:40 <ihrachys> armax: how is it ml2-ying anything? it's just making some existing features working for all other plugins.
15:05:46 <mestery> My vote is to not ml2-fy the core plugins
15:05:50 <ihrachys> if anything, it's un-ml2-fying neutron
15:06:11 <garyk1> so now ml2 has become a verb?
15:06:11 <ihrachys> mestery: you vote for each plugin to be updated for any 3rd party service plugin?
15:06:19 <armax> ihrachys: you’ll have to call methods in a loop don’t you
15:06:20 <armax> ?
15:06:30 <amotoki> does ml2-ying mean to allow to dsiable  extensions by config?
15:06:44 <ihrachys> armax: inside the manager, yes. but in the plugin, you just call to the manager once and it makes the magic.
15:06:45 <armax> not that there’s anything wrong with that per se
15:07:00 <armax> ihrachys: did you do any PoC investigation on how that would look like?
15:07:08 <mestery> ihrachys: Nope, not what I want.
15:07:09 <ajo> o/ sorry, I got distracted and wanted to join
15:07:16 <ihrachys> armax: no, and probably I won't have time for that in M due to... you know... stuff
15:07:42 <armax> ihrachys: stuff, we all love *the* stuff
15:07:44 <markmcclain> magic is bad because it's easily misunderstood/abused
15:07:47 <armax> ihrachys: you should be careful
15:07:49 <ihrachys> 1 min...
15:08:07 <ihrachys> armax: our own stuff especially
15:08:21 <armax> ihrachys: ok, right now no staffing, plus some concern on the complexity of the resulting implementation
15:08:31 <armax> I’ll capture this on the bug report
15:08:40 <armax> next
15:08:49 <armax> #bug 1438159
15:08:49 <openstack> bug 1438159 in neutron "[RFE] Make neutron agents less chatty on AMQP" [Wishlist,Triaged] https://launchpad.net/bugs/1438159
15:08:50 <dougwig> so, reading it again, this is enabling filtering across an extension mechanism that already exists, right?
15:09:36 <armax> ihrachys, kevinbenton you both commented on this one
15:09:38 <armax> thoughts?
15:09:43 <ihrachys> armax: I suspect that one is (partial?) dup for kevin's rpc refactoring
15:09:50 <armax> kevinbenton: you have the push notification discussion going on
15:09:53 <ajo> yes
15:09:57 <armax> ihrachys: right
15:09:58 <ajo> looks like a dup
15:10:10 <kevinbenton> yeah, i think this is already basically going to be covered by RPC callbacks and the stuff i am doing
15:10:30 <ihrachys> not exactly a dup, since some stuff there is on top of it, like per agent topic for pushing updates.
15:10:37 <armax> ok, I’ll make sure I capture that and clean up any loose end
15:10:48 <armax> but it’s definitely related
15:10:54 <armax> ihrachys: is it not?
15:10:54 <ihrachys> but I don't believe we need RFE for that now until we settle on kevin's work and assess it
15:11:25 <ihrachys> armax: it is related
15:11:26 <kevinbenton> ihrachys: +1
15:11:37 <ihrachys> armax: and it should be reassessed after we have rpc refactored
15:11:39 <armax> ok
15:11:43 <ihrachys> can be closed/postponed for now
15:12:07 <armax> #bug 1486388
15:12:07 <openstack> bug 1486388 in neutron "use timestamp of resources to reduce the agent sync load" [Wishlist,Triaged] https://launchpad.net/bugs/1486388
15:12:31 <armax> this is also related, in that it’s proposign a different approach to deal with loadd
15:12:32 <armax> load
15:12:55 <dougwig> is this introducing a dependency on ntp, or do we alrady require that?
15:12:59 <armax> but I think it’s one or the other
15:13:01 <kevinbenton> -1
15:13:05 <dougwig> because if your clocks are out of sync...
15:13:18 <kevinbenton> using timestamps for sync is a workaround for other innefficiencies imo
15:13:30 <mestery> We don't require NTP
15:13:31 <armax> kevinbenton: agreed
15:13:32 <mestery> But we should
15:13:32 <kevinbenton> we should be able to fetch 500 things from a DB in short order
15:13:44 <ihrachys> yes, should not be an issue after switching to rpc callbacks (assuming we handle raciness for the latter)
15:13:47 <dougwig> if we do this at all, i'd think it should be with sequence numbers, not time.
15:13:50 <armax> running a cloud without NTP is a disaster waiting to happen
15:14:04 <markmcclain> out-of-sync clocks can create other problems too
15:14:11 <werunthenight> Exactly.
15:14:12 <ajo> dougwig : +1 for seqnumbers
15:14:17 <russellb> ntp is effectively required already
15:14:17 <ajo> exactly
15:14:20 <russellb> fwiw..
15:14:21 <markmcclain> dougwig: lamport clock
15:14:23 <ajo> even if synced they can drift
15:14:28 <mestery> Right
15:14:47 <kevinbenton> yes, time is unreliable as to what is 'newest' without distributed locking that can account for drift
15:14:54 <armax> I think this proposal is effectively clashing with some of the things that kevinbenton and ihrachys were talking about eralier
15:15:07 <kevinbenton> (ala google's spanner paper)
15:15:11 <ihrachys> it does. it won't apply once kevinbenton does... stuff
15:15:12 <dougwig> ok, off with it's head.
15:15:15 <armax> so for that reason, I’d say ‘wonfix’
15:15:37 <armax> bug 1508243
15:15:37 <openstack> bug 1508243 in neutron "Store Private Key Passphrase in Neutron-LBaaS for TLS Terminations" [Wishlist,Triaged] https://launchpad.net/bugs/1508243 - Assigned to Doug Wiegley (dougwig)
15:15:53 <kevinbenton> defer to dougwig :)
15:16:04 <armax> everyone wants a pony but no-one is willing to pay for it
15:16:08 <armax> that’s the gist on this bug?
15:16:09 <salv-orlando> are we even considering storing a private key in neutron?
15:16:15 <armax> sorry RFE
15:16:21 <dougwig> they were debating this one internally, and i can't say i'm thrilled with the idea of storing passwords in the db.
15:16:38 <kevinbenton> store it in the description field or as a tag :)
15:16:42 <armax> what’s wrong with storing passowrds in clear?
15:16:53 <ihrachys> :D
15:16:54 <dougwig> i'd like to talk with adam/rm_work about this one.
15:17:03 <armax> just use simple ones
15:17:08 <armax> like mysecret123
15:17:14 <dougwig> sex or money or password
15:17:27 <salv-orlando> if you have nothing to hide, you have nothing to worry
15:17:37 * neiljerram heads off to armax's Gerrit account...
15:17:41 * ihrachys makes notes
15:17:44 <armax> salv-orlando: said the man who’s hiding something
15:17:47 <ihrachys> neiljerram: exactly
15:17:54 <armax> dougwig: ok, I think this needs a spec to say the least
15:18:14 <armax> but if no-one is willing/able to staff it…this is dying ‘incomplete’
15:18:15 <dougwig> armax: ack, but let me vet it first.  i'll put it on my list for today.
15:18:18 <armax> is that a fair assessement?
15:18:21 <armax> ok
15:18:36 <armax> what’s the existing workaround today, dougwig?
15:18:56 <werunthenight> hm
15:19:01 <werunthenight> good question
15:19:01 <dougwig> don't use a passphrase on your tls cert, or it's in barbican.
15:19:20 <dougwig> and i'm not certain why that's not enough.
15:20:07 <amotoki> if so, it is better to be clarified.
15:20:14 <dougwig> aye
15:20:59 <armax> ok
15:21:16 <armax> #bug 1508384
15:21:16 <openstack> bug 1508384 in neutron "QoS proxy functions" [Wishlist,Triaged] https://launchpad.net/bugs/1508384
15:21:19 <armax> this might be quick
15:21:31 <dougwig> that sounds like a challenge.
15:21:57 <armax> I personally don’t see much of an issue to add client support as server capability increases
15:22:07 <ihrachys> with no huge benefit for those who add support for new qos rule types
15:22:15 <armax> that’s not where the bulk of the cost lies
15:22:27 <ajo> It makes neutron client more usable
15:22:40 <ajo> but, it increases the amount of server queries we need to do
15:22:48 <ihrachys> ajo: how so, assuming client is updated with new CLI?
15:23:06 <ajo> may be I got it wrong
15:23:13 <ihrachys> also it's something new for neutron to maintain API schema accessible thru REST
15:23:21 <ajo> but my understanding was that the proxy functions lived on the python-neutronclient
15:23:42 <dougwig> if the qos client support was part of the neutron package, as an extension, couldn't it be updated with the same commit that makes the api change, too?
15:24:07 <ihrachys> ajo: see comment #5, David proposes to inspect API schema.
15:24:18 <amotoki> we made similar discussions on finding capabilities.
15:24:23 <ajo> ahh, ok, I missed that update
15:24:26 * ajo is outdated :(
15:24:36 <amotoki> exposing API schema sounds good to me.
15:25:08 <ajo> If we expose the API schema, probably isn't something we'd like to do neutron-wise?
15:25:21 <ihrachys> amotoki: I can consider it, but then not just for QoS.
15:25:22 <armax> I appreciate that there’s the neat way of doing things and the dull way of doing things
15:25:24 <salv-orlando> ajo: maybe...
15:25:32 <amotoki> if a client library can expose this kind of information, we can use it from CLI, horizon or other stuff.
15:25:40 <dougwig> since you can dynamically extend the client, isn't a better model to put new client feature support where the feature lives, instead of a workaround like api introspection?
15:26:08 <armax> if someone wants to go on a quest to rewrite every possible framework we rely on to embrace this working model, sure that’s a possibility
15:26:20 <ihrachys> armax: +1 who's paying?
15:26:26 <ajo> exactly
15:26:28 <amotoki> a client library has two options: define them inside it or fetch them from neutron.
15:26:34 <salv-orlando> ihrachys: Don Quixote, Inc.
15:27:22 <armax> ihrachys: that’s one quesiton, the other question is: what’s the long term gain, and how it related to the short-term one?
15:28:08 <armax> how frequently does functionalitiy have to evolve for this working model to be worthwhile
15:28:20 <dougwig> i don't have a strong opinion here, beyond not liking jamming every little thing inside the monolithic client, which doesn't affect this rfe. (though client extensions did exist before qos.)
15:28:22 <armax> the initial investment of getting qos capabilities in the client is done already
15:28:41 <ihrachys> no idea why we did it in core :)
15:28:56 <ihrachys> we could move it away, but it's irrelevant to rfe
15:29:05 <armax> and if we had resources to spare I’d rather have someone work on the openstack client for a bit
15:29:33 <armax> as a matter of fact there’s an rfe on it too…but that’s much newer and I am going chronologically
15:29:36 <ajo> armax : +1
15:29:59 <armax> ok, let me capture the conversation that we had here and we’ll see
15:30:01 <ihrachys> so can we move forward then? or people feel strongly we need API schema right now?
15:30:22 <armax> ihrachys: I’d say hold it for now
15:30:27 <armax> bug #1511574
15:30:27 <openstack> bug 1511574 in neutron "[RFE] Support cleanup of all resources associated with a given tenant with a single API call" [Wishlist,Triaged] https://launchpad.net/bugs/1511574 - Assigned to John Davidge (john-davidge)
15:31:06 <armax> amuller is not the room
15:31:22 <armax> he’s the one who had some concern about this
15:31:23 <ihrachys> should it really be API, or local db crawling tool is enough?
15:31:45 <armax> ihrachys: it’s gotta be API I think
15:31:53 <armax> becxause cleaning up the DB is not enough
15:32:01 <armax> you may want to issue RPC messages and all
15:32:12 <amotoki> i think crawling db is not enough. we need to clean up on nodes.
15:32:23 <dougwig> i'd be in favor of adding a purge, and if the eventual cross project definition differs, support that as well. punting a real ops concern for some unicorn definition later seems like just passing the buck.
15:32:26 * ajo asks armax for a slot on 1512587 (QoS/RBAC) and 1461000 (OVS/CT Firewall -status update-) when other priorities are sorted out
15:32:45 <armax> dougwig: how bad can they differ?
15:32:49 <ihrachys> armax: ok. not that we cannot issue RPC without API calls.
15:32:53 <armax> in the simplest of cases the API call should be
15:33:07 <dougwig> armax: agree.  purge(tenant).
15:33:11 <armax> right
15:33:26 <amuller> hi
15:33:29 <armax> and if not, then we logic is not going to change that dramaatically
15:33:34 <armax> hi amuller
15:33:43 <armax> someone must have pulled you in
15:33:48 <armax> we’re talking about 1511574
15:33:51 <armax> bug 1511574
15:33:51 <openstack> bug 1511574 in neutron "[RFE] Support cleanup of all resources associated with a given tenant with a single API call" [Wishlist,Triaged] https://launchpad.net/bugs/1511574 - Assigned to John Davidge (john-davidge)
15:33:53 <amuller> yeah Miguel pinged me
15:34:02 <amuller> I worked on tenant deletion a yearish ago
15:34:03 <armax> I remember you had done some work on this already
15:34:04 * ajo whistles...
15:34:05 <armax> didn’t you?
15:34:07 <amuller> yeah
15:34:19 <ihrachys> I remember those patches; they were -2'd
15:34:31 <armax> they were ahead of their time
15:34:36 <armax> amuller: you were a visionary
15:34:38 <ihrachys> :D
15:34:42 <ajo> lol :)
15:34:53 <amuller> armax: I get that literally every never
15:35:04 <amuller> so, there's lots of ways of going about that
15:35:09 <armax> in the end something like os-purge does the job
15:35:13 <armax> right, plenty
15:35:21 <amuller> we can say it's not Neutron's problem and use an external tool (like ospurge)
15:35:24 <salv-orlando> oh well some guy tried that a year before amuller I think
15:35:41 <armax> oh amuller sorry you’re no longer a visionary, I take it back
15:35:42 <ajo> salv-orlando : seems like a hard wall
15:35:48 <amuller> we can listen on the RPC bus for keystone tenant (sorry, project) deletion
15:35:49 <ihrachys> salv-orlando: that one was genius, not visionary
15:36:05 <amuller> but neutron-server may be down when that notification goes out
15:36:10 <amuller> so you need a 'sync' mechanism
15:36:11 <amuller> or
15:36:13 <amuller> you expose it via  the API
15:36:35 <amuller> either way we need a consistent story across openstack
15:36:42 <armax> I think there are three positions here
15:36:44 <dougwig> it's a straight-forward definition, it has a volunteer, why would we just punt it?
15:36:58 <amuller> dougwig: I'm not saying that
15:37:02 <salv-orlando> dougwig: strongly agree with you
15:37:02 <armax> you either have the whole pruning/purging all integrated and fully managed end-to-end
15:37:12 <armax> that’s one end of the sprecturm
15:37:19 <armax> the other end of the sprectrum is what we have today
15:37:26 <armax> the admin is on his/her own
15:37:43 <amuller> I don't think we should go with the API approach without getting cross-project agreement with Nova and Cinder at the least
15:37:47 <armax> the middle ground is, neutron gives you a short-cut to clear tenant resources at once
15:37:53 <armax> at a push of a button
15:38:17 <ihrachys> amuller: but we can go with a tool that triggers the operation inside neutron-server
15:38:29 <armax> amuller: I don’t understand why we’d preclude ourselves the ability to provide the shortcut based on what other projects might do
15:38:40 <salv-orlando> I mean API wise, even if Neutron does not own tenants, it is fair to assume it manages a TENANT resource on which you can only do GET and DELETE
15:38:44 <armax> I can talk to the Nova and Cinder PTL to see where they are on this
15:38:53 <dougwig> amuller: what's the risk of adding one sooner?  maybe there's a slightly different cross-project signature, and we support both with the same code for awhile? that seems better to me than leaving ops in the cold.
15:39:03 <salv-orlando> amuller is probably bringing up a reasonable problem of API consistency
15:39:14 <amuller> dougwig: I don't know why you assume that other projects would be against this?
15:39:19 <amuller> it's reasonable to it via the API
15:39:30 <amuller> Hopefully other projects would arrive at the same conclusion
15:39:40 <amuller> doing it via RPC has its shortcomings
15:39:55 <dougwig> amuller: i'm just assuming that going cross-project punts it a cycle.
15:39:55 <armax> I agree with amuller that consistency will be nice
15:40:01 <amuller> dougwig: so be it
15:40:04 <armax> but other projects had tags on teh api
15:40:16 <armax> and they didn’t wait for all projects to ocmply
15:40:28 <armax> that begs the question if we need to file a spec to openstack-specs
15:40:30 <salv-orlando> amuller:  correct. For instance a REST API is way easier to integrate into whatever tools ops use than a RPC over AMQP call
15:40:34 <armax> and then proceed from there
15:40:48 <amuller> this has been a problem for years, putting some arbitrary time limit on this and saying screw quality or what's right is misguided
15:40:58 <amuller> we should do what's right for all of openstack
15:41:03 <amuller> not just an rfe in neutron
15:41:16 <amotoki> amuller: totally agree
15:41:39 <armax> amuller: right, one can proceed with a spec in http://specs.openstack.org/openstack/openstack-specs/
15:41:48 <amuller> armax: that sounds great
15:41:52 <armax> but work can happen regardless in neutron
15:41:54 <dougwig> amuller: you're right, but this isn't an argument of absolutes.
15:41:59 <armax> as the effort to reconcile the two
15:42:01 <armax> won’t be hard
15:42:09 <ajo> yup
15:42:15 <armax> there’s really not much to go wrong here IMO
15:42:23 <amuller> armax: if we introduce an API in Neutron and the cross project effort dies we've screwed ourselves and the entire openstack community
15:42:29 <ihrachys> armax: is it a way to say we will 'follow up' on it (never happens)?
15:42:31 <armax> the simplest purge(tenant_id) would suffice
15:42:34 <armax> and I shall say
15:42:37 <armax> purge(project_id)
15:42:47 <amuller> armax: dougwig: What if John writes the code without the API endpoint
15:42:56 <amuller> for example a CLI tool would invoke it
15:42:59 <amuller> as first step
15:43:08 <armax> amuller: that wouldn’t be the first time something like that happens
15:43:11 <amuller> a later step would add an API endpoint that would invoke the exact same code
15:43:29 <dougwig> or maybe we steal a play from other protocols, and let him implement /x-purge, saving the real /purge for the cross project effort, and knowing that one will likely silently call the other.
15:43:33 <armax> openstack is not exactly renowned for consistency
15:43:56 <amuller> armax: and we should do our part to combat that, not accept it as some axiom
15:43:57 <ajo> at least now we're conscious about it
15:44:02 <ajo> as a first step
15:44:15 <armax> amuller: agree, but that’s the nature of the beast
15:44:26 <armax> amuller: you can fight it, but you’ll never kill it
15:44:34 <salv-orlando> dougwig: whatever... I'd just release note the API as experimental and warn all users that its syntax and/or semantics could change over time
15:44:35 <ihrachys> I am for unblocking RFE as long as API is not included in first iteration, and we bring the API topic in cross project specs
15:44:38 <salv-orlando> we've done that before too.
15:44:45 <amuller> ihrachys++
15:44:58 <armax> having code that’s unreachable?
15:45:00 <armax> what’s the point?
15:45:06 <amuller> armax: you would reach it via CLI
15:45:14 <ihrachys> armax: how is it unreachable? it's avail thru ssh :)
15:45:16 <amuller> tools/project-purge.sh
15:45:22 <salv-orlando> ihrachys: I can bring that up with the API WG, but I'm not sure if that is the right place, since it also involves interactions between keystone and everybody else
15:45:29 <dougwig> salv-orlando: the point of an experimental namespace is that you don't break backwards compatibility, but still get to say, "this might change". i hate backwards incompatibiliy.
15:45:35 <ihrachys> amuller: even /usr/sbin/neutron-tenant-cleanup
15:45:41 <amuller> ihrachys: true
15:45:45 <amuller> ihrachys: you mean project :)
15:45:49 <amuller> ihrachys: tenant is a bad word now
15:45:56 <armax> I am not sure I fully understand
15:45:56 <ihrachys> ah
15:46:04 <armax> amuller: can you make your proposal on the bug report please?
15:46:04 <ajo> tenant--
15:46:07 * ihrachys hits himself hard
15:46:20 <salv-orlando> dougwig: yeah, I think we're on the same page. I was just pointing out that being the API not so well organized at the moment you might not bother with the exp namespace
15:46:23 <ihrachys> armax: we have neutron-linuxbridge-cleanup; we don't expose it thru API
15:46:36 <amuller> the bad part of having an opinion is action items
15:46:38 <armax> ihrachys: but that’s different
15:46:50 <dougwig> i think we're past our timebox on this one.
15:47:00 <amuller> armax: I'll try to come up with something concrete
15:47:01 <ihrachys> yeah, let's give amuller a chance to comment there.
15:47:02 <armax> ihrachys: here we have stuff that spans a lot more than one agent
15:47:11 <armax> amuller: thanks amuller
15:47:14 <ihrachys> armax: hence server side tool
15:47:20 <amuller> please do move on
15:47:26 <armax> yes sir
15:47:48 <armax> bug 1512587
15:47:48 <openstack> bug 1512587 in neutron "[RFE] Role-based Access Control for QoS policies" [Wishlist,Triaged] https://launchpad.net/bugs/1512587 - Assigned to Haim Daniel (hdaniel)
15:48:01 <ajo> o/
15:48:05 <cbits> :)
15:48:15 <ajo> armax , why do you believe this needs an spec?
15:48:49 <armax> https://bugs.launchpad.net/neutron/+bug/1512587/comments/8
15:48:49 <openstack> Launchpad bug 1512587 in neutron "[RFE] Role-based Access Control for QoS policies" [Wishlist,Triaged] - Assigned to Haim Daniel (hdaniel)
15:48:57 <ajo> yes, armax , but I didn't fully understand that
15:49:06 <ajo> it's partly of what the bug is going to fix
15:49:26 <dougwig> the use case sounds more like flavors than rbac.
15:49:29 <armax> this is going to provide API changes etc
15:49:30 <armax> no?
15:49:43 <ajo> armax: not finally, we talked about it on the QoS meeting
15:49:55 <ajo> we were considering the drop of --shared in favor of using rbac directly
15:50:16 <ajo> instead of --shared on policy, doing rbac access_as_shared *
15:50:17 <ajo> but
15:50:20 <armax> ok, so where is this design discussion being captured? :)
15:50:22 <ihrachys> as I told before, you can't drop, it's not compat.
15:50:22 <ajo> the call was not to introduce api changes
15:50:30 <ajo> exactly
15:50:43 <armax> either spec of devref, someone has to explain how this is going to work
15:51:05 <ajo> armax , isn't the rfe good enough?, I will go over it and make sure there won't be any api changes
15:51:58 <ajo> I see the rfe is now unconsistent with what we said on the meeting
15:52:02 <armax> ajo: the chance doesn’t sound trivial enough to warrant no information being captured in some forme or another
15:52:22 <amotoki> ajo: i think RFE is a place to discuss what feature we want. it is betetr to discuss how in spec or devref.
15:52:49 <ajo> armax, ok, I will get it specced then
15:52:53 <armax> I am ok with the use case, but I think we need to document somehow the work involved
15:53:06 <ajo> ok, as long as we're all on the same page,
15:53:07 <armax> spec or devref 
15:53:15 <ajo> I didn't fully understand your comment at #8, but now it's clear to me :)
15:53:18 <armax> but spec seems the most natural thing as this is very user visible
15:53:33 <armax> ajo: sorry, most of the times I talk with my eyes closed
15:53:40 <ajo> ack, let's go for a spec with the high level details
15:53:44 <armax> and type like a monkey
15:54:02 <ajo> armax : nope, the RFE details were outdated and missleading, I must admit
15:54:08 <ajo> misleading
15:54:26 <ihrachys> ok, so ajo updates the RFE bug and provides a spec.
15:54:29 <armax> ok next
15:54:33 <armax> bug 1517903
15:54:33 <openstack> bug 1517903 in neutron "[RFE] Add agent specific API for l2 agent extensions" [Wishlist,Triaged] https://launchpad.net/bugs/1517903 - Assigned to Ihar Hrachyshka (ihar-hrachyshka)
15:54:36 <ajo> ack
15:54:43 <armax> this actually shows as approved in the list of blueprints
15:54:47 <armax> for mitaka-1
15:55:17 <ihrachys> yeah, saw you approved for M1 already. I agree spec is probably needed.
15:55:27 <armax> but I wanted to give the opportunity to talk
15:55:32 <armax> before doing the state transition
15:55:37 <ihrachys> it's a blocker for qos, sfc, bgpvpn. that's what we know so far.
15:55:37 <armax> to rfe-approved
15:56:03 <armax> ihrachys: yes we need to execute based on some of the discussions that happened on the summit too
15:56:07 <ihrachys> basically, features need access to br-int/br-tun and friends
15:56:11 <ihrachys> and do it in l2 agent extensions
15:56:26 <ihrachys> which currently lack access to those bridges
15:56:40 <yamamoto_> ihrachys: tap-as-a-service will likely want to use it too
15:56:44 <armax> if many efforts do rely on the ovs agents for delivering functionality
15:56:55 <ihrachys> so there is a plan to provide extensions with per agent type API objects that will expose some agent details without exposing too much
15:56:58 <armax> it’s only fair to provide some extensibility mechanism
15:57:19 <ajo> ihrachys , wouldn't a devref be more appropriate?
15:57:23 <armax> even though I fundamentally believe there’s a better more radical way to dealing with this
15:57:31 <ihrachys> we have etherpad and some oral tales about how it will look like. I need spec/devref to document / notify folks
15:57:37 <ajo> it's not a user facing feature, but an implementer feature/api
15:57:39 <armax> ajo: it could be both :)
15:57:39 <ihrachys> ajo: I am fine with devrefs. I like them.
15:58:07 <ihrachys> let's do both and steal from spec to devref
15:58:19 <ihrachys> unless someone is against extensions, we can move
15:58:21 <ihrachys> I gues
15:58:40 <ajo> that's fine too :) as long as we end with a good documentation for developers, and make it clear it has to be an stable api :)
15:58:49 <armax> ok
15:59:01 <armax> 2 mins left
15:59:16 <ihrachys> 1
15:59:19 <shz> i have one #1468236
15:59:19 <armax> I’ll capture the latest discussion on teh bug reports we talked about
15:59:24 <armax> #endmeeting