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