18:01:34 <SumitNaiksatam_> #startmeeting networking_policy
18:01:35 <s3wong> SumitNaiksatam_: seems like it, probably good to appoint another chair then
18:01:35 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:38 <openstack> The meeting name has been set to 'networking_policy'
18:01:47 <SumitNaiksatam_> banix: :-)
18:02:01 <SumitNaiksatam_> #chair rkukura banix s3wong
18:02:02 <openstack> Current chairs: SumitNaiksatam_ banix rkukura s3wong
18:02:19 <SumitNaiksatam_> whew! got that out of the way
18:02:22 * regXboi notes SumitNaiksatam has learned well :)
18:02:31 <SumitNaiksatam_> regXboi: ;-)
18:02:46 <SumitNaiksatam_> #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
18:03:14 <SumitNaiksatam_> i hope everyone slept well yesterday! ;-)
18:03:49 <SumitNaiksatam_> #topic Mailing list discussion on GBP
18:04:30 <SumitNaiksatam_> so I think good arguments have been made in favor of doing this in-tree
18:04:36 <SumitNaiksatam_> in the mailing list yesterday
18:05:12 <SumitNaiksatam_> what does everyone else think?
18:05:25 * regXboi has been waffling back and forth
18:06:01 <ivar-lazzaro> SumitNaiksatam_: +1, there has been a good response.
18:06:17 * banix surprisingly in good spirit :)
18:06:27 <SumitNaiksatam_> banix: :-)
18:06:45 <yyywu> i am glad to know so many people are interesting on GBP.
18:06:59 <s3wong> 131 posts on that thread - finally quiet down for the last hour
18:07:12 <banix> yyywu: or lack there of :)
18:07:24 <yyywu> i am impressed so many high quality discussion in one day!
18:07:40 <arosen> 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 <banix> that changes the statement :)
18:08:17 <SumitNaiksatam_> arosen: honestly, i think its difficult to explain it any better than what kevinbenton already has
18:09:03 <SumitNaiksatam_> arosen: i think we spoke at lenght about this at least a couple of times before as well
18:09:08 <hemanthravi> kevinbenton's last e-mail summarized it well
18:09:13 <arosen> 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 <SumitNaiksatam_> arosen: and every time the discussion seems to get reset
18:09:21 <banix> 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 <SumitNaiksatam_> arosen: we could potentially take turns in relaying this to you in different ways, would that help?
18:09:56 <arosen> I agree i wish i paid more attention to this.
18:09:57 <SumitNaiksatam_> arosen: at this point myself and kevinbenton already tried
18:10:15 <SumitNaiksatam_> arosen: the fundamental premise is not going to change though
18:10:34 <banix> 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 <arosen> One sec*
18:10:56 <SumitNaiksatam_> 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 <SumitNaiksatam_> regXboi: agree
18:11:58 <arosen> 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 <arosen> If you guys are interested in having that discussion
18:12:18 <SumitNaiksatam_> regXboi: hence the suggestion that we can take turns in explaining this, and present different perspectives :-)
18:12:58 <SumitNaiksatam_> arosen: i am not sure that we can go through all the points in this meeting
18:12:58 <arosen> banix:  where do you see the benefit of the new model?
18:13:12 <SumitNaiksatam_> arosen: but we can certainly pick a few of them
18:13:25 <arosen> SumitNaiksatam_:  okay let me pick a point then .
18:13:36 <SumitNaiksatam_> arosen: also for the records most if not all of those have been discussed at length in various different fora before
18:13:46 <rkukura> 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 <SumitNaiksatam_> arosen: we cannot keep rehashing the same discussion over and over again
18:14:13 <SumitNaiksatam_> arosen: but defintiely go ahead
18:14:29 <banix> arosen: some are listed on the spec, level of abstraction is the main factor in my view
18:15:19 <arosen> 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 <regXboi> all: may I?
18:15:59 <SumitNaiksatam_> regXboi: please
18:16:10 <regXboi> neutron's logical abstraction has some inherent assumptions baked into it
18:16:29 <ivar-lazzaro> 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 <regXboi> specifically withing the concept of scoping that are not natural for an applicaiton programmer to think in
18:16:35 <mscohen> arosen: do you want to talk to me now outside this meeting to go through some of these?
18:16:49 <rkukura> 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 <SumitNaiksatam_> ivar-lazzaro: just a few minutes, i am still optimistic that arosen will be happy after this :-)
18:18:49 <arosen> I don't want to take over your meeting perhaps following up in openstack-neutron later is a better option.
18:19:05 <regXboi> all: sorry - I'm getting pulled into another discussion - I'll have to go split brain for a while
18:19:24 <SumitNaiksatam_> arosen: we have certainly allocated some time on the agenda for this discussion
18:19:33 <arosen> 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 <SumitNaiksatam_> arosen: if you anticipate that this is a much longer discussion then we can take it to a different place
18:19:43 <LouisF> arosen: there is considerable literature and research work showing that providing higher level abstractions is the way forward on managing networks
18:20:36 <arosen> 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 <LouisF> arosen: gbp is a step is in that direction
18:20:58 <SumitNaiksatam_> arosen: i think you are confusing the mapping with the GBP abstraction
18:21:12 <ivar-lazzaro> SumitNaiksatam_: +1
18:21:20 <SumitNaiksatam_> arosen: the reference implementation mapping is one way to realize GBP
18:21:46 <SumitNaiksatam_> arosen: i think you argument always starts at the mapping level
18:22:09 <SumitNaiksatam_> arosen: at which point you have fundamentally side stepped the GBP abstraction in the first place
18:22:26 <SumitNaiksatam_> arosen: there is not much to discuss in terms of differences at that point
18:22:39 <arosen> So are we saying the mapping implementation isn't very useful?
18:22:52 <SumitNaiksatam_> arosen: of course it is
18:23:34 <arosen> "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 <arosen> can we talk about that point?
18:23:50 <SumitNaiksatam_> arosen: it helps you leverage the advantages of GBP when using the neutron reference implementation (involving ML2 etc)
18:24:00 <SumitNaiksatam_> arosen: yes sure
18:24:17 <arosen> what automatic orchestration does it do?
18:24:25 <SumitNaiksatam_> arosen: that particular point was well articulated in kevinbenton's responses
18:24:44 <SumitNaiksatam_> arosen: he also gave you the analogy by comparing puppet and bash scripts
18:25:20 <SumitNaiksatam_> arosen: when you use the current neutron abstractions, you require - "human interaction to translate intent to specific actions"
18:25:38 <SumitNaiksatam_> arosen: when you use GBP, you - "Allow for automatic orchestration that can respond to changes in policy or infrastructure"
18:25:48 <rkukura> 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 <SumitNaiksatam_> rkukura: and it maintains the consistency of those
18:26:19 <SumitNaiksatam_> rkukura: without further human intervention
18:26:21 <arosen> SumitNaiksatam_:  why do you say it requires, "human interaction to translate intent to specific actions"
18:26:32 <rkukura> Right, as the contracts change, new EPs added to EPGs, etc.
18:27:02 <SumitNaiksatam_> arosen: i will paraphrase kevinbenton's examples for expediency here"
18:27:09 <SumitNaiksatam_> 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 <rkukura> 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 <arosen> SumitNaiksatam_:  sure i understand that's the current work flow.
18:28:23 <SumitNaiksatam_> arosen: as rkukura pointed out above, and kevinbenton's example, thats the human interaction that we are referring to
18:29:25 <SumitNaiksatam_> arosen: are we good?
18:29:25 <arosen> SumitNaiksatam_:  cool, mind showing how one would deploy this same style of app but showing it done with group based policy?
18:29:56 <SumitNaiksatam_> arosen: i thought you were digging into the PoC script, and we spent a couple of hours discussing it
18:29:59 <arosen> rkukura:  i showed that you can use --remote-group-id with security groups to avoid updating any ips.
18:30:46 <rkukura> arosen: Yes, that is one option, or you can reference subnet’s CIDRs, …
18:31:07 <ivar-lazzaro> 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 <rockyg> 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 <arosen> rkukura:  so i don't see why your talking about a workflow with security groups that are hard.
18:31:43 <arosen> going to each security profile group etc.
18:31:48 <rkukura> 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 <SumitNaiksatam_> rockyg: yes
18:32:50 <arosen> rockyg:  good example
18:32:53 <SumitNaiksatam_> so at this point we are 30 mins into the meeting
18:33:21 <SumitNaiksatam_> one another point i wanted to bring in this context was with regards to the naming convention
18:33:24 <arosen> 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 <rockyg> 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 <SumitNaiksatam_> arosen: you still abstractions at the network policy level to express this in heat
18:34:28 <regXboi> SumitNaiksatam_: I think we need to change from endpoint
18:34:31 <SumitNaiksatam_> arosen: is it fair to say we have given enough time to this discussion?
18:34:31 <regXboi> I don't know what to
18:34:43 <SumitNaiksatam_> regXboi: exactly :-)
18:34:47 <regXboi> but I think that's low hanging fruit we should seriously consider
18:34:55 <SumitNaiksatam_> so that was the next sub topic in this agenda item
18:35:01 <arosen> 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 <ivar-lazzaro> arosen: exactly.
18:35:35 <arosen> ivar-lazzaro:  you're saying with GBP the user doesn't have to decide
18:35:38 <SumitNaiksatam_> arosen: ah, now you are getting it
18:35:43 <ivar-lazzaro> arosen: that's why you don't want to understand about that, but just expressing your intent
18:35:46 <banix> did markmcclain joined the meeting os simply started his IRC client?
18:36:07 <SumitNaiksatam_> arosen: i think we can leave the rest to you as a home work exercise ;-)
18:36:31 <SumitNaiksatam_> markmcclain: hi, you are welcome to join this meeting
18:36:50 <SumitNaiksatam_> so regarding the endpoint terminology
18:36:53 <SumitNaiksatam_> any suggestions?
18:36:56 <arosen> ivar-lazzaro:  If you are expressing your intent of doing enforcement at both points you do care then.
18:37:09 <rockyg> regXboi: Edgar Magana suggested using the IETF phrasing -- enforcement point
18:37:31 <mscohen> i was thinking “edgar point” would be good.  and we won’t have to change our slides from EP.
18:37:44 <arosen> 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 <rockyg> mschoen ++
18:37:55 <SumitNaiksatam_> rockyg: although enforcement point tends to be used in a slightly different context
18:38:02 <rockyg> mscohen ++
18:38:04 <regXboi> I was involved in the early IETF policy days, and I'm not a big from of ep
18:38:04 <SumitNaiksatam_> mscohen: we dont want to overload the terminology
18:38:13 <SumitNaiksatam_> regXboi: +1
18:38:17 <rkukura> I’m not entirely sure “enforcement point” is the same as our usage of endpoint
18:38:25 <SumitNaiksatam_> rkukura: exactly
18:38:28 <mscohen> SumitNaiksatam: i am joking of course
18:38:42 <SumitNaiksatam_> mscohen: :-)
18:38:54 <rockyg> Yeah.  that's the problem with endpoint.  It's right for networking, but it already has another definition in virtualization world.
18:38:54 <SumitNaiksatam_> how about network-endpoint (someone else suggested that)?
18:38:55 <rkukura> I think enforcement point is more like the SG or FWaaS that is used to render the intent
18:39:07 <SumitNaiksatam_> rkukura: agree
18:39:09 <regXboi> so... let's hit the thesaurus
18:39:16 <rockyg> Rkukara, agree
18:39:38 <rkukura> 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 <regXboi> rkukura: if we can find something different, let's consider it
18:40:11 <regXboi> there is enough of a hill to climb
18:40:35 <regXboi> how about terminus?
18:40:52 * regXboi keeps reading synonyms
18:41:06 <rms_13> network-endpoint?
18:41:12 <regXboi> um... no
18:41:27 <regXboi> I think that won't help
18:41:58 <LouisF> policy-point/policy groups?
18:42:07 <rkukura> group member?
18:42:14 <mscohen> termination-point, gbp-id, policy point maybe
18:42:18 <SumitNaiksatam> sorry i dropped off again!
18:42:23 <regXboi> I think member
18:42:31 <regXboi> unless that's already used somewhere
18:42:33 <SumitNaiksatam> i was saying earlier, what about policy-point?
18:42:36 <s3wong> #chair SumitNaiksatam
18:42:37 <openstack> Current chairs: SumitNaiksatam SumitNaiksatam_ banix rkukura s3wong
18:42:41 <rkukura> regXboi: Just “member” and “group”?
18:42:44 <SumitNaiksatam> s3wong: :-)
18:43:04 <s3wong> SumitNaiksatam: so now either way works for you :-)
18:43:09 <regXboi> rkurkura: too general I think...
18:43:15 <nbouthors> policy-provider, policy-consumer
18:43:16 <regXboi> er rkukura ... sorry
18:43:17 <yyywu> i still like endpoint better.
18:43:23 <rockyg> bourn or bourne 1  (bɔːn)
18:43:23 <rockyg> 
18:43:23 <rockyg> — n
18:43:23 <rockyg> 1.  a destination; goal
18:43:23 <rockyg> 2.      a boundary
18:43:25 <regXboi> I think policy-point and policy-group
18:43:27 <SumitNaiksatam> yyywu: :-)
18:43:34 <rockyg> Bourne-point?
18:43:40 <SumitNaiksatam> rockyg: :-)
18:44:04 <SumitNaiksatam> more in favor of policy-point and policy-group?
18:44:36 <SumitNaiksatam> i thnk LouisF suggested as well
18:44:49 <mscohen> +1 to policy-point
18:44:50 <rms_13> +1 to policy-point and policy-group
18:44:55 <yyywu> +1
18:44:56 <nbouthors> SumitNaiksatam: +1 too
18:45:07 <rockyg> +1
18:45:08 <rms_13> FINALLY... YEAH
18:45:18 <SumitNaiksatam> okay so how about we float this in the ML?
18:45:21 <s3wong> +1
18:45:31 <prasadv> +1
18:45:35 <rms_13> Yes... lets do that
18:45:37 <rkukura> +1
18:45:44 <SumitNaiksatam> so that we dont end up picking up an overlapping terminology again
18:45:55 <SumitNaiksatam> 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 <SumitNaiksatam> regXboi: ?
18:46:17 <rms_13> I can do it
18:46:26 <regXboi> hmm?
18:46:31 <SumitNaiksatam> rms_13: ah you put your hand up first
18:46:36 * regXboi apologies - bouncing between multiple IRC meetings
18:46:47 <hemanthravi> policy-endpoint ?
18:46:57 <SumitNaiksatam> #action rms_13 to send “policy-point” “policy-group” suggestion to mailing list
18:47:01 <rms_13> NO END to the ENDPOINT :)
18:47:04 <SumitNaiksatam> regXboi: ^^^ fine?
18:47:09 <banix> hemanthravi: no wont work
18:47:11 <SumitNaiksatam> rms_13: lol
18:47:18 <regXboi> SumitNaiksatam: works for me
18:47:28 <SumitNaiksatam> hemanthravi: see the AI above
18:47:30 <rkukura> I guess the acronyms PP and PG work
18:47:37 <regXboi> let's get that complaint cleared up
18:47:40 <rms_13> policy-point and policy-group. Final. Lets move to another topic ?
18:47:43 <LouisF> +1
18:47:55 <songole> +1
18:47:59 <SumitNaiksatam> i knew rkukura would be thinking acronyms, just waiting :-D
18:48:15 <SumitNaiksatam> yeah lets move on
18:48:16 * regXboi chants "... and there was much rejoicing ..."
18:48:25 <rockyg> Huzzah!
18:48:31 <SumitNaiksatam> #topic Patch reviews
18:49:01 <SumitNaiksatam> -2 still persists, markmcclain1 can hopefully chime on the thread on the ML and help us make progress here
18:50:19 <SumitNaiksatam> #topic model update
18:50:19 <SumitNaiksatam> nothing besides the endpoint naming convention
18:50:19 <regXboi> SumitNaiksatam: I put +1s on the CLI ones earlier today - I reserve the right to change if I run into issues ;)
18:50:19 <SumitNaiksatam> #topic mapping udpate
18:50:19 <regXboi> (sorry about being late)
18:50:19 <SumitNaiksatam> regXboi: sweet, getting to the CLI
18:50:19 <SumitNaiksatam> rkukura: any updates on the mapping?
18:50:19 <SumitNaiksatam> we will SG mapping separately
18:50:19 <SumitNaiksatam> different agenda item
18:50:38 <rkukura> No, just that I added code to reject changing a PG’s PP in the last rebase
18:50:38 <rkukura> I mean a PP’s PG, sorry
18:50:38 <SumitNaiksatam> rkukura: nice catch on that
18:50:43 <SumitNaiksatam> rkukura: :-)
18:50:54 <SumitNaiksatam> rkukura: i think that was in response to reviewer’s comments?
18:51:03 <rkukura> yes, on the API patch
18:51:05 <SumitNaiksatam> rkukura: thanks for that
18:51:16 <SumitNaiksatam> #topic SG mapping update
18:51:18 <SumitNaiksatam> s3wong: ?
18:51:41 <s3wong> yes
18:51:54 <markmcclain1> sorry on flaky connection… I have reservations the API changes
18:52:03 <markmcclain1> the changes leak out details of the underlay
18:52:14 <s3wong> still working on the patch, hopefully will send out a first patch sometimes this week (or weekend)
18:52:15 <SumitNaiksatam> markmcclain1: which API changes?
18:52:23 <SumitNaiksatam> s3wong: great, thanks
18:52:47 <banix> marun: hi
18:52:49 <s3wong> markmcclain1: please elaborate
18:53:03 <SumitNaiksatam> markmcclain1: this is the GBP meeting
18:53:14 <marun> banix: hi
18:53:19 <markmcclain1> oops repasted wrong response
18:53:30 <SumitNaiksatam> markmcclain1: np, guessed as much
18:53:43 <markmcclain1> so on the GPB discussion I was on jury duty yesterday
18:53:44 <SumitNaiksatam> markmcclain1: for a minute i thought, wow, we are making progress here! ;-)
18:53:58 <banix> marun: in the GBP meeting… wondering how you and markmcclain1 think of the discussion on the ML
18:54:10 <SumitNaiksatam> markmcclain1: we do understand you have personal committments
18:54:29 <SumitNaiksatam> markmcclain1: is it appropriate to hold up an entire team of people for that reason though?
18:54:33 <marun> banix: I haven't fully caught up I'm afraid.
18:54:36 <rms_13> SumitNaiksatam: I will reply on this http://lists.openstack.org/pipermail/openstack-dev/2014-August/042243.html  please confirm
18:54:44 <SumitNaiksatam> markmcclain1: i am referring to the -2
18:55:03 <SumitNaiksatam> rms_13: i think you can start separate thread
18:55:18 <banix> marun: sure; hope to hear from you soon.
18:55:20 <SumitNaiksatam> rms_13: use [policy] in the subject header
18:55:24 <marun> 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 <banix> marun: i see
18:55:53 <rms_13> SumitNaiksatam: Fine
18:55:58 <SumitNaiksatam> rkukura: perhaps you can relay the input for the benefit of everybody, if you think its appropriate?
18:56:13 <SumitNaiksatam> s3wong: sorry for hijacking the SG mapping topic
18:56:28 <s3wong> SumitNaiksatam: I am done with my update anyway, please change topic if you like :-)
18:56:28 <SumitNaiksatam> #topic Input from markmcclain1 and marun
18:56:58 <rkukura> 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 <SumitNaiksatam> rkukura: sure
18:57:16 <SumitNaiksatam> marun: do you feel comfortable doing that?
18:57:17 <rkukura> I don’t want to put words in his mouth he didn’t say
18:57:30 <marun> Well, I've said alot of things.
18:57:37 <SumitNaiksatam> rkukura: sure, i just asked because marun seemed to indicate that you were on the same page
18:57:49 <rkukura> One area we’ve discussed is setting expectations properly about the stability of the API in an initial release
18:57:55 <marun> Right
18:58:07 <SumitNaiksatam> rkukura marun: agree
18:58:20 <SumitNaiksatam> i believe that is the case with every new extension we add
18:58:23 <marun> Allowing a new and as-yet unproven api into the tree would require some groundwork that hasn't been done yet.
18:58:50 <marun> 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 <SumitNaiksatam> marun: how is it different from any other extension that has been introduced in neutron?
18:59:00 <rkukura> But it wouldn’t be the first time we’ve done it, either
18:59:06 <marun> SumitNaiksatam: I'm afraid we're playing catch-up here.
18:59:38 <marun> SumitNaiksatam: The impression outside of the project is that things like lbass, vpnaas, and fwaas have been stabilized too soon.
18:59:47 <SumitNaiksatam> marun: well, to some extent i can definitely say that we have tried to incorporate from those past experiences
18:59:53 <marun> SumitNaiksatam: Whether or not we as a project believe that to be true, I think we need to consider that feedback.
19:00:00 <SumitNaiksatam> marun: sure
19:00:04 <markmcclain> so I've switched to a more stable conneciton… I'm actually working on a refinement to the plan
19:00:25 <markmcclain> that incorporates lots of feedback I've gotten and addresses LBaaSv2 too
19:00:31 <SumitNaiksatam> we have hit the hour, but we can continue until we are kicked out
19:00:38 <marun> 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 <SumitNaiksatam> marun: seems like a reasonable thing to state
19:01:02 <marun> 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 <SumitNaiksatam> markmcclain: i am not too comfortable with you, as one person, making the plans for the rest of the project
19:01:35 <marun> The details of how we accomplish these goals would have to be determined.
19:01:50 <SumitNaiksatam> markmcclain: i am referring to - “I'm actually working on a refinement to the plan"
19:01:57 <SumitNaiksatam> markmcclain: we are having a discussion on the ML
19:02:05 <SumitNaiksatam> markmcclain: please participate
19:02:06 <marun> SumitNaiksatam: He can propose plans.  And we as a community will give feedback and ultimately decide what to do.
19:02:14 <SumitNaiksatam> markmcclain: the plan has to evolve
19:02:24 <SumitNaiksatam> markmcclain: it cannot be one person handing out things
19:02:39 <marun> SumitNaiksatam: Let's be clear - Mark is not acting alone.
19:02:42 <SumitNaiksatam> and while at that we dont have the luxury of infinite time here
19:02:43 <markmcclain> SumitNaiksatam: it is.. there were 90+ messages to catch up while on jury duty
19:03:16 <ivar-lazzaro> 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 <SumitNaiksatam> 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 <rkukura> 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 <marun> ivar-lazzaro: sorry, that's not what's going to happen.
19:03:44 <SumitNaiksatam> markmcclain: i totally sympathize with you, and appreciate you personal situation
19:03:53 <markmcclain> rkukura: my plan would deal with all preview eligible APIs which is more than just policy
19:03:55 <SumitNaiksatam> markmcclain: however you have blocked this effort for more than a month
19:04:10 <SumitNaiksatam> markmcclain: without providing a single reason
19:04:16 <marun> SumitNaiksatam: As I've expressed to rkukura, Mark is not blocking this out of being obstinate.
19:04:20 <ivar-lazzaro> marun: as long as it's a community decision… I'm telling my point of view.
19:04:23 <markmcclain> SumitNaiksatam: sorry I don't regret working to find a community solution to a very real problem
19:04:30 <SumitNaiksatam> markmcclain: and utilimately you come up with an unreasonable proposal to throw the whole thing under the bus
19:04:38 <marun> 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 <regXboi> whoa folks
19:05:01 <SumitNaiksatam> marun: what numbers are talking here?
19:05:10 <regXboi> let's back up
19:05:15 <banix> markmcclain: Mark, could you tell us a bit more about the revised plan you are going to suggest
19:05:18 <rms_13> +1 regXboi
19:05:20 <salv-orlando> 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 <regXboi> I'm interested in hearing what the proposal is?
19:05:51 <regXboi> banix: +1
19:05:55 <SumitNaiksatam> salv-orlando: markmcclain marun: my point is not about the people
19:05:55 <banix> yeah lets get back to the proposal
19:06:03 <SumitNaiksatam> my point is about the process
19:06:07 <marun> 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 <markmcclain> regXboi, banix: it's been something I've working on today
19:06:13 <SumitNaiksatam> regXboi banix: yes sure
19:06:29 <SumitNaiksatam> marun: that is a blatantly incorrect statement
19:06:29 <markmcclain> it also clarifies lots of process items
19:06:37 <marun> SumitNaiksatam: If you don't think that this is true, then you are uninformed.
19:06:43 <ivar-lazzaro> SumitNaiksatam: +1 for the process
19:06:47 <regXboi> markmcclain: please go on
19:06:52 <marun> SumitNaiksatam: It matters if you want to understand why this initiative is not moving forward as quickly as you would like.
19:06:56 <SumitNaiksatam> markmcclain: yes please go on
19:06:56 <regXboi> I'm curious to hear it, even in draft form...
19:07:02 <salv-orlando> 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 <marun> SumitNaiksatam: This group does bear some responsibility for the situation they are in, whether it wants to recognize that or not.
19:07:19 <markmcclain> I'll post it later today after finishing up the details
19:07:24 <SumitNaiksatam> salv-orlando: agree 100%, its not about blaming individual
19:07:45 * regXboi is slightly disappointed, his curiosity was piqued
19:07:52 <SumitNaiksatam> marun: i am still at a loss to understand
19:08:01 <marun> SumitNaiksatam: That's kind of the point.
19:08:05 <SumitNaiksatam> does anyone else here know what marun is referring to?
19:08:07 <marun> SumitNaiksatam: You've been a core for how long?
19:08:08 <rockyg> markmcclain:  Can you give a quick outline, and would it allow GBP in the release?
19:08:20 <markmcclain> 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 <SumitNaiksatam> marun: how is that relevant?
19:08:31 <marun> SumitNaiksatam: With respect, there are trust and relationship issues around this initiative that are causing lots of friction.
19:08:31 <SumitNaiksatam> marun: are we getting personal details now?
19:08:32 <salv-orlando> 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 <marun> SumitNaiksatam: No, it's simply an observation that open source is a messy human business.
19:08:55 <regXboi> markmcclain: oh well, understood
19:09:03 <SumitNaiksatam> salv-orlando: please
19:09:04 <banix> ok i think let’s have this discussion on ML after markmcclain posts his comments
19:09:06 <salv-orlando> who loses if this is delayed for further discussion?
19:09:24 <salv-orlando> I mean is this going to hurt the user commnity?
19:09:29 <SumitNaiksatam> just a note to everyone, that we are past the meeting time, 10 mins over
19:09:46 <salv-orlando> SumitNaiksatam: sorry I did not even realized this was the meeting channel
19:09:56 <regXboi> 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 <marun> I'm not committed to having it in vs out of the tree at this point.
19:09:59 <banix> SumitNaiksatam: as you said let’s talk more unless there is another meeting
19:10:05 <SumitNaiksatam> salv-orlando: no worries, we are waiting until we get kicked out
19:10:21 <ivar-lazzaro> regXboi: +1. A lot of them.
19:10:22 <SumitNaiksatam> salv-orlando: but i just wanted to make the process point that we are over
19:10:26 <regXboi> "are not here" meaning "did not contribute to this process"
19:10:35 <regXboi> gack! s/process/project/
19:10:39 <banix> SumitNaiksatam: yes, thanks.
19:10:40 <salv-orlando> ok so we have active users relying on this feature to be available in trunk in juno for their deployments?
19:10:42 <marun> 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 <ivar-lazzaro> regXboi: not sure if they are taken into account though, together with all the work done to get this in place.
19:11:00 <marun> If we don't have an answer for this, then no, I don't think it should be merged.
19:11:03 <regXboi> salv-orlando: I believe I can say that
19:11:06 <salv-orlando> we have some brave users out there ;)
19:11:23 <regXboi> salv-orlando: I believe I can say that I am planning on using it as an operator, not as a vendor
19:11:38 <regXboi> if it lands in Juno, that is
19:11:45 <regXboi> if it doesn't then I have to go find another solution
19:11:46 <marun> regXboi: echo chamber, much?
19:11:49 <banix> marun: how do you do that if in the tree?
19:12:11 <regXboi> marun: didn't get the reference, sorry
19:12:13 <banix> marun: i mean minimizing the maintenance
19:12:19 <ivar-lazzaro> marun: So you propose to do bug fixing in tree and literally everything else out of tree?
19:12:21 <marun> 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 <marun> 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 <banix> marun: is there any other project that do this?
19:13:15 <salv-orlando> 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 <marun> banix: No.  Projects like nova are better at saying 'no'.
19:13:37 <rms_13> marun: wouldnt that approach open up a kitchen sync for future?
19:13:51 <regXboi> salv-orlando: yeah, I have all sorts of gates to go through if this lands outside the tree
19:13:51 <marun> rms_13: We need to be able to fail-fast as per Mark's email.
19:13:57 <regXboi> not that I can't go through them
19:14:03 <regXboi> it just becomes a whole different ball game
19:14:08 <regXboi> but that's neither here nor there
19:14:10 <marun> 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 <rkukura> 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 <regXboi> rkukura: +1
19:14:47 <marun> 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 <SumitNaiksatam> rkukura: i like the preview terminology
19:14:58 <regXboi> marun: I could live with the idea rkukura just stated
19:15:03 <ivar-lazzaro> rkukura: +1
19:15:06 <mscohen> +1 rkukura.  I think this is good for neutron in general to have.  and works for this project.
19:15:28 <regXboi> markmcclain: you still around?
19:15:36 <marun> I don't think the term is important, just the fact that things are clearly identified so there is no confusion on the part of users or developers.
19:15:47 <rockyg> I think the key will be how to schedule the integration testing so that it stays sync'ed
19:15:53 <rms_13> marun: I understand but than what about services? Do they fall in the same bucket as well?
19:16:05 <marun> rockyg: for out-of-tree?
19:16:17 <marun> rms_13: it could be for anything we want time to stabilize
19:16:33 <marun> rms_13: clearly there would be limitations though, since some changes would be very invasive
19:16:46 <salv-orlando> what the technical difference when it comes to building a release between a subtree and another repository?
19:16:48 <rms_13> marun: I understand that. But do we take action on them is the question. LBaaS, FWaas, VPNaas?
19:17:07 <rms_13> salv-orlando: +1 to question
19:17:10 <rockyg> marun: for branch.  You are trying to limit maintenance, so I owuld think that you would either have triggers for when something in the branch gets merged, or maybe a long job, or nightly/weekly
19:17:11 <marun> I would expect, over time, that the need for modularity between subsystems would become obvious, and make it easier to make changes that would otherwise be invasive
19:17:28 <arosen> fwiw the nova-docker virt driver was pulled out of the nova tree and you can plug it into nova very easily. I don't see why this can't work in a similar way.
19:17:35 <marun> rockyg: you're talking about out-of-tree development?
19:17:46 <marun> arosen: well, we need a stable api
19:18:05 <marun> arosen: does docker introduce api changes?
19:18:26 <salv-orlando> marun: it’s a nova compute driver pretty much
19:18:29 <regXboi> hey all, wonderful discussion, but I gotta run (escalation calls) ... I'll check the minutes later
19:18:33 <rockyg> marun:  no, just if there is a branch, would you want to run main integration for every review?
19:18:34 <regXboi> and the ML
19:18:39 <marun> arosen: I mean, we can already support out-of-tree plugins and drivers.  Is it as easy to add neutron services or extensions?
19:18:40 <arosen> marun:  I don't really see how an api couldn't be loaded in a similar way
19:18:44 <SumitNaiksatam> regXboi: thanks for joining
19:18:53 <arosen> the extension frame work in neutron actually has support for loading things through PATHS
19:18:54 <marun> arosen: uh
19:19:04 <rkukura> Anything that was significantly invasive could be considered for future cycles. For the existing BPs that introduce new APIs that need to get into early adopters hands so they can stability, I hope we can come up with something simple but effective enough.
19:19:28 <arosen> marun: https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L52
19:19:31 <salv-orlando> marun, arosen: I think we’ve been running 2 extensions like that until they merged in master
19:19:31 <rkukura> s/stability/stabilize/
19:19:33 <marun> rkukura: I don't think we can compromise on the need for separation.
19:19:40 <SumitNaiksatam> ok, so are we converging on the “preview” option that marun and rkukura are talking about?
19:19:41 * salv-orlando we as our team
19:19:59 <marun> salv-orlando: so does that imply that group policy could be distributed in its current form out-of-tree?
19:20:22 <salv-orlando> I don’t know all the technical details and how entangled it is with other db models for instance
19:20:23 <rkukura> I think we are talking in-tree, aren’t we?
19:20:27 <arosen> marun:  Sure I see now reason why you can't plug anything into neutron that is out of tree this way.
19:20:27 <salv-orlando> we need a developer to comment on that
19:20:28 <marun> SumitNaiksatam: I think you need feedback from more than just the participants here to move forward in that way.
19:20:38 <SumitNaiksatam> marun: completely agree
19:20:39 <marun> SumitNaiksatam: this meeting != the community that it impacts
19:20:41 <arosen> set core_plugin or service_plugin to the path and it loads
19:20:41 <banix> are we atlking about vendor-specific extensions?
19:20:49 <salv-orlando> marun: I’d say it feasible but I can’t say how long it will take
19:20:50 <rockyg> Marun, So, suppose you run the branch like a 3rd party CI for voting on changes to main, but don't test reviews of the branch against main until the approve stage?  Trying to save on nodepool bw
19:20:50 <SumitNaiksatam> marun: i was just going to say that we can take this option to the mailing list
19:21:02 <marun> SumitNaiksatam: +1
19:21:04 <SumitNaiksatam> marun: assumign that we have some level of consensus here
19:21:09 <marun> rockyg: that's out-of-tree, though.
19:21:14 <SumitNaiksatam> marun: just trying to find out if we at least have consensus here
19:21:23 <marun> SumitNaiksatam: fair enough, my apologies
19:21:30 <SumitNaiksatam> marun: may be not consensus, just in some lose form
19:21:40 <rkukura> As features aproach becoming stable APIs, we absolutely need them to be run as part of normal testing of the tree, so anything that breaks them is detected.
19:21:51 <SumitNaiksatam> marun: no need to apologize, i did not take it negativel
19:21:58 <SumitNaiksatam> *negatively
19:22:00 <marun> rkukura: I think they need the same testing as early as possible
19:22:02 <rockyg> Marun:  no, it's in tree, but like the stable branches
19:22:05 <arosen> rockyg:  i don't think this has anything to do with nodepool
19:22:17 <marun> rkukura: we can add integration testing in-tree, if we want to btw
19:22:50 <marun> rockyg: out-of-tree or feature branches are not a good idea except for things that can be distributed separately (plugins, drivers, etc)
19:22:54 <rockyg> marun: ++
19:23:13 <SumitNaiksatam> marun: we would love to experiment with that approach the integration testing in-tree approach
19:23:36 <SumitNaiksatam> marun: for now we are focussing on the tempest tests since that seems to be the fastest path to validation
19:23:43 <SumitNaiksatam> marun: and also per your earlier suggestion on this
19:23:59 <rockyg> smitnaiksatam: ++
19:24:15 <SumitNaiksatam> i know we are discussing a larger process issue here
19:24:26 <rockyg> sumitnaiksatam:  sorry for the misspell
19:24:32 <marun> SumitNaiksatam: There is some question as to whether the tests should be in Tempest if they aren't considered stable, but the same tests can exist and be run from either our repo or theirs.
19:24:48 <SumitNaiksatam> marun: ah ok
19:24:56 <SumitNaiksatam> marun: for now these are WIP patches in tempest
19:25:12 <SumitNaiksatam> marun: not meant to be merged soon for obvious reasons
19:25:35 <SumitNaiksatam> marun: but we can move it to wherever its more appropraite per the plan for the “preview” apis
19:25:37 <marun> SumitNaiksatam: So long as they exist we can make them usable in whatever way ends up being necessary.
19:25:44 <marun> SumitNaiksatam: agreed
19:25:45 <SumitNaiksatam> marun: +1
19:25:57 <SumitNaiksatam> so let me ask again, rkukura marun do you feel comfortable bringing up this topic in the mailing list?
19:26:27 <markmcclain> sorry was pulled away… my plan is very close to the preview idea
19:26:34 <markmcclain> but with a lot more clarity around processes
19:26:36 <rms_13> how does other openstack project suppose to work with "preview" APIs? Just in normal fashion? (nova, glance, keystone OR horizon)
19:26:45 <SumitNaiksatam> markmcclain: thanks for joining again
19:26:55 <banix> if i understand it, all this will be part of what markmcclain  will propose later today
19:27:07 <SumitNaiksatam> markmcclain: sure, preview of your proposal? ;-)
19:28:13 <marun> SumitNaiksatam: If Mark's proposal encompasses similar concepts, I would like to see that before I comment.  I'm not entirely clear of all the details of how unstable APIs have hurt us and I think his insight is critical.
19:28:24 <SumitNaiksatam> marun: ok
19:28:32 <ivar-lazzaro> SumitNaiksatam: +1, very curious to have a preview :)
19:28:42 <rkukura> +1
19:28:45 <SumitNaiksatam> preview of the preview
19:29:30 <markmcclain> SumitNaiksatam: haha
19:29:45 <banix> sounds like we will continue this discussion on the ML
19:30:43 <rkukura> I’m happy to review a proposal from markmcclain on the ML today. If that doesn’t happen, I’d be happy to writeup some of my ideas on managing preview APIs and posting it for discussion.
19:30:52 <rockyg> Wow!  Progress, and interim closure?
19:31:03 <SumitNaiksatam> rkukura: thanks!
19:31:07 <SumitNaiksatam> rockyg: :-)
19:31:22 <SumitNaiksatam> markmcclain: so no preview of the preview? :-P
19:32:35 <banix> rkukura: i think if you have any ideas, putting them out for discussion would be helpful
19:32:54 <markmcclain> SumitNaiksatam: not yet
19:33:23 <SumitNaiksatam> markmcclain: is it because the idea is not baked, or you dont feel this is the right forum to discuss it?
19:33:41 <SumitNaiksatam> markmcclain: sorry for pressing, i am just curious
19:33:56 <markmcclain> SumitNaiksatam: not fully committed to text
19:34:03 <SumitNaiksatam> markmcclain: okay
19:34:23 * markmcclain had lots of time to think while in the jury waiting room
19:34:29 <SumitNaiksatam> #action markmcclain to send a proposal on GBP progress by eod Aug 7th 2014
19:34:36 <SumitNaiksatam> markmcclain: lol
19:34:41 <rockyg> markmcclain:   looking forward to seeing the proposal
19:34:42 <SumitNaiksatam> markmcclain: hope that AI is fine
19:35:05 <banix> marun, markmcclain, arosen, salv-orlando and all others  thanks for joing this call today
19:35:14 <SumitNaiksatam> banix: indeed
19:35:27 <SumitNaiksatam> markmcclain: marun arosen salv-orlando: thanks for gracing this meeting
19:35:35 <SumitNaiksatam> you are welcome to stick around though :-)
19:35:40 <SumitNaiksatam> didnt think you were leaving
19:35:44 <SumitNaiksatam> should we go through the rest of the agenda for today?
19:35:53 <SumitNaiksatam> people have time to stick around for another 10 mins?
19:35:56 <SumitNaiksatam> may be less
19:35:58 <arosen> go for it. It looks like you have the room..
19:35:58 <banix> SumitNaiksatam: yes please
19:36:07 <SumitNaiksatam> arosen: yeah :-)
19:36:17 <rkukura> ok with me
19:36:29 <SumitNaiksatam> #topic CLI/Client update
19:36:44 <SumitNaiksatam> we discussed the “profiled” API suggestion last week
19:36:48 <banix> s3wong: had started his comments. no?
19:36:59 <SumitNaiksatam> banix: i thought s3wong said he was done
19:37:04 <SumitNaiksatam> s3wong: ?
19:37:10 <banix> ok
19:37:27 <SumitNaiksatam> i think s3wong is close to posting the patch
19:37:39 <SumitNaiksatam> unfortunately regxboi has left the meeting
19:37:43 <songole> profiled API patch?
19:37:50 <SumitNaiksatam> banix: or anyone else to update on that?
19:38:12 <SumitNaiksatam> songole: yeah, just checking if there are any developments or blockages to that idea
19:38:13 <banix> nothing from me
19:38:26 <SumitNaiksatam> banix: ok
19:38:34 <SumitNaiksatam> so over to you songole
19:38:43 <SumitNaiksatam> any updates on the CLI/Client patches?
19:38:53 <songole> I updated the wiki page with links to the patches
19:39:05 <songole> I see that regXboi removed -1
19:39:07 <rms_13> I have tested them
19:39:22 <rms_13> Atleast they look ok API wise.
19:39:24 <songole> rms_13: any issues?
19:39:35 <songole> ok
19:39:40 <rms_13> I still need to test l2pol, l3pol and endpoint
19:39:41 <SumitNaiksatam> songole: nice
19:39:44 <rms_13> oops sorry
19:39:48 <SumitNaiksatam> rms_13: thanks, thats great progress!
19:39:50 <rms_13> policy-point :)
19:40:00 <SumitNaiksatam> rms_13: wait, not so soon! :-)
19:40:08 <rms_13> name of the day :)
19:40:28 <rms_13> alright....I need to head out
19:40:40 <SumitNaiksatam> rms_13: we need your horizon update
19:40:42 <rms_13> See you all in next meeting. Will send an email to the ML soon with name proposal
19:40:42 <songole> How would you want to deal with mapping extension?
19:40:59 <songole> Does it need to be part of CLI?
19:41:02 <rms_13> Horizon update is I will open up my WIP update for people to look at and comment
19:41:11 <SumitNaiksatam> rms_13: ok thanks!
19:41:13 <rms_13> If the skeleton looks good
19:41:20 <rms_13> we can add more resources
19:41:23 <SumitNaiksatam> rkukura: you have thoughts on songole’s question?
19:42:03 <rkukura> what needs to be dealt with?
19:42:13 <banix> songole: you mean the extra attributes?
19:42:21 <songole> banix: right
19:42:27 <rkukura> Is the question whether these should appear in horizon?
19:42:46 <songole> rkukura: CLI in particular
19:43:25 <songole> extensions/group_policy_mapping.py
19:43:56 <rkukura> Certainly in the CLI I would think
19:44:15 <rkukura> How else would a user get the port_id from a PP to pass to nova boot?
19:44:38 <rkukura> In horizon, it might be nice to have an option to turn the mapping attributes on/off
19:44:39 <songole> However, this is an optional extension, right?
19:44:46 <SumitNaiksatam> rkukura: i think songole’s question is whether to add these as optional attributes to the GBP CLI itself
19:45:00 <SumitNaiksatam> rkukura: yeah, songole’s point about the optional extension
19:45:34 <rkukura> We currently don’t provide any way to use the group-policy extension without the group-policy-mapping extension also being present, right?
19:45:50 <SumitNaiksatam> rkukura: yes
19:45:53 <banix> rkukura: right
19:46:01 <SumitNaiksatam> i believe the question is in cases where the mapping is slightly different (based on the mapping driver) how will this CLI handle that?
19:46:19 <songole> right
19:48:05 <rkukura> The CLi should be prepared to handle the attributes as defined in the group-policy-mapping API (allow_put, allow_post, …)
19:48:36 <rkukura> If the configured driver rejects an attempt to do something the API allows, the CLI users gets an exception.
19:49:06 <SumitNaiksatam> rkukura: ok
19:49:15 <songole> ok. Then, I will update the CLI to take those attributes as well.
19:49:26 <SumitNaiksatam> songole: i am wondering whether there is a pattern in the current CLI code to discover extensions
19:49:34 <SumitNaiksatam> songole: this is done in the Horizon code
19:49:49 <songole> SumitNaiksatam: I don't think so. Will check
19:49:54 <rkukura> would be nice if extensions were negotiated
19:50:12 <rkukura> the user can use the CLI to query what extensions are supported
19:50:24 <SumitNaiksatam> songole: if there is then one could drive this based on discovering that
19:50:26 <SumitNaiksatam> rkukura: yeah
19:50:37 <SumitNaiksatam> songole: perhaps you can keep it simple to begin with
19:50:55 <SumitNaiksatam> since like rkukura mentioned, we currently only have the reference mapping driver
19:50:59 <SumitNaiksatam> okay with everyone?
19:51:07 <banix> yes
19:51:14 <songole> ok
19:51:24 <SumitNaiksatam> ok great
19:51:29 <SumitNaiksatam> #topic Horizon update
19:51:59 <SumitNaiksatam> i think rms_13 already indicated that he is getting the branch out of WIP pretty soon
19:52:18 <SumitNaiksatam> i believe the branch is #link https://review.openstack.org/93590
19:52:50 <SumitNaiksatam> #topic Vendor Drivers
19:53:10 <SumitNaiksatam> has anyone started working on this; any questions for the team or any blockers?
19:53:27 <banix> have started working on the driver for sdn-ve
19:53:40 <SumitNaiksatam> banix: cool, thanks for leading the way
19:53:50 <SumitNaiksatam> banix: perhaps we can learn from your experience
19:54:09 <banix> sure
19:54:16 <ivar-lazzaro> I'm at early stage with the cisco driver, nothing blocking so far
19:54:45 <SumitNaiksatam> ivar-lazzaro: nice
19:54:56 <SumitNaiksatam> #topic API intercept
19:54:59 <SumitNaiksatam> kevinbenton: there?
19:55:05 <songole> we are making progress on our driver. no issues
19:55:15 <kevinbenton> SumitNaiksatam: yeah, but might lose connection
19:55:19 <kevinbenton> SumitNaiksatam: on the road
19:55:37 <banix> kevinbenton: hopefully not driving :)
19:55:39 <kevinbenton> SumitNaiksatam: still waiting on rkukura for feedback before opening it up
19:55:41 <SumitNaiksatam> kevinbenton: oh okay, perhaps we can get an update in the next meeting then
19:55:47 <kevinbenton> banix: not while typing at lease :-)
19:55:49 <SumitNaiksatam> kevinbenton: okay sure
19:55:57 <kevinbenton> least*
19:56:05 <SumitNaiksatam> kevinbenton: thanks for joining!
19:56:08 <kevinbenton> banix: do you want to take a look at it?
19:56:13 <rkukura> feedback?
19:56:24 <banix> sure will do
19:56:24 <rkukura> I might have missed something
19:56:31 <kevinbenton> rkukura, banix: https://review.openstack.org/#/c/109901/
19:56:31 <SumitNaiksatam> rkukura: i believe kevinbenton had send an email about a week back
19:56:40 <SumitNaiksatam> *sent
19:56:41 <rkukura> OK, on the intercept!
19:56:46 <SumitNaiksatam> rkukura: yeah
19:56:52 <rkukura> sorry
19:57:22 <rkukura> I will review that in detail today or tomorrow.
19:57:28 <SumitNaiksatam> rkukura: thanks
19:57:34 <kevinbenton> rkukura: thx
19:57:39 <SumitNaiksatam> #topic Tempest tests
19:58:02 <banix> unfortuntely, i have to run; see you all later
19:58:19 <SumitNaiksatam> i dont have much update on this, its still at the same patch set: #link https://review.openstack.org/#/c/108234/
19:58:33 <SumitNaiksatam> #topic open discussion
19:58:36 <SumitNaiksatam> banix: thanks
19:58:44 <susaant> I have posted patches for GBP heat resources https://review.openstack.org/#/c/111417/ & https://review.openstack.org/#/c/111419/
19:58:45 <SumitNaiksatam> if no one has anything else to bring up, we can wrap up
19:58:55 <SumitNaiksatam> susaant: thats great
19:59:01 <SumitNaiksatam> susaant: sorry missed the heat update
19:59:03 <susaant> we will posting patches for remaining resources soon
19:59:10 <SumitNaiksatam> susaant: thanks much!
19:59:20 <SumitNaiksatam> we are exactly one hour over! :-)
19:59:29 <SumitNaiksatam> we can just pretend that we start an hour late!
19:59:44 <kevinbenton> SumitNaiksatam: yeah, i figured i missed the meeting :-)
19:59:48 <SumitNaiksatam> thanks all for joining, and I apologize for venting a little bit earlier
20:00:22 <SumitNaiksatam> kevinbenton: :-)
20:00:22 <SumitNaiksatam> alright thanks everyone!
20:00:24 <SumitNaiksatam> bye
20:00:26 <songole> bye
20:00:28 <SumitNaiksatam> #endmeeting