18:02:10 <stevemar> #startmeeting keystone
18:02:11 <openstack> Meeting started Tue Sep 29 18:02:10 2015 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:14 <gyee> traffice is bad today
18:02:14 <openstack> The meeting name has been set to 'keystone'
18:02:21 <stevemar> gyee: for sure
18:02:27 <stevemar> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:02:32 <stevemar> agenda has been updated
18:02:36 <stevemar> i tossed a few items up
18:02:56 <stevemar> morgan: around?
18:03:00 <marekd> stevemar: me too (3 mins ago)
18:03:16 <stevemar> yup, i see that
18:03:22 <gyee> hail to stevemar!
18:03:25 * dstanek is here. better late than never
18:03:26 <gyee> first agenda
18:03:34 <stevemar> #topic ptl change
18:03:41 <stevemar> well this is awkward :P
18:03:44 <bknudson> there's a new sheriff in town
18:03:49 <dstanek> stevemar: congrats!
18:03:52 <marekd> ++
18:03:55 <stevemar> morgan did an awesome job, let's all thank him first
18:03:57 <amakarov> +1
18:04:03 <morgan> O/ and btw it said not me
18:04:07 <bknudson> thanks to everyone who ran. it was a tough choice
18:04:13 <stevemar> bknudson: ++
18:04:20 <gyee> stevemar, you prefer cash or check?
18:04:28 <dstanek> gyee: reviews
18:04:30 <stevemar> gyee: jewels
18:04:34 <stevemar> reviews too
18:04:42 <gyee> yes
18:04:46 <lbragstad> beer?
18:05:06 <stevemar> hope i don't disappoint :) but i feel like i have the world's largest safety net with such an awesome team
18:05:30 * morgan welcomes the new stevemar keystone overlord :P
18:05:40 <marekd> stevemar: you won't, just keep rockin' :-)
18:05:43 <dstanek> you'll do great, just like our previous leaders
18:05:43 <shaleh> stevemar: we can always stage a coup if we have to :-)
18:05:52 <tsymanczyk> \o
18:06:02 <stevemar> shaleh: i like your style
18:06:24 * morgan pours a drink and sits back.
18:06:27 <stevemar> not much else to say here, let's go on to a few lighter topics before we get into the weeds
18:06:28 <bknudson> start our own keystone project
18:06:37 <stevemar> #topic meeting time
18:06:57 <amakarov> shaleh, for the complete democracy we need an opposition! ))
18:07:14 <stevemar> we've had this time for a while, and it works, but i feel like we need to bring it up every release, just in case
18:07:28 <stevemar> jamielennox: amakarov marekd, looking at you guys
18:07:29 <gyee> no issue with meeting time here
18:07:32 <bknudson> if this time didn't work for someone they're probably not here.
18:07:38 <stevemar> hehe
18:07:43 <jamielennox> it really can't go any earlier for me
18:07:52 <jamielennox> as is i'm about 50/50
18:07:55 <amakarov> I'm fine with current meeting time
18:08:03 <jamielennox> but i'm ok with the current
18:08:07 <lbragstad> i'm good with the current time
18:08:07 <morgan> stevemar: we need to make the meeting at least 7hours later /s
18:08:23 <stevemar> morgan: just to really get jamielennox
18:08:30 <marekd> morgan: deep night for me :(
18:08:39 <amakarov> it will be 4am for me and breton
18:08:41 <morgan> Note the "/s" ;)
18:08:52 <stevemar> marekd: you're good with current?
18:08:59 <marekd> stevemar: yeah
18:09:04 <stevemar> alright
18:09:19 <stevemar> as usual, no need to alternate meetings or have a second time, thats nice to hear
18:09:24 <marekd> stevemar: i said a meeting 7hrs later would be a deep night for me
18:09:25 <raildo> this time is great for us here in Brazil :)
18:09:27 <stevemar> and saves me from creating a ML post
18:09:44 <stevemar> neeeext topic
18:09:54 <marekd> given geodistribution of team members i think that's the only reasonable team
18:10:08 <stevemar> #topic liberty-rc2 do we need one?
18:10:18 <morgan> Yes
18:10:21 <bknudson> I assume one is needed for translations
18:10:23 <morgan> For translations
18:10:31 <stevemar> alright, for translations
18:10:44 <bknudson> how do we know when translation work is complete?
18:11:00 <morgan> stevemar: you just talked to dhellmann an hour ago about this...
18:11:04 <morgan> :P
18:11:22 <stevemar> morgan: well yes, i wanted to use this time to see if there's anything else
18:11:45 <stevemar> i think this one is handy: https://review.openstack.org/#/c/215870/
18:12:41 <stevemar> if an admin creates endpoints using v3, then v2's endpoint-list doesn't bring them up, that's my understanding anyway
18:12:53 <marekd> stevemar: when would be liberty-rc2 cut?
18:13:05 <morgan> marekd: next week iirc
18:13:13 <stevemar> marekd: soon, we still have a bit of time, maybe a week
18:13:15 <marekd> morgan: ok.
18:13:27 <bknudson> we can backport https://review.openstack.org/#/c/215870/ if it doesn't make the rc
18:14:04 <dstanek> i was pretty close last time i looked
18:14:28 <marekd> i would also take a look at this https://review.openstack.org/#/c/206561/
18:14:28 <dstanek> i just wanted to verify the json coming back still looks correct and then i'd be happy with it
18:14:29 <stevemar> dstanek: agreed, i pulled it down and tried it out, i'd be happy to vouch for it
18:14:43 <dstanek> i can do that today and throw up a new vote
18:14:55 <stevemar> dstanek: cool
18:14:56 <marekd> nevertheless we will need to backport it to kilo.
18:14:59 <gyee> so we need to map 1 endpoint ID to multiple?
18:15:12 <gyee> sorry I mean multiple to 1
18:15:17 <jamielennox> i'd agree with having the feature, code seems strange to me - but i don't think the brain has really kicked in yet
18:15:18 <stevemar> marekd: hold up a sec, we can get into the other one in a minute
18:15:37 <dstanek> gyee: yes
18:15:48 <morgan> jamielennox: drink moar coffee
18:16:04 <gyee> would that be problematic as we need to maintain multiple IDs?
18:16:12 * lbragstad hands jamielennox more coffee
18:16:16 <marekd> stevemar: yes sir!
18:16:17 <dstanek> jamielennox: it's mostly strange because of how we changed v2 and v3 endpoints
18:16:31 <dstanek> gyee: we don't in v2
18:16:41 <stevemar> morgan: so umm, how's this work, hypothetically if 215870 is merged, and we want it in rc2, we need to merge it to master - then cherry-pick it to liberty? and cut rc2 from stable/liberty?
18:16:49 <jamielennox> yea, just looking as to why we build a v3_endpoints dict and iter that again, but ok
18:16:51 <morgan> Yep
18:16:59 <stevemar> morgan: i am learnding
18:17:09 <morgan> Back port to stable/Liberty which is where rc2 will be tagged from
18:17:15 <stevemar> \o/
18:17:29 <bknudson> we used to have a -proposed branch
18:17:40 <stevemar> i like this way more, it's easier
18:17:40 <edmondsw> I think https://review.openstack.org/#/c/217373/ should be backported to liberty and kilo
18:18:17 <stevemar> edmondsw: that's would be re-releasing a minor version of keystonemiddleware
18:18:23 <edmondsw> yes
18:18:38 <stevemar> oh it's approved, doh
18:19:00 <gyee> dstanek, ahh, its using the public endpoint ID as the legacy endpoint ID?
18:19:16 <lbragstad> but what about the backport? that will require a new release of something, right?
18:19:21 <bknudson> I don't think we can do a minor version change in stable/liberty, it'll be the patch #.
18:19:37 <stevemar> morgan: for edmondsw's question, does the same logic still hold for keystonemiddleware? or do we just tag a new release from master?
18:19:45 <bknudson> http://semver.org/
18:19:49 <morgan> We can only do patch level .Z changes
18:19:58 <morgan> For stable branches
18:20:03 <dstanek> do we do release of kilo for kmw? or is it just a normal new release from master?
18:20:22 <stevemar> dstanek: they have stable branches
18:20:24 <morgan> Middleware has stable branches
18:20:47 <morgan> If this is a real bug fix, it is a .z patch level
18:20:59 <morgan> If it is a .y patch level it isn't a bug fix
18:21:03 <bknudson> the change should be released in master before it's released in stable releases.
18:21:05 <stevemar> the only hitch is updating the requirements in the stable branch too right?
18:21:10 <morgan> It is a feature/behavior change
18:21:11 <edmondsw> it's a real bug fix
18:21:40 <morgan> stevemar: adding new requirements to stable is a no-go in most cases
18:21:45 <ayoung> edmondsw, yeah...that is a bug fix
18:21:58 <morgan> So work around requirements changes.
18:22:27 <morgan> If you do a .z release requirements won't change
18:22:31 <morgan> In stable
18:22:38 <stevemar> #todo stevemar to bug dhellmann about ksm refresh and pulling in edmondsw's change
18:22:42 <morgan> Upper bounds will (perhaps)
18:22:51 <stevemar> i'll dig into this
18:23:00 <morgan> It will be a back port for that change. Simple
18:23:06 <stevemar> morgan: is there an rc2 in lp?
18:23:26 <morgan> stevemar: for keystone or middleware? Middleware doesn't do rc
18:23:32 <morgan> My
18:23:35 <stevemar> keystone proper
18:23:53 <morgan> For keystone that is pending rel management to add the milestone
18:24:08 <morgan> Talk to dhellmann and/or ttx
18:24:09 <stevemar> morgan: so then hows it work for targeting bugs?
18:24:24 <ayoung> how's rc2 work?  We release right away, or on some schedule?
18:24:28 <bknudson> is there an rc2-potential for bugs?
18:24:34 <stevemar> ayoung: right away
18:24:36 <morgan> Mark the bug as rc-potential and get the milestone added
18:24:40 <morgan> Target the bug
18:24:41 <stevemar> bknudson: that would be a good idea
18:24:45 <morgan> Merge the fix
18:24:46 <stevemar> cool
18:24:51 <stevemar> alrighty
18:24:53 <morgan> Tag rc2 when needed
18:24:57 <stevemar> i think i already tagged it
18:25:16 <morgan> :)
18:25:25 <stevemar> okay, marekd your go, you wanted to talk about another potential rc2 bug?
18:26:02 <marekd> stevemar: yeah
18:26:29 <marekd> https://review.openstack.org/#/c/206561/ this may actually blow up db_sync keystone
18:26:32 <marekd> including kilo
18:26:50 <marekd> i can work on it tomorrow and address the comments.
18:27:20 <marekd> actually bug desc is better to read: https://bugs.launchpad.net/keystone/+bug/1478961
18:27:20 <openstack> Launchpad bug 1478961 in Keystone "db sync on federation failed if there is existing data" [High,In progress] - Assigned to Marek Denis (marek-denis)
18:27:22 <dstanek> marekd: merging that change would blow up db_sync? or things will blow up without it?
18:27:27 <lbragstad> so that won't require a backport migration will it?
18:27:45 <stevemar> i think it's just a liberty fix lbragstad
18:27:53 <morgan> lbragstad: if a migration is back ported it has to be idempotent.
18:27:54 <lbragstad> stevemar: cool, so no backport
18:28:00 <marekd> dstanek: without that change things *might* blow up db_sync in some cases
18:28:15 <marekd> stevemar: lbragstad this actually should be backported to kilo too.
18:28:21 <morgan> This is another case where we need to collapse the separate migrate repos into the main one
18:28:23 <dstanek> marekd: is it possible to get a test to generate data to get into that situation?
18:28:39 <morgan> marekd: that is likely un backportable to kill
18:28:42 <morgan> Kilo
18:28:57 <marekd> morgan: why?
18:29:10 <morgan> If 006 doesn't exist in kilo you can't back port it
18:29:34 <morgan> You can't have gaps and you can't reuse numbers
18:29:54 <morgan> If it
18:30:00 <bknudson> for M we need to consider if we want the placeholder migrations
18:30:00 <marekd> morgan: uh, let me check
18:30:02 <dstanek> no placeholders for the federation migrations?
18:30:22 <morgan> dstanek: no placeholders for any non-main repo
18:30:34 <stevemar> dstanek: no placeholders for any extensions unfortunately
18:30:37 <dstanek> morgan: didn't know that and i've never bothered to look
18:30:39 <morgan> We need to collapse all of these into the main repo
18:30:57 <morgan> As part of mitaka to fix this silly
18:31:02 <morgan> State
18:31:20 <marekd> morgan: https://github.com/openstack/keystone/tree/stable/kilo/keystone/contrib/federation/migrate_repo/versions correct me if i am wrong but we do have 006 in kilo ?
18:31:24 <morgan> The split repos was (in hindsight) a bad idea
18:32:04 <morgan> Ok... Hm.. Maybe you can backport it
18:32:12 <ayoung> halfway through
18:32:17 <morgan> Be wary. Back porting migrations is scary
18:32:17 <ayoung> and I really want to talk roles...
18:32:26 <bknudson> 006 is already doing something else.
18:32:46 <marekd> morgan: the only reason would be gaps in migrations numbering  or something more 'political' ?
18:32:49 <morgan> Anyway.. Just be warned there be dragons here
18:32:50 <ayoung> morgan, the split repos was not a bad idea.  Merging all of the migrations into one repo is the bad idea, but lets let it go....
18:32:56 <marekd> morgan: ok
18:33:03 <marekd> i will work on the fix and get back to you.
18:33:09 <stevemar> ayoung: yeah, we're still good for time, its just this and a heads up about release notes, then we're on to roles
18:33:14 <dstanek> marekd: and a test?
18:33:17 <morgan> ayoung: the split repos was a terrible idea. It sounded good at the time
18:33:18 <marekd> dstanek: and a test.
18:33:21 <bknudson> this is changing an existing migration to clean it up. should be fine.
18:33:30 <dstanek> marekd: thx!
18:33:32 <morgan> bknudson: ++
18:33:43 <marekd> morgan: stevemar dstanek : i think jose revealed this bug while doing test upgrade to kilo on his dev env....
18:33:48 <bknudson> the migration would have failed before so don't have to worry about it breaking anything.
18:33:52 * morgan was for split repos at the time. Anyway
18:33:57 <stevemar> bknudson: lol
18:33:57 <ayoung> If we are pulling info from an extension in, have the migration check for the table before making any changes
18:34:22 <dstanek> bknudson: for the test i'm more worried about ensuring we are fixing something
18:34:31 <ayoung> it won't be reverseable, but we've droppped that requirement anyway
18:34:34 <stevemar> marekd: let's proceed with fixing it
18:34:34 <morgan> Anyway I'll take a bug to collapse the extra repos this cycle.
18:35:03 <marekd> stevemar: OK, i will address the commments.
18:35:04 <morgan> Let's backport that and get a test added
18:35:04 <stevemar> we can potentially backport it, i can't imagine too many ppl have stuff in their federation tables, you guys were the early adopters
18:35:19 <ayoung> morgan, we going to do all of the extensions at once?
18:35:26 <morgan> Just be super careful backporting
18:35:37 <stevemar> and as bknudson said, it can't get worse
18:35:43 <morgan> ayoung: I'll collapse each as an idempotent migration
18:35:48 <ayoung> morgan, ++
18:35:51 <stevemar> yup
18:35:55 <lbragstad> ++
18:36:00 <marekd> stevemar: i think lots of people are on very old releases, so they might get to the point we (cern) are today - let's then save them from the troubles.
18:36:16 <marekd> esp the fix is in the end not super hard.
18:36:18 <marekd> :-)
18:36:25 <stevemar> #todo stevemar to look into getting those 2 bugs backported and a possible ksm refresh
18:36:35 <ayoung> stevemar, #action for those
18:36:42 <stevemar> marekd: yup
18:36:45 <marekd> stevemar: thanks!
18:36:49 <stevemar> next!
18:36:56 <stevemar> #topic release notes
18:37:18 <ayoung> we do that on etherpad first?
18:37:28 <bknudson> #link https://etherpad.openstack.org/p/keystone-liberty-release-notes
18:37:32 <lbragstad> i think we already have on started
18:37:33 <lbragstad> ^^
18:37:43 <bknudson> the proposed release notes are at the bottom
18:38:10 <stevemar> #link https://etherpad.openstack.org/p/keystone-liberty-release-notes
18:38:11 <stevemar> we have an etherpad
18:38:11 <stevemar> the link to the wiki is there
18:38:11 <stevemar> and now here!
18:38:11 <stevemar> #link https://wiki.openstack.org/wiki/ReleaseNotes/Liberty#OpenStack_Identity_.28Keystone.29
18:38:11 <stevemar> please review and add as you see fit, i trust you all
18:38:23 <ayoung> We are claiming Fernet token as a hardened feature.  We willing to take it out of experimental?
18:38:46 <ayoung> line 62
18:38:50 <stevemar> ayoung: yes, but it looks like it was in a good enough state to motivate someone to move it over (dolphm?)
18:38:54 <lbragstad> it's hardened but I don't think it's moved out of experimental
18:38:59 <stevemar> maybe lbragstad knows
18:39:08 <bknudson> we never advertised fernet as experimental as far as I know
18:39:09 <lbragstad> bknudson: had a patch up to document that it's experimental
18:39:31 <ayoung> lets be explicit one way ot the other with it, please
18:39:42 <bknudson> #link https://review.openstack.org/#/c/224888/
18:39:44 <gyee> so we have 3 levels now, experimental, harden, and stable?
18:40:05 <lbragstad> gyee: no, i think the point was to just say that it was hardened
18:40:25 <stevemar> gyee: no, hardened isn't a thing, just yeah - what lbragstad says ^
18:40:25 <marekd> ^^ which of the state is equivalent to "may be used in prod" ?
18:40:29 <stevemar> stable and experimental
18:40:38 <stevemar> marekd: stable
18:40:52 <stevemar> experimental means we are subject to change things
18:41:00 <lbragstad> yes
18:41:13 <stevemar> break API contracts / endpoints / blah
18:41:18 <ayoung> OK...review the rest...roels?
18:41:22 <gyee> but would that be confusing to the operators?
18:41:34 <gyee> its harden, but still experimental
18:41:34 <bknudson> I don't think we're planning to break the fernet API contract
18:41:37 <marekd> stevemar: AFAIR fernet format doesn't have any 'contract'
18:41:38 <ayoung> 20 minutes left...  and no henrynash
18:42:00 <bknudson> fernet isn't working with tempest currently
18:42:06 <lbragstad> bknudson: yes,
18:42:08 <stevemar> gyee: i'll clean up the wording :)
18:42:25 <marekd> bknudson has some patches for fernet & federation i also have some patches and not actually sure what to do with them...
18:42:30 <gyee> stevemar, k, thanks, I was having my operator hat on
18:42:33 <ayoung> I haven't looked, but I'll bet it still needs an external token format identifier, too.
18:42:35 <lbragstad> bknudson: once we have it passing all the tempest tests (which we're close) I feel comfortable marking it as stable
18:42:53 <bknudson> y, we should change one of the gates to use it.
18:42:54 <stevemar> marekd: patches for what?
18:42:56 <lbragstad> but, that will require some work around the subsecond problem that dolphm and i have been working on
18:43:03 <lbragstad> which will require an API change
18:43:04 <bknudson> also, we need to change the gate that uses eventlet to stop doing that
18:43:08 <morgan> If fernet can't pass tempest we can't mark it stable
18:43:09 <marekd> stevemar: fernet + federation
18:43:11 <morgan> FYI.
18:43:23 <bknudson> all the token formats should use the same resolution for timestamps
18:43:34 <lbragstad> bknudson: ++
18:43:37 <morgan> Oooh ooooooh stevemar I'm gonna kill eventlet today for mitaka!!
18:43:39 <bknudson> deployers already think fernet is stable.
18:43:40 <marekd> https://review.openstack.org/#/c/213742/
18:43:41 <stevemar> marekd: link me later
18:43:47 <amakarov> morgan, ++
18:43:50 <lbragstad> yes, and correcting that will be an api change
18:44:02 <stevemar> morgan: i just got feedback from someone saying to *not* kill it
18:44:10 <stevemar> but, later
18:44:11 <morgan> stevemar: why?
18:44:22 <morgan> stevemar: in -keystone post meeting
18:44:29 <stevemar> morgan: meh, later, let's give ayoung time to chat about d20s
18:44:33 <stevemar> #topic roles
18:44:35 <ayoung> Rolllllllllles
18:44:36 <stevemar> ayoung: ^
18:44:42 <ayoung> OK...so wish henry was here
18:44:59 <stevemar> oh right, henry can't make it today, my bad, was supposed to say that earlier :)
18:45:07 <ayoung> As you might have learned, right now is the most valuable time for ghetting newe features definied;  we have rc out, and people can start thinking about the next release
18:45:16 * morgan roles 2d8: 4 and 7
18:45:18 <ayoung> we've got a few things that might finally make some progress
18:45:30 <ayoung> first.. bug 968696  issue
18:45:30 <openstack> bug 968696 in OpenStack Compute (nova) ""admin"-ness not properly scoped" [High,Confirmed] https://launchpad.net/bugs/968696
18:45:38 <gyee> morgan, rolls?
18:46:08 <ayoung> there was an issue if a user deleted a project but the resources were not deleted, there was no way to clean them up
18:46:19 <ayoung> dolphm, suggested that it should be a service specific task;
18:46:27 <ayoung> nova should clean vms, neutron networks and so on
18:46:29 <ayoung> so...
18:46:39 <ayoung> first spec for that is
18:46:40 <stevemar> ayoung: create an event and nova listens for it?
18:46:52 <gyee> mistrial?
18:46:53 <ayoung> stevemar, not if it missed it in the past
18:46:57 <bknudson> we already have an event, that's why we closed the bug.
18:47:00 <ayoung> https://review.openstack.org/#/c/228477/
18:47:11 <gyee> taskflow?
18:47:17 <marekd> RAFT :P
18:47:17 <ayoung> or not
18:47:43 <ayoung> it means we need to catch every exceptional case up front, with not way to fix things if they are broken
18:47:50 <ayoung> operators need more support than that
18:48:01 <raildo> bknudson, ++ the only problem is that the services doesn't consume this event
18:48:29 <ayoung> keystone sends the notifcation to cielometer only today...the distribution of events is not something that is well handled
18:48:43 <marekd> ayoung: ++ :(
18:48:46 <ayoung> and if there is additional workflow?
18:48:58 <marekd> and i think it's not default for ceilometer to consume and store those events
18:49:04 <ayoung> so...lets state explicitly what this is:  scope admin to an endpoint
18:49:58 <ayoung> instead of trying to shoehord this into the HMT approach, we make a new value for "scope" in a token...."endpoint"....we could do all of the catalog items, but I think that makes policy too hard to write correctly
18:49:58 <gyee> customer can create their own queue right?  I am talking Rabbit
18:50:22 <ayoung> gyee, its trickier than that...it should be a different listener on the same topic
18:50:44 <ayoung> and if a service goes down, we don't have guaranteed delivery etc
18:50:48 <ayoung> lets not count on events yet
18:51:03 <stevemar> ayoung: if i have a role on an endpoint, what can i do? any action on that endpoint?
18:51:20 <ayoung> stevemar, still depends on the role, just that the assignment is scoped to the endpoint
18:51:53 <ayoung> it would mean that to perform an admin operation, instead of admin on any project (what we have today) or some admin project (suggested)  they would have it on the endpoint...
18:52:06 <gyee> with endpoint filtering, assignment is restrict to endpoint
18:52:18 <bknudson> how do you assign a role for a user on an endpoint?
18:52:21 <ayoung> and we do an HMT style assignment for the normal case:  assign the user the role on the whole catalog,  requies a token  scoped to the endpoint
18:52:44 <gyee> bknudson, you assign a role to a user for a project and given set of endpoints
18:52:48 <ayoung> bknudson, it becomes a new value for assignmnet_type in the assignemnt table
18:53:00 <ayoung> gyee, not filtering...
18:53:14 <ayoung> this is scope of the assignment itself, not endpoints filtered by project
18:53:20 <bknudson> ok, a new assignment type
18:53:22 <ayoung> there would be no project in the token
18:53:23 <stevemar> the dots still aren't connecting for me
18:53:24 <gyee> assigning role to a endpoint makes no sense
18:53:25 <ayoung> bknudson, yes
18:53:25 <bknudson> and scope
18:53:27 <marekd> does it have anytging to do with dynamic policies or it's a completely separated topic?
18:53:53 <stevemar> marekd: separate-ish
18:54:00 <ayoung> gyee, assigning a role to a user on an endpoint;  essentially, the role name only means something if the role is scoped to endpoint, not a project on the endpoint
18:54:13 <marekd> stevemar: how are they connected, then?
18:54:17 <ayoung> marekd, similar, but separate from dynamic policy
18:54:17 <gyee> unless we support endpoint scoping
18:54:26 <gyee> which still doesn't make much sense without the project
18:54:51 <ayoung> gyee, to peform an admin action, instead of requesting a proejct scoped token, user requests and endpoint scoped token
18:54:51 <marekd> ayoung: filling same bug, but in a different way, ok
18:55:01 <ayoung> marekd, yep
18:55:06 <gyee> ayoung, yes, for admin action, it make a lot of sense
18:55:13 <ayoung> dolphm, does this pass your sanity checker?
18:55:35 <ayoung> OK...so that is the first item...
18:55:38 <stevemar> dolphm might be afk
18:55:40 <bknudson> what's the service catalog look like?
18:55:51 <lbragstad> ~5 minutes left
18:55:53 <ayoung> bknudson, probably just the one endpoint
18:55:55 <bknudson> keystone won't be able to fill in the %(tenant_id)s
18:56:09 <ayoung> ok...so, we can cont that later
18:56:13 <ayoung> on to...
18:56:25 <gyee> sounds like a good topic for Tokyo
18:56:38 <ayoung> bknudson, true, but anne gentle is trying to kill that anyway...
18:56:51 <stevemar> ayoung: i suggest you and henry really hash this out before tokyo
18:56:54 <ayoung> gyee, agreed, but want to have consensus before Tokyo or we will miss 'M'
18:57:04 <ayoung> stevemar, want everyone to know what we are talking about.
18:57:07 <stevemar> ayoung: yes, service catalog: this topic https://review.openstack.org/#/c/181393/13/specs/service-catalog.rst
18:57:12 <stevemar> ayoung: understood
18:57:13 <ayoung> Henrynash's proposal is really three things
18:57:13 <gyee> ayoung, I am all for endpoint-scoping
18:57:19 <ayoung> 1.  namespacing of roles.
18:57:23 <ayoung> 2. Role inference
18:57:29 <bknudson> don't wait for the meeting to talk about it. put together a workgroup or something.
18:57:35 <ayoung> 3.  virtual roles
18:57:49 <ayoung> I was just targetting the 2
18:57:52 <stevemar> ayoung: those mean nothing to us right now :)
18:58:01 <ayoung> I have working code for that.
18:58:16 <ayoung> stevemar, right...which is why I am typing as fast as I can
18:58:20 <ayoung> role infrecne....
18:58:22 <stevemar> s'all good
18:58:32 <ayoung> an implied role means if I get "admin" I also get "member"
18:58:37 <ayoung> so policy rule can be simplified
18:58:46 <stevemar> put it up on a wiki and try to timeline it out and we can chat about it in -keystone
18:58:53 <stevemar> we're not gonna get it in 90 seconds
18:58:53 <ayoung> instead of saying "you need to have either admin or memeber" you can just say " you need to have member"
18:59:10 <stevemar> s/wiki/etherpad/g
18:59:38 <ayoung> stevemar, I put it up in a spec and I am working on example code...
18:59:44 <stevemar> everyone - please please read: https://review.openstack.org/#/c/181393/13/specs/service-catalog.rst
18:59:53 <ayoung> the thing Henry and I need to hash out is where his and mine aline
18:59:55 <ayoung> align
18:59:58 <stevemar> for sure
19:00:19 <stevemar> lets not interfere with infras time
19:00:23 <stevemar> #endmeeting