18:01:34 #startmeeting networking_policy 18:01:35 SumitNaiksatam_: seems like it, probably good to appoint another chair then 18:01:35 Meeting started Thu Aug 7 18:01:34 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam_. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:38 The meeting name has been set to 'networking_policy' 18:01:47 banix: :-) 18:02:01 #chair rkukura banix s3wong 18:02:02 Current chairs: SumitNaiksatam_ banix rkukura s3wong 18:02:19 whew! got that out of the way 18:02:22 * regXboi notes SumitNaiksatam has learned well :) 18:02:31 regXboi: ;-) 18:02:46 #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy 18:03:14 i hope everyone slept well yesterday! ;-) 18:03:49 #topic Mailing list discussion on GBP 18:04:30 so I think good arguments have been made in favor of doing this in-tree 18:04:36 in the mailing list yesterday 18:05:12 what does everyone else think? 18:05:25 * regXboi has been waffling back and forth 18:06:01 SumitNaiksatam_: +1, there has been a good response. 18:06:17 * banix surprisingly in good spirit :) 18:06:27 banix: :-) 18:06:45 i am glad to know so many people are interesting on GBP. 18:06:59 131 posts on that thread - finally quiet down for the last hour 18:07:12 yyywu: or lack there of :) 18:07:24 i am impressed so many high quality discussion in one day! 18:07:40 Honestly, I feel like points of why GBP have been really been made/proven. I'm just trying to come from a point of understanding... 18:07:49 * arosen haven't 18:08:12 * arosen imho solely :) 18:08:13 that changes the statement :) 18:08:17 arosen: honestly, i think its difficult to explain it any better than what kevinbenton already has 18:09:03 arosen: i think we spoke at lenght about this at least a couple of times before as well 18:09:08 kevinbenton's last e-mail summarized it well 18:09:13 At one point there was talk that GBP provides optimizations and preformance improvements though i don't think anyone has explained why. 18:09:17 arosen: and every time the discussion seems to get reset 18:09:21 arosen: I wish you were enaged a few monts ago (or may be even before that) but I ubderstand schedules/interests changes 18:09:44 arosen: we could potentially take turns in relaying this to you in different ways, would that help? 18:09:56 I agree i wish i paid more attention to this. 18:09:57 arosen: at this point myself and kevinbenton already tried 18:10:15 arosen: the fundamental premise is not going to change though 18:10:34 arosen: i dont think performance optimization is the main issue at all; that is in my opinion but others may have different views 18:10:48 One sec* 18:10:56 banix: agree, not sure where that came from 18:11:43 * regXboi suspects people come to GP from different places and so see different aspects of the solution 18:11:58 regXboi: agree 18:11:58 I'd be interested in going through the points i commented here on the blueprint: http://lists.openstack.org/pipermail/openstack-dev/2014-August/042114.html 18:12:11 If you guys are interested in having that discussion 18:12:18 regXboi: hence the suggestion that we can take turns in explaining this, and present different perspectives :-) 18:12:58 arosen: i am not sure that we can go through all the points in this meeting 18:12:58 banix: where do you see the benefit of the new model? 18:13:12 arosen: but we can certainly pick a few of them 18:13:25 SumitNaiksatam_: okay let me pick a point then . 18:13:36 arosen: also for the records most if not all of those have been discussed at length in various different fora before 18:13:46 arosen: The optimization and performance oportunities are when things like ODL or vendor controllers can render the intent expressed in the contracts without necessarily using the same mechanisms needed for Neutron security groups, firewalls, etc.. The advantages to the user are that the API gives them a more natural way to express what they need to control. 18:13:50 arosen: we cannot keep rehashing the same discussion over and over again 18:14:13 arosen: but defintiely go ahead 18:14:29 arosen: some are listed on the spec, level of abstraction is the main factor in my view 18:15:19 rkukura: neutron's api is a logical abstraction the backend implementation can be done however a vendor chooses. Why does moving to GBP allow ODL/vendor controllers a performance improvement? 18:15:54 all: may I? 18:15:59 regXboi: please 18:16:10 neutron's logical abstraction has some inherent assumptions baked into it 18:16:29 SumitNaiksatam_: hopefully we get time to discuss the agenda :) get arosen in sync is certainly very important but it may be better to move the discussion elsewhere? just asking 18:16:35 specifically withing the concept of scoping that are not natural for an applicaiton programmer to think in 18:16:35 arosen: do you want to talk to me now outside this meeting to go through some of these? 18:16:49 arosen: Because by expressing just the intent rather than describing a specific configuration of virtual appliances, there is a lot more flexibility in how the intent gets rendered. 18:17:07 ivar-lazzaro: just a few minutes, i am still optimistic that arosen will be happy after this :-) 18:18:49 I don't want to take over your meeting perhaps following up in openstack-neutron later is a better option. 18:19:05 all: sorry - I'm getting pulled into another discussion - I'll have to go split brain for a while 18:19:24 arosen: we have certainly allocated some time on the agenda for this discussion 18:19:33 Also, I'm just trying to just understand this new model and why. I definitely hate to make you guys rehash things you have hashed. 18:19:41 arosen: if you anticipate that this is a much longer discussion then we can take it to a different place 18:19:43 arosen: there is considerable literature and research work showing that providing higher level abstractions is the way forward on managing networks 18:20:36 My question though is GBP really a higher level abstraction perhaps? I still see the same network primiatives in it similar to the model we have today. 18:20:56 arosen: gbp is a step is in that direction 18:20:58 arosen: i think you are confusing the mapping with the GBP abstraction 18:21:12 SumitNaiksatam_: +1 18:21:20 arosen: the reference implementation mapping is one way to realize GBP 18:21:46 arosen: i think you argument always starts at the mapping level 18:22:09 arosen: at which point you have fundamentally side stepped the GBP abstraction in the first place 18:22:26 arosen: there is not much to discuss in terms of differences at that point 18:22:39 So are we saying the mapping implementation isn't very useful? 18:22:52 arosen: of course it is 18:23:34 "Allow for automatic orchestration that can respond to changes in policy or infrastructure without requiring human interaction to translate intent to specific actions." 18:23:38 can we talk about that point? 18:23:50 arosen: it helps you leverage the advantages of GBP when using the neutron reference implementation (involving ML2 etc) 18:24:00 arosen: yes sure 18:24:17 what automatic orchestration does it do? 18:24:25 arosen: that particular point was well articulated in kevinbenton's responses 18:24:44 arosen: he also gave you the analogy by comparing puppet and bash scripts 18:25:20 arosen: when you use the current neutron abstractions, you require - "human interaction to translate intent to specific actions" 18:25:38 arosen: when you use GBP, you - "Allow for automatic orchestration that can respond to changes in policy or infrastructure" 18:25:48 arosen: It creates the networks, subnets, ports, routers, and security groups for you, and hooks all of these up properly to provide exactly the connectivity between EPGs described by the contracts. 18:26:11 rkukura: and it maintains the consistency of those 18:26:19 rkukura: without further human intervention 18:26:21 SumitNaiksatam_: why do you say it requires, "human interaction to translate intent to specific actions" 18:26:32 Right, as the contracts change, new EPs added to EPGs, etc. 18:27:02 arosen: i will paraphrase kevinbenton's examples for expediency here" 18:27:09 create a network/subnet for each endpoint group allow all traffic on the security groups since the logging would need to be accomplished with FWaaS create an FWaaS instance attach the FWaaS to both networks add an FWaaS policy and the FWaaS rules to allow the correct traffic 18:27:32 Manually, if you add a new VM to a pool providing some service, you need to go find all the SGs that reference that service and add the new VM’s IP (or subnet) to those SGs. This is all automatic with GBP. 18:27:53 SumitNaiksatam_: sure i understand that's the current work flow. 18:28:23 arosen: as rkukura pointed out above, and kevinbenton's example, thats the human interaction that we are referring to 18:29:25 arosen: are we good? 18:29:25 SumitNaiksatam_: cool, mind showing how one would deploy this same style of app but showing it done with group based policy? 18:29:56 arosen: i thought you were digging into the PoC script, and we spent a couple of hours discussing it 18:29:59 rkukura: i showed that you can use --remote-group-id with security groups to avoid updating any ips. 18:30:46 arosen: Yes, that is one option, or you can reference subnet’s CIDRs, … 18:31:07 arosen: the point is that you don't have to choose between SG or FW depending on your needs… That is completely handled by the implementation. 18:31:18 Lemme give it a try. arosen: suppose I'm an app developer and have deployed a db base app for a customer. I've created my policies, etc. Now I have a new customer and need to deploy pretty much the same on a new set of VMs. I just refer to the original policy and the networking happens. Am I naively correct here, guys? 18:31:32 rkukura: so i don't see why your talking about a workflow with security groups that are hard. 18:31:43 going to each security profile group etc. 18:31:48 arosen: I don’t think anyone is arguing that an experienced network engineer cannot do what they need with the current API, and with proper planning and best practices, do it efficiently. 18:32:11 rockyg: yes 18:32:50 rockyg: good example 18:32:53 so at this point we are 30 mins into the meeting 18:33:21 one another point i wanted to bring in this context was with regards to the naming convention 18:33:24 why not write all of your policy in an external system like heat which is designed to do this kind of thing? 18:33:35 Cool. And if I want to change the network interactions, I modify the policy and restart the networks on all the vms that use it? 18:33:58 arosen: you still abstractions at the network policy level to express this in heat 18:34:28 SumitNaiksatam_: I think we need to change from endpoint 18:34:31 arosen: is it fair to say we have given enough time to this discussion? 18:34:31 I don't know what to 18:34:43 regXboi: exactly :-) 18:34:47 but I think that's low hanging fruit we should seriously consider 18:34:55 so that was the next sub topic in this agenda item 18:35:01 ivar-lazzaro: also i'm not sure about your point about how a user doesn't have to choose about security groups and fwaas. These are two different points of enforcement no? 18:35:18 arosen: exactly. 18:35:35 ivar-lazzaro: you're saying with GBP the user doesn't have to decide 18:35:38 arosen: ah, now you are getting it 18:35:43 arosen: that's why you don't want to understand about that, but just expressing your intent 18:35:46 did markmcclain joined the meeting os simply started his IRC client? 18:36:07 arosen: i think we can leave the rest to you as a home work exercise ;-) 18:36:31 markmcclain: hi, you are welcome to join this meeting 18:36:50 so regarding the endpoint terminology 18:36:53 any suggestions? 18:36:56 ivar-lazzaro: If you are expressing your intent of doing enforcement at both points you do care then. 18:37:09 regXboi: Edgar Magana suggested using the IETF phrasing -- enforcement point 18:37:31 i was thinking “edgar point” would be good. and we won’t have to change our slides from EP. 18:37:44 ivar-lazzaro: would be great to see an example using the CLI how one sets something up that in GBP that does enforcement at the instance and router. 18:37:44 mschoen ++ 18:37:55 rockyg: although enforcement point tends to be used in a slightly different context 18:38:02 mscohen ++ 18:38:04 I was involved in the early IETF policy days, and I'm not a big from of ep 18:38:04 mscohen: we dont want to overload the terminology 18:38:13 regXboi: +1 18:38:17 I’m not entirely sure “enforcement point” is the same as our usage of endpoint 18:38:25 rkukura: exactly 18:38:28 SumitNaiksatam: i am joking of course 18:38:42 mscohen: :-) 18:38:54 Yeah. that's the problem with endpoint. It's right for networking, but it already has another definition in virtualization world. 18:38:54 how about network-endpoint (someone else suggested that)? 18:38:55 I think enforcement point is more like the SG or FWaaS that is used to render the intent 18:39:07 rkukura: agree 18:39:09 so... let's hit the thesaurus 18:39:16 Rkukara, agree 18:39:38 I had always throught endpoint was the right word for both our usage and for keystone, with similar meanings, but different meta-levels 18:40:01 rkukura: if we can find something different, let's consider it 18:40:11 there is enough of a hill to climb 18:40:35 how about terminus? 18:40:52 * regXboi keeps reading synonyms 18:41:06 network-endpoint? 18:41:12 um... no 18:41:27 I think that won't help 18:41:58 policy-point/policy groups? 18:42:07 group member? 18:42:14 termination-point, gbp-id, policy point maybe 18:42:18 sorry i dropped off again! 18:42:23 I think member 18:42:31 unless that's already used somewhere 18:42:33 i was saying earlier, what about policy-point? 18:42:36 #chair SumitNaiksatam 18:42:37 Current chairs: SumitNaiksatam SumitNaiksatam_ banix rkukura s3wong 18:42:41 regXboi: Just “member” and “group”? 18:42:44 s3wong: :-) 18:43:04 SumitNaiksatam: so now either way works for you :-) 18:43:09 rkurkura: too general I think... 18:43:15 policy-provider, policy-consumer 18:43:16 er rkukura ... sorry 18:43:17 i still like endpoint better. 18:43:23 bourn or bourne 1 (bɔːn) 18:43:23 18:43:23 — n 18:43:23 1. a destination; goal 18:43:23 2. a boundary 18:43:25 I think policy-point and policy-group 18:43:27 yyywu: :-) 18:43:34 Bourne-point? 18:43:40 rockyg: :-) 18:44:04 more in favor of policy-point and policy-group? 18:44:36 i thnk LouisF suggested as well 18:44:49 +1 to policy-point 18:44:50 +1 to policy-point and policy-group 18:44:55 +1 18:44:56 SumitNaiksatam: +1 too 18:45:07 +1 18:45:08 FINALLY... YEAH 18:45:18 okay so how about we float this in the ML? 18:45:21 +1 18:45:31 +1 18:45:35 Yes... lets do that 18:45:37 +1 18:45:44 so that we dont end up picking up an overlapping terminology again 18:45:55 who wants to do it? as in send to the ML? 18:46:07 * SumitNaiksatam waiting to hand out an AI :-P 18:46:16 regXboi: ? 18:46:17 I can do it 18:46:26 hmm? 18:46:31 rms_13: ah you put your hand up first 18:46:36 * regXboi apologies - bouncing between multiple IRC meetings 18:46:47 policy-endpoint ? 18:46:57 #action rms_13 to send “policy-point” “policy-group” suggestion to mailing list 18:47:01 NO END to the ENDPOINT :) 18:47:04 regXboi: ^^^ fine? 18:47:09 hemanthravi: no wont work 18:47:11 rms_13: lol 18:47:18 SumitNaiksatam: works for me 18:47:28 hemanthravi: see the AI above 18:47:30 I guess the acronyms PP and PG work 18:47:37 let's get that complaint cleared up 18:47:40 policy-point and policy-group. Final. Lets move to another topic ? 18:47:43 +1 18:47:55 +1 18:47:59 i knew rkukura would be thinking acronyms, just waiting :-D 18:48:15 yeah lets move on 18:48:16 * regXboi chants "... and there was much rejoicing ..." 18:48:25 Huzzah! 18:48:31 #topic Patch reviews 18:49:01 -2 still persists, markmcclain1 can hopefully chime on the thread on the ML and help us make progress here 18:50:19 #topic model update 18:50:19 nothing besides the endpoint naming convention 18:50:19 SumitNaiksatam: I put +1s on the CLI ones earlier today - I reserve the right to change if I run into issues ;) 18:50:19 #topic mapping udpate 18:50:19 (sorry about being late) 18:50:19 regXboi: sweet, getting to the CLI 18:50:19 rkukura: any updates on the mapping? 18:50:19 we will SG mapping separately 18:50:19 different agenda item 18:50:38 No, just that I added code to reject changing a PG’s PP in the last rebase 18:50:38 I mean a PP’s PG, sorry 18:50:38 rkukura: nice catch on that 18:50:43 rkukura: :-) 18:50:54 rkukura: i think that was in response to reviewer’s comments? 18:51:03 yes, on the API patch 18:51:05 rkukura: thanks for that 18:51:16 #topic SG mapping update 18:51:18 s3wong: ? 18:51:41 yes 18:51:54 sorry on flaky connection… I have reservations the API changes 18:52:03 the changes leak out details of the underlay 18:52:14 still working on the patch, hopefully will send out a first patch sometimes this week (or weekend) 18:52:15 markmcclain1: which API changes? 18:52:23 s3wong: great, thanks 18:52:47 marun: hi 18:52:49 markmcclain1: please elaborate 18:53:03 markmcclain1: this is the GBP meeting 18:53:14 banix: hi 18:53:19 oops repasted wrong response 18:53:30 markmcclain1: np, guessed as much 18:53:43 so on the GPB discussion I was on jury duty yesterday 18:53:44 markmcclain1: for a minute i thought, wow, we are making progress here! ;-) 18:53:58 marun: in the GBP meeting… wondering how you and markmcclain1 think of the discussion on the ML 18:54:10 markmcclain1: we do understand you have personal committments 18:54:29 markmcclain1: is it appropriate to hold up an entire team of people for that reason though? 18:54:33 banix: I haven't fully caught up I'm afraid. 18:54:36 SumitNaiksatam: I will reply on this http://lists.openstack.org/pipermail/openstack-dev/2014-August/042243.html please confirm 18:54:44 markmcclain1: i am referring to the -2 18:55:03 rms_13: i think you can start separate thread 18:55:18 marun: sure; hope to hear from you soon. 18:55:20 rms_13: use [policy] in the subject header 18:55:24 banix: I've been talking a bunch with rkukura directly about the issue, so my input has been in play even if it appears not. 18:55:41 marun: i see 18:55:53 SumitNaiksatam: Fine 18:55:58 rkukura: perhaps you can relay the input for the benefit of everybody, if you think its appropriate? 18:56:13 s3wong: sorry for hijacking the SG mapping topic 18:56:28 SumitNaiksatam: I am done with my update anyway, please change topic if you like :-) 18:56:28 #topic Input from markmcclain1 and marun 18:56:58 SumitNaiksatam: I’d really rather marun summarize his own thoughts if he is here and thinks they will be valuable. We’ve discussed a number of things. 18:57:10 rkukura: sure 18:57:16 marun: do you feel comfortable doing that? 18:57:17 I don’t want to put words in his mouth he didn’t say 18:57:30 Well, I've said alot of things. 18:57:37 rkukura: sure, i just asked because marun seemed to indicate that you were on the same page 18:57:49 One area we’ve discussed is setting expectations properly about the stability of the API in an initial release 18:57:55 Right 18:58:07 rkukura marun: agree 18:58:20 i believe that is the case with every new extension we add 18:58:23 Allowing a new and as-yet unproven api into the tree would require some groundwork that hasn't been done yet. 18:58:50 We'd have to be able to address Mark's concerns about having to support unstable API's (and slowing down evolution in the process) 18:58:53 marun: how is it different from any other extension that has been introduced in neutron? 18:59:00 But it wouldn’t be the first time we’ve done it, either 18:59:06 SumitNaiksatam: I'm afraid we're playing catch-up here. 18:59:38 SumitNaiksatam: The impression outside of the project is that things like lbass, vpnaas, and fwaas have been stabilized too soon. 18:59:47 marun: well, to some extent i can definitely say that we have tried to incorporate from those past experiences 18:59:53 SumitNaiksatam: Whether or not we as a project believe that to be true, I think we need to consider that feedback. 19:00:00 marun: sure 19:00:04 so I've switched to a more stable conneciton… I'm actually working on a refinement to the plan 19:00:25 that incorporates lots of feedback I've gotten and addresses LBaaSv2 too 19:00:31 we have hit the hour, but we can continue until we are kicked out 19:00:38 SumitNaiksatam: Going forward, I think we need to make sure that new APIs and features can continue to evolve and don't impose the burden of stabilization. 19:00:58 marun: seems like a reasonable thing to state 19:01:02 SumitNaiksatam: I don't think this problem is unique to group policy, but we're having to confront it as part of the initiative. 19:01:35 markmcclain: i am not too comfortable with you, as one person, making the plans for the rest of the project 19:01:35 The details of how we accomplish these goals would have to be determined. 19:01:50 markmcclain: i am referring to - “I'm actually working on a refinement to the plan" 19:01:57 markmcclain: we are having a discussion on the ML 19:02:05 markmcclain: please participate 19:02:06 SumitNaiksatam: He can propose plans. And we as a community will give feedback and ultimately decide what to do. 19:02:14 markmcclain: the plan has to evolve 19:02:24 markmcclain: it cannot be one person handing out things 19:02:39 SumitNaiksatam: Let's be clear - Mark is not acting alone. 19:02:42 and while at that we dont have the luxury of infinite time here 19:02:43 SumitNaiksatam: it is.. there were 90+ messages to catch up while on jury duty 19:03:16 SumitNaiksatam: +1. Also, this kind of planning should be referred to the next release without blocking what is already approved and implemented 19:03:18 i can already see you coming back in a couple of weeks and saying that its too late now to review and i am goint to put a -2 19:03:18 Not sure if its at all related to markmcclain’s plan, but marun, myself, and a couple others have kicked around the idea of labeling a feature as a “preview” until its API is declared stable. It would still be in-tree, subject to normal reviews, etc.. 19:03:42 ivar-lazzaro: sorry, that's not what's going to happen. 19:03:44 markmcclain: i totally sympathize with you, and appreciate you personal situation 19:03:53 rkukura: my plan would deal with all preview eligible APIs which is more than just policy 19:03:55 markmcclain: however you have blocked this effort for more than a month 19:04:10 markmcclain: without providing a single reason 19:04:16 SumitNaiksatam: As I've expressed to rkukura, Mark is not blocking this out of being obstinate. 19:04:20 marun: as long as it's a community decision… I'm telling my point of view. 19:04:23 SumitNaiksatam: sorry I don't regret working to find a community solution to a very real problem 19:04:30 markmcclain: and utilimately you come up with an unreasonable proposal to throw the whole thing under the bus 19:04:38 SumitNaiksatam: He is the roadblock you see, but he has weight of numbers behind him whether you want to recognize it or not. 19:04:57 whoa folks 19:05:01 marun: what numbers are talking here? 19:05:10 let's back up 19:05:15 markmcclain: Mark, could you tell us a bit more about the revised plan you are going to suggest 19:05:18 +1 regXboi 19:05:20 from what I gather it seems unfair to blame a single person for the sticky -2 on the patch. If it weren’t him it probably were somebody else. 19:05:23 I'm interested in hearing what the proposal is? 19:05:51 banix: +1 19:05:55 salv-orlando: markmcclain marun: my point is not about the people 19:05:55 yeah lets get back to the proposal 19:06:03 my point is about the process 19:06:07 SumitNaiksatam: All the folks that have issues with this initiative whose voices are being ignored in favor of those that support it. 19:06:12 regXboi, banix: it's been something I've working on today 19:06:13 regXboi banix: yes sure 19:06:29 marun: that is a blatantly incorrect statement 19:06:29 it also clarifies lots of process items 19:06:37 SumitNaiksatam: If you don't think that this is true, then you are uninformed. 19:06:43 SumitNaiksatam: +1 for the process 19:06:47 markmcclain: please go on 19:06:52 SumitNaiksatam: It matters if you want to understand why this initiative is not moving forward as quickly as you would like. 19:06:56 markmcclain: yes please go on 19:06:56 I'm curious to hear it, even in draft form... 19:07:02 SumitNaiksatam: I hope so… actually I’m quite sure of that, but it’s still good to remind that it’s not about blaming individual. If that was the case, we would have eliminated markmcclain with potassium cyanide back in Atl 19:07:15 SumitNaiksatam: This group does bear some responsibility for the situation they are in, whether it wants to recognize that or not. 19:07:19 I'll post it later today after finishing up the details 19:07:24 salv-orlando: agree 100%, its not about blaming individual 19:07:45 * regXboi is slightly disappointed, his curiosity was piqued 19:07:52 marun: i am still at a loss to understand 19:08:01 SumitNaiksatam: That's kind of the point. 19:08:05 does anyone else here know what marun is referring to? 19:08:07 SumitNaiksatam: You've been a core for how long? 19:08:08 markmcclain: Can you give a quick outline, and would it allow GBP in the release? 19:08:20 understand everyone wants to see it, but I'd prefer to have a more intact proposal a sketch with lots of gaps 19:08:20 marun: how is that relevant? 19:08:31 SumitNaiksatam: With respect, there are trust and relationship issues around this initiative that are causing lots of friction. 19:08:31 marun: are we getting personal details now? 19:08:32 I see a lot of argument, more or less opinionated, pro and cons this new API. Am I allowed to ask something as somebody who simply doesn’t care? 19:08:44 SumitNaiksatam: No, it's simply an observation that open source is a messy human business. 19:08:55 markmcclain: oh well, understood 19:09:03 salv-orlando: please 19:09:04 ok i think let’s have this discussion on ML after markmcclain posts his comments 19:09:06 who loses if this is delayed for further discussion? 19:09:24 I mean is this going to hurt the user commnity? 19:09:29 just a note to everyone, that we are past the meeting time, 10 mins over 19:09:46 SumitNaiksatam: sorry I did not even realized this was the meeting channel 19:09:56 salv-orlando: there were several posts to the ML from folks who (I believe) are not here but are looking for GP to land in Juno 19:09:57 I'm not committed to having it in vs out of the tree at this point. 19:09:59 SumitNaiksatam: as you said let’s talk more unless there is another meeting 19:10:05 salv-orlando: no worries, we are waiting until we get kicked out 19:10:21 regXboi: +1. A lot of them. 19:10:22 salv-orlando: but i just wanted to make the process point that we are over 19:10:26 "are not here" meaning "did not contribute to this process" 19:10:35 gack! s/process/project/ 19:10:39 SumitNaiksatam: yes, thanks. 19:10:40 ok so we have active users relying on this feature to be available in trunk in juno for their deployments? 19:10:42 But we need to solve the problem I spoke of earlier - minimizing the maintenance burden of an unstable api and allow it to evolve with minimal friction - if it is to go into the tree this cycle. 19:10:46 regXboi: not sure if they are taken into account though, together with all the work done to get this in place. 19:11:00 If we don't have an answer for this, then no, I don't think it should be merged. 19:11:03 salv-orlando: I believe I can say that 19:11:06 we have some brave users out there ;) 19:11:23 salv-orlando: I believe I can say that I am planning on using it as an operator, not as a vendor 19:11:38 if it lands in Juno, that is 19:11:45 if it doesn't then I have to go find another solution 19:11:46 regXboi: echo chamber, much? 19:11:49 marun: how do you do that if in the tree? 19:12:11 marun: didn't get the reference, sorry 19:12:13 marun: i mean minimizing the maintenance 19:12:19 marun: So you propose to do bug fixing in tree and literally everything else out of tree? 19:12:21 banix: One possibility would be putting it into an 'experimental' subtree, and an 'experimental' rest path. 19:12:26 * regXboi not at best form - too many nights chasing defects 19:12:57 banix: This would allow us to clearly demarcate efforts that haven't been finalized, so that we wouldn't have to provide full support. 19:13:07 marun: is there any other project that do this? 19:13:15 regXboi: just saying, we’ve used stuff that was delayed off trunk in the past. But maybe our cloud is small and more manageable, so picking a package from somewhere else is easier. 19:13:24 banix: No. Projects like nova are better at saying 'no'. 19:13:37 marun: wouldnt that approach open up a kitchen sync for future? 19:13:51 salv-orlando: yeah, I have all sorts of gates to go through if this lands outside the tree 19:13:51 rms_13: We need to be able to fail-fast as per Mark's email. 19:13:57 not that I can't go through them 19:14:03 it just becomes a whole different ball game 19:14:08 but that's neither here nor there 19:14:10 rms_13: We could do it out of tree, as he suggests, but then re-integration is a problem (as you've experienced) 19:14:28 marun: The subtree the kind of thing you and I were discussing, and I could support this if labeled something like “preview” instead of “experimental” and if it really targets code that is working its way towards a stable API and does not end up being a long-term place to dump code. 19:14:42 rkukura: +1 19:14:47 rms_13: Ideally we would figure out a way to iterate faster in the tree but not accept a feature as something we want to keep until it's considered 'fully baked' 19:14:53 rkukura: i like the preview terminology 19:14:58 marun: I could live with the idea rkukura just stated 19:15:03 rkukura: +1 19:15:06 +1 rkukura. I think this is good for neutron in general to have. and works for this project. 19:15:28 markmcclain: you still around? 19:15:36