15:30:47 #startmeeting neutron-drivers 15:30:47 Meeting started Wed Jun 3 15:30:47 2015 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:30:47 o/ 15:30:48 \o/ 15:30:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:30:51 The meeting name has been set to 'neutron_drivers' 15:30:54 #topic Agenda 15:31:00 * ihrachyshka lurks 15:31:05 Disolve the drivers team and instead directly use lietenants 15:31:06 :) 15:31:08 thoughts? 15:31:39 +1 15:31:40 I mean, not dissolve, but refocus 15:31:48 well, I think the drivers team should be made up by 15:31:49 Since we have Lts. now, they need to be involved in evaluating RFEs 15:31:50 lietenants 15:31:54 armax: ++ 15:31:58 dougwig amotoki ihrachyshka: Thoughts? 15:32:03 yeah, I was going to say. Still helpful to have a high-level group of ptl delegates 15:32:10 marun: Exactly 15:32:13 this in turn means that marun and I give our seats to the other folks 15:32:23 seems reasonable, except for when the current LT silos don't cover something. 15:32:28 armax marun: You both will forever be in my heart ;) 15:32:32 and include the rest of the folks 15:32:39 dougwig: the ptl is responsible for everything not delegated 15:32:43 mestery: I would personally still do the reviews etfc 15:32:47 ++ 15:32:47 right 15:32:52 I hope people keep reviewing! 15:32:54 They should! 15:32:58 Code, RFEs, etc. 15:33:11 but yesterday it occurred to me that I have not the right visibility into some of the lietenant areas for juding an approval 15:33:12 I mean, even now, I am defering to Lts. for some of these specs/RFEs 15:33:17 armax: Exactly 15:33:18 the driver team focus on the project management and mainly focuses on spec approvals. 15:33:27 amotoki: agreed 15:33:44 are drivers still the only ones to merge specs then? 15:33:44 so it makes sense to let lietenants have that right 15:33:53 marun: Yes, and that would be made up of Lts. 15:33:54 I thought the lts should have that right 15:33:56 ah, ok 15:33:57 marun: by the looks of it, yes 15:34:04 marun: But, I expect after Liberty-1 we will have a negligble amount of specs 15:34:08 so lts are elevated to drivers essentially 15:34:09 makes sense 15:34:13 we can collaborate with lientenants and we can share our views. 15:34:17 marun: yes, exactly! 15:34:26 so drivers are now lieutenants + existing drivers? 15:34:28 amotoki: Keep in mind, you and dougwig are Lts., so there is no change for either of you 15:34:38 ihrachyshka: No, marun and armax would be out since they are not Lts. 15:35:12 mestery: i know, but only dougwig and me are intersections ;-) 15:35:19 :) 15:35:37 amotoki: So, you are advocating for keeping a separate drivers team to do project management, etc,? That's a fair point. 15:35:38 how come armax is not in drivers team??? :) 15:35:42 i think it was a natural consequence, though it seems to me to be too quickly, but i don't have any objection. 15:35:46 ihrachyshka: because I am not a lt 15:35:53 ihrachyshka: Personal choice :) 15:36:19 rest assured that my level of involvement is not going to change 15:36:29 at least for the reasonable time being :) 15:36:29 I don't think we should have more separate teams. 15:36:43 So long as the ptl can maintain relationships with all the lts this should be fine 15:36:55 if the number grows unmanageble, middle management may be required 15:37:00 :( 15:37:08 Reasonably, 7 is about the max 15:37:17 amotoki: what separate teams are your thinking of? 15:37:24 linux manages quite a deep hierarchy 15:37:25 Although, I am going to start "IRC office hours" for "PTL to Lt. communication" each week 15:37:27 so it is possible 15:37:32 I think mestery needed to intereact on a regular basis with lietenants 15:37:35 an LT per tent repo is probably unmanageable already. :) 15:37:39 that can happen in the context of this meeting 15:37:48 dougwig: True dat. 15:37:53 Actually 15:37:57 Now that we're discussing this 15:38:03 I am starting to understand amotoki's points 15:38:12 * dougwig left his tea brewing for half an hour. danger. 15:38:17 the fact each repo in the neutron stadium has a Lt. now makes the team large already 15:38:24 I'm not sure everything in the tent needs direct ptl oversight though 15:38:27 mestery: care to elaborate? 15:38:34 marun: right 15:38:47 marun: IT does! By coming in, they are agreeing to it, but how much time will it take? Debatable. We won't know until Liberty is done to be honest. 15:38:50 I mean, the argument for ovn's inclusion was that it wouldn't add work to ptl 15:38:52 Experimentation is #ftw 15:38:58 If that's not true, we're in trouble 15:39:06 For OVN, I'm already intimiately involved there, so it wasn't a problem 15:39:16 So they get special treatment :/ 15:39:26 I wouldn't say special treatment 15:39:26 mestery: I think this boils down to stuff that must go in neutron proper 15:39:26 marun: they are meant to be mostly standalone, but the ptl is there if needed. 15:39:31 Honestly, if we don't prioritize effort we'll be overworked indefinitely 15:39:40 or the interface with external parties 15:39:47 right 15:39:48 Not everything in the tent is equally deserving 15:39:50 marun: I agree! 15:39:50 for that we can keep an ad-hoc approach 15:39:58 ++ marun 15:40:06 marun: ++ 15:40:15 there's in the tent, and then there's in the same sleeping bag. 15:40:32 * marun thinks dougwig missed his calling as a comedian 15:40:51 OK 15:41:02 So wrt lts getting direct oversight from ptl... 15:41:02 So, this is all good feedback 15:41:30 Shouldn't that be on a prioritized basis on how important the area of responsibility is perceived to be to the project? 15:41:38 marun: It is, yes! 15:41:41 so, to recap: drivers team == made up of neutron lt’s 15:41:59 armax: I don't think everyone agreed to that yet :) 15:42:14 amotoki still had concerns about dissolving the existing drivers team in favor of Lts. being the new drivers team 15:42:19 the tent projects lt’s as being defined by russellb patch https://review.openstack.org/#/c/187733/ will have ad hoc interaction with the neutron ptl? 15:42:24 Also, do we allow LTs. from stadium projects into drivers? I would say no. 15:42:30 mestery: I think so long as you're comfortable directly interacting with the lts, it's fine. 15:42:31 armax: Yes 15:42:33 mestery: what cocnern? 15:42:47 armax: Correct 15:42:48 mestery: If/when it becomes too much work, then we can revsiit 15:42:56 marun: Right, agreed. 15:42:59 i would suggest that the drivers team be "drivers + LTs", to give yourself some wiggle room for broader delegation. 15:43:05 mestery: ok, so does my summary make sense? 15:43:06 marun: Thus, my idea of weekly IRC office hours for Lt. interaction 15:43:14 dougwig: no, I would oppose to the idea 15:43:17 marun: This is how ttx has moved the general realease work to as well 15:43:25 There are no longer 1:1s between ttx and the PTLs, just office hours 15:43:26 dougwig: nothing stopping lts from being anybody responsible for anything 15:43:28 armax: i mean, you can still stop being a driver. :) 15:43:39 dougwig: That works too 15:43:47 dougwig: but at that point if we enlarge the team so why why do we have the drivers team at all? 15:43:48 mestery: cool 15:44:09 OK, let me write something up and share it with everyone on this. 15:44:11 Does that sound fair? 15:44:12 dougwig: it’s either a small drivers team or no drivers teamm at all 15:44:17 * mestery gest out his DMV clipboard 15:44:18 I think this represents an expansion of driver responsibility along with increasing the membership. 15:44:20 so maybe he can delegate all the decomposed plugins to one person. or maybe add nobody to that half of the group. it's his organizational call. 15:44:24 mestery: I got number 4434343 15:44:28 lol 15:44:30 and we're renaming it too 15:44:45 it is confusing, I'll admit 15:44:53 what are we renaming? 15:44:57 I wish we had been able to use the term 'maintainers', frankly. 15:44:58 neutron-intent-based-lieutenant-policy-chaining? ;) 15:45:07 though i canot follow all discussions... lts are regarded as some kind of specialists of specific areas. on the other hand drivers team review specs and priorities. the role is a bit different but the goal is similar. 15:45:09 you forgot flavors 15:45:09 drivers -> lts 15:45:12 marun: ++ to maintainers 15:45:18 dougwig: Nuts! 15:45:20 or at least member of drivers team -> lts 15:45:49 #action mestery to sort out neutron-drivers vs. Lts. and the path forward 15:45:51 or maybe amotoki's idea is drivers is lts + non-lt drivers? 15:45:54 I gave myself a work item 15:46:05 not sure where the disconnect is: I think that what it’s being advocated here is that members of the drivers team are selected from the LT’s pool 15:46:17 Are people ok with me coming up with a solution here and driving consensus? 15:46:17 I trust all drivers and lts and I have no worry about merging both. 15:46:31 I don't know if the distinction of driver with area of code responsibility vs driver with area of non-code responsibility is justified. 15:46:33 as they are the ones who need to care for their area of specialization, they have intimate knowledge of what needs to get done, fixed etc 15:46:37 mestery: yes 15:46:48 OK 15:46:50 there is an interesting dynamic to this conversation, wherein armax and marun are opposed to the drivers continuing in their current form. if you're that adamant, why are you still in the group? aren't you really saying that you want out? 15:46:55 We have 13 minutes left, shall we move on? 15:47:09 dougwig: It doesn't make sense for me to be in the group regardless. 15:47:11 * mestery waits for responses to dougwig's point 15:47:25 dougwig: you’re reading it wrong, but at this point yes, 15:47:27 I want out 15:47:32 dougwig: I have no vested interest in any given outcome, just that it should make sense to everyone involved. 15:47:59 because it makes no sense for me to +A a spec whose ultimate impact should be determined by the LT 15:48:11 that’s all I am saying 15:48:21 so you don't see your broader knowledge of neutron than most as having additional value in spec review? (and it's broader, and with longer history, than mine.) 15:48:27 the drivers team main feat was the +A right 15:48:29 that’s all 15:48:39 armax: Also, consistency 15:48:44 dougwig: I am not saying that I am stopping reviewing 15:48:55 armax: fair point. 15:49:05 my understanding for the driver team is not to rush to approve specs. I think it is important point. 15:49:07 only that the last say into whether something needs to be +A or not does not lie with me 15:49:09 one of hte original goals of the small drivers team was consistency from release to release 15:49:11 dougwig: ^ 15:49:17 If we make hte team too big, we lose that 15:49:20 amotoki: ++ 15:49:47 Lots more to discuss here I think, but this is all good! Thanks for all the feedback everyone! 15:49:48 I think this bears further thought, in any case. 15:49:52 mestery: yes, that's the thing that might get lost, although i see that as moving back onto the PTL's shoulders if this stays as simply "LTs". 15:49:55 amotoki: agreed, but the lt’ team is only 7 folks now, and we’d need a bit of extra help 15:50:05 especially if the core team grows, then the ratio is not too bad 15:50:11 armax: agreed. 15:50:31 I'll write something up to share with folks by Monday. 15:50:47 In either case, we'll iterate on gerrit and see what we come up with. 15:50:56 Ideally, we keep this meeting to 9 more minutes :) 15:51:04 Shall we look at at least a few RFEs now? 15:51:08 sounds good 15:51:16 #topic RFE review 15:51:17 #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe 15:51:35 #link https://bugs.launchpad.net/neutron/+bug/1460177 15:51:35 Launchpad bug 1460177 in neutron "Support metadata service with IPv6-only tenant network" [Undecided,Confirmed] 15:51:38 Lets start with this one 15:51:48 Because I think it's an example of a good RFE overall 15:52:28 "metadata only works with IPv4, and we'd like it to work for tenants with IPv6 only networks." 15:52:31 Thoughts by folks? 15:52:54 +1 sane 15:53:15 it sounds reasonable for pure IPv6 world. 15:53:47 OK, lets move it to triaged, which means that work can proceed on it. armax dougwig marun, good with this? 15:53:56 yes 15:54:04 I am wondering how cloud-init works with IPv6 15:54:32 aren't all ipv4 addresses also ipv6? 15:54:35 says cloud-init can be configured with other URLs 15:54:42 yes 15:54:45 i thought it was a simple no prefix scenario. 15:55:03 so i'm confused why that ipv4 won't work, but that's ok. 15:55:08 i'm too far into the weeds. 15:55:11 russellb: if that’s the case, then it should be fine 15:55:22 i understand we need to identify prbolems to support preu ipv6 world, but it is worth triaged. 15:55:47 I wonder if a more elegant approach would be adopting config-drive 15:55:57 there's no adopting needed, that already works 15:56:15 but metadata service is pretty well known and established, seems fine to make sure it works via ipv6, as well 15:56:22 russellb: ++ 15:56:25 russellb: + 15:56:28 This one is good 15:56:41 How about this one: https://bugs.launchpad.net/neutron/+bug/1461000 15:56:41 Launchpad bug 1461000 in neutron "[rfe] openvswitch based firewall driver" [Undecided,Triaged] - Assigned to Jakub Libosvar (libosvar) 15:57:00 This was an example of a not so good RFE (we're learning, I'm not picking on the submitters) 15:57:04 But kuba's response is good 15:57:27 kuba's update is solid 15:57:50 I moved this to triaged I realized before consulting in this meeting, but it's fairly obvious we want this, does anyone disagree? 15:58:45 seems obviously good to me :) 15:58:54 no disagreement 15:59:04 sounds good to me. 15:59:29 added a note to the bug 15:59:48 Lets do one more 15:59:50 https://bugs.launchpad.net/neutron/+bug/1460222 15:59:54 Launchpad bug 1460222 in neutron "Add 'labels', a list of opaque strings, to the neutron 'port' object" [Undecided,Triaged] 15:59:56 armax: You moved this to triaged I think? 16:00:07 mestery: yes 16:00:15 I'm fine with that, just letting other folks know. 16:00:29 armax: Any idea who this should be assigned to? 16:00:36 i think nova has a thing very similar, but they call it tags 16:00:37 * mestery notes it shouldn't be armax 16:00:39 would be nice to be consistent 16:00:46 but i'm fine with the concept 16:00:47 russellb: Comment in the bug? :) 16:00:49 my question is whether we should allow 'labels' for all other resources. 16:00:51 acknoledging that we starteed the discussion 16:00:52 Consistency is good 16:01:02 speaking as a vendor who has wanted to stash some meta-data in the past, it was always pushed back against as "locking in". 16:01:22 I am wondering if we can achieve the use case proposed with what we got already 16:01:25 like binding:profile 16:01:27 dougwig: In effect, that is partially the goal from the proposer here as well to be honest 16:01:29 that's basically adding a key=value meta store to each object. which i agree with, but which has already been rejected before. 16:01:30 ugh, it's actually proposed as info interpreted by the backend 16:01:35 dougwig: But the general concept seems ok 16:01:38 more backend specific pass-through is harmful IMO 16:01:47 russellb: Right 16:01:49 That was my concern as well 16:01:52 i assumed it'd be just used for clients to do filtering 16:02:10 the more vendor specific stuff added, the less valuable neutron is as an abstraction 16:02:32 yes, this is purely an aid for vendor specifics. we should be upfront about that. 16:02:32 russellb: Agreed, and the harder it becomes for people to switch backends, etc. 16:02:41 russellb: binding:profile is effectively already doing that 16:02:47 Can you folks comment in the bug with this info too? russellb dougwig 16:02:47 :) 16:02:51 * russellb will comment on the bug 16:02:55 armax: right, and i think that's bad too :) 16:02:57 opaque bags of data for everyone! 16:02:59 so, we sort have that ship already sailed 16:02:59 flavors also does this, but puts the configuration control in the hands of operators. 16:03:03 marun: lol 16:03:16 armax: doesn't have to get worse 16:03:20 Lets be honest, this is an attempt to end-run neutron, bottom line. 16:03:30 russellb: however that can be used for a number of other use cases, I was talking to Sukhdev and he mentioned that he uses it for bare metal provisioning 16:03:47 armax: Not everyone will use their special powers for good :) 16:03:50 if it didn't have use cases, we wouldn't have flavors being worked on. 16:03:58 dougwig: ++ 16:04:52 there was also another proposal made in the past about tagging core resoruces 16:05:03 yes, the yahoo one from manesh right? 16:05:07 despite what some people think 16:05:10 mestery: yes 16:05:41 I think that pushing back is not really a viable long-term solution 16:05:53 There are too many valid use cases to ignore 16:06:07 So long as core neutron doesn't rely on these fields, I think it's fine. 16:06:15 marun: to quote you, "opaque bags of data for everyone!" 16:06:17 but we need a common way to interact with other projects. vendor specific way is not diresable. 16:06:27 i think all of those uses cases are covered by flavors, if we can ship it. 16:06:27 lol 16:06:37 mestery: but if neutron isn't using them, I don't think it matteres 16:06:38 dougwig: We have to ship it in Liberty 16:06:43 marun: ++ 16:07:01 i think it does matter in terms of interop 16:07:01 mestery: I'm more concerned with neutron itself relying on opaque data bags. 16:07:02 amotoki: we give the tool, if the tool is misused is not our fault 16:07:05 Lets be honest here, there are valid use cases for this, yes. Will people use this for nefarious purposes? Absolutely! Should we care? If it harms the concept of neutron and waters it down, yes. 16:07:07 it means code written against one openstack does not work against another 16:07:09 it makes interop worse 16:07:17 marun: We can't rely on opaque data blogs agreed 16:07:24 russellb: that's a given 16:07:33 russellb: and a reality today 16:07:35 russellb: that’s an academic point to be honest 16:07:45 russellb: It does beg the question of how we can deal with that reality constructively. 16:07:47 russellb: no two openstack clouds are alike and interoperable, period. 16:08:00 russellb: without stalling useful efforts or requiring a bunch of rework to existing stuff 16:08:02 take each use case and define a proper abstraction that serves it 16:08:10 russellb: ++ 16:08:10 instead of just adding pass through data bags 16:08:23 russellb: easier said than done in a landscape of conflicting vendor requirements 16:08:33 i do not disagree :) 16:08:42 :) 16:08:46 to level-set, flavors, as approved today, is nothing but a big table of opaque data bags associated with neutron objects, which must be enabled by operators and then can be seen by plugins/drivers. we have already approved this concept, in a way that doesn't promote lock-in, and doesn't touch the core data models. 16:09:15 dougwig: ++ 16:09:30 I think interop is a pipe dream where specialized behavior is being provided by specialized solutions 16:09:40 dougwig: so do you think that’s another viable appraoch to solving this use case? 16:09:44 at least above lowest-common-denominator capabilities 16:09:58 if so, we should capture that on the rfe bug 16:09:59 Given that, maybe we should find ways to make this clear to operators? 16:10:05 we allow some way for vendors, but it is better most things are common. it is one of our (neutron) important roles. 16:10:06 armax: yes, you could create ODL flavored ports. 16:10:28 So they can make decisions based on the long term cost/benefit of the loss of interop vs capabilities? 16:10:36 ODL flavored ports, now with less testing! :) 16:10:38 dougwig: I would love pointers 16:10:40 armax: well, an operator could choose to define ODL flavored ports, which would then be accessible, to be clearer. 16:10:49 so that the bug author can explore with it too 16:10:57 i'll comment on the bug. 16:11:14 dougwig: thanks, much appreciated 16:11:26 yes, lets comment on the bug and drive discussion there for ODL flavored ports 16:11:32 dougwig: That is too rich not to keep using :) 16:11:45 that sounds kinda dirty, and i almost regret hitting enter. :) 16:12:54 and we killed all conversation. 16:12:56 OK 16:13:01 Since we are still here 16:13:07 And have 17 minutes or so left 16:13:07 * russellb got distracted sorry :) 16:13:09 shall we keep going? 16:13:11 I think we should be vigilant on how certain tools provided by teh systems are used to make sure that people do not shoot themselves in the foot 16:13:14 so what purpose does neutron serve if we give up caring about interop... 16:13:25 kevinbenton: The point is we are not giving up on interop 16:13:37 kevinbenton: This bug will make interop worse, thus the discussion 16:13:37 :) 16:13:44 i think debating these features is very healthy fwiw 16:13:52 russellb: ++ 16:13:55 gets at the heart of what neutron should be, and where lines are drawn 16:13:57 really good stuff 16:14:23 cool 16:14:27 russellb: + 16:14:29 I think we’re mixing the what we provide with how it’s being used 16:14:47 I am firmly in the camp of "neutron is an abstraction and should be a DB/API layer" 16:14:51 Just to be clear 16:14:58 when gunpowder was invented it clearly had various applications 16:15:05 we can make pretty fireworks 16:15:06 lol 16:15:10 or kill people 16:15:12 i suppose that was directed at marun 16:15:30 kevinbenton: The reality is that interop has only ever been lcd 16:15:30 marun: what do you think the job of neutron is if interoperability is a pipe dream? 16:15:51 marun: lcd? 16:15:56 kevinbenton: and hopefully we bump lcd over time to encompass more features as they mature and become more widely distributed 16:16:01 lowest common denominator 16:16:11 i read lcd as lsd ...... 16:16:17 lol 16:16:17 i don't think it's a pipe dream, and default neutron is interoperable. but if an operator *chooses* to modify neutron to be non-interoperable, for their needs, why should we try to prevent that? 16:16:19 marun: nothign wrong with that 16:16:19 i was so confused ... and intrigued 16:16:19 russellb: LOOL 16:16:56 well stuff like port tags could easily lead to everyone developing a similar feature with a different data format 16:16:58 When we see opaque bags of data becoming the norm 16:17:03 and I'm looking at you, ml2 16:17:12 It's pretty clear that interop is starting to fall by the wayside 16:17:12 kevinbenton: i think port tags just got shot down. 16:17:24 ++ 16:17:29 * russellb throws a data bag at dougwig 16:17:31 "shot down! In a blaze of glory!" 16:17:38 When we have a client that can only configure the backend with arbitrary key value pairs 16:17:45 we're not doing a good job of interop either 16:18:03 I'm not saying we're doomed, but we have been falling behind. 16:18:27 marun: Right, thus the need to take the reigns back a bit 16:18:29 * marun digresses 16:18:30 And focus on the platform 16:18:39 not terribly, the very basic l2 wiring doesn't rely on the data bags 16:18:51 kevinbenton: right, that's lcd 16:18:59 "ODL flavored ports" and "data bags", only in a neutron meeting 16:19:01 kevinbenton: necessary but not sufficient to run most clouds 16:19:07 Look 16:19:17 part of the problem with neutron is that vendors still want to differentiate 16:19:22 At the expense of their customers 16:19:29 'part'? ;) 16:19:32 Look at all the stuff we've let into the client for example 16:19:37 "vendors gotta vend" 16:19:39 marun: ha 16:19:40 It's the cost of doing business, yeah 16:19:42 Our job is to keep growing lcd 16:19:44 mestery: amen to that 16:19:56 *cough*, some of their customers want that differentiation too. 16:20:01 marun: no, monolithic plugins skirt the provider extension and they provide l2. ml2 raises the requirements to expose the encap info 16:20:05 dougwig: Right, thus, "vendors gotta vend" 16:20:08 i think differentiation is possible without opaque data bags 16:20:16 you can have a proper abstraction that not every backend implements 16:20:17 russellb: ++ 16:20:33 and implementations of abstractions can be superior in other ways too, performance, ease of deployment, whatever 16:20:33 russellb: just have to get people to work together to develop those common abstractions 16:20:37 APi should define both protocol and its behaivor. If we don't define the behavior, it means we don't provide a proper abstraction. it is from operators view. 16:20:42 russellb: we can definitely improve in that regard 16:20:44 I think we’re dereiling the conversation badly 16:20:45 marun: totally ... and i view that as a core part of what neutron is 16:20:50 not sure whetehr that was intended 16:20:50 or should be 16:20:51 port tags as a service 16:20:59 i thought we already decided against data bags. i'm nots sure why we're still arguing. 16:21:06 are we violently agreeing? 16:21:10 right 16:21:10 yes 16:21:11 i mean, that can be fun sometimes 16:21:13 we're agreeing 16:21:15 :) 16:21:18 data bags are out! 16:21:21 dougwig: arguers gonna argue 16:21:24 we came to agreement too soon, we have argument quotas 16:21:34 lol 16:21:40 OK, I'd say that's it for this week. 16:21:41 then let's talk service chaining. 16:21:41 bah 16:21:44 I am lost 16:21:47 rofl 16:21:48 what am i supposed to do with all of this indignant outrage!?!? 16:21:57 service _flavor_ chaining (ftfy) 16:22:00 kevinbenton: go murder a puppy 16:22:04 rofl 16:22:05 woah 16:22:09 that escalated quickly 16:22:09 you guys clearly taking me for a ride 16:22:21 he's from idaho, they do things differently there 16:22:25 armax: You're like a 57 corvette my friend 16:22:31 bye bye now 16:22:36 lol 16:22:37 heh 16:22:47 * mestery reigns everyone back in 16:22:47 OK 16:22:49 focus. FOCUS! 16:23:04 I'm proposing the meeting is over, unless someone has another RFE they want to look at in 7 minutes? 16:23:13 A quick one 16:23:17 HenryG: Please 16:23:20 Bug 1460720 16:23:20 bug 1460720 in neutron "Move ipv6_gateway L3 config to CLI" [Undecided,New] https://launchpad.net/bugs/1460720 - Assigned to Abishek Subramanian (absubram) 16:23:31 The rfe tag was removed 16:23:34 HenryG: I think I wasn't in favor of this even being an RFE 16:23:36 I removed the tag in fact :) 16:23:46 But it changes the api, just wanted to make sure 16:24:25 HenryG: Ah, ok! In reality, the RFE wasn't written well (had too much "how"), again, not picking on the submitter, the process is new 16:24:31 HenryG: Bottom line, I made a mistake here and I'll correct it 16:24:54 agreed that moving something to client side sounds a big change. 16:25:27 yes, it should say "Add API to configure v6 gateway" 16:26:01 So add rfe tag back? 16:26:02 OK, thanks amotoki HenryG. 16:26:05 I added it back 16:26:06 refresh 16:26:10 HenryG: do we still have IPv6 meeting in Liberty? 16:26:16 no 16:26:17 I can update the title and description 16:26:26 amotoki: sean disbanded it 16:26:36 We discuss v6 in the L3 meeting if needed 16:26:39 I think it is worth discussed among IPv6 experts. 16:27:11 #action HenryG to make sure Bug 1460720 is discussed during an upcoming L3 meeting with carl_baldwin and team 16:27:11 bug 1460720 in neutron "Move ipv6_gateway L3 config to CLI" [Undecided,New] https://launchpad.net/bugs/1460720 - Assigned to Abishek Subramanian (absubram) 16:27:41 mestery: thanks! 16:27:43 * carl_baldwin adds it to the agenda… 16:27:51 * mestery ^5s carl_baldwin. 16:27:51 carl_baldwin: thanks! 16:27:53 OK 16:27:56 well, this has been a surreal meeting. 16:27:56 That's a wrap! 16:28:02 lol 16:28:04 Thanks folks! 16:28:06 thanks for letting me crash it 16:28:17 russellb: Anytime :) 16:28:17 HenryG too! 16:28:19 #endmeeting