18:01:17 <stevemar> #startmeeting keystone
18:01:17 <openstack> Meeting started Tue Jun 16 18:01:17 2015 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:18 <marekd> jamie won't be here...
18:01:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:21 <openstack> The meeting name has been set to 'keystone'
18:01:36 <stevemar> marekd, yeah, jamie is on the other side of OZ today
18:01:39 <stevemar> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:01:41 <gyee> I need Jamie on one of the topics
18:02:00 <stevemar> #topic Release numbering
18:02:24 <stevemar> quick one, i wanted to give everyone a heads up on the numbering change that will occur (likely)
18:02:28 <marekd> stevemar: numbering of what: ksc, kmw, ksa, keystone?
18:02:30 <stevemar> you can read about it here: http://lists.openstack.org/pipermail/openstack-dev/2015-June/067082.html
18:02:44 <stevemar> keystone will be released as 8.0.0 in liberty, instead of 2015.2
18:02:58 <stevemar> M-release will be 9.0.0
18:03:03 <bknudson> just like windows 8 :(
18:03:04 <dstanek> marekd: all the things
18:03:07 <gyee> 8 is a luck number for me
18:03:09 <raildo> bknudson, lol
18:03:10 <stevemar> the thinking is, it's been the 8th integrated release
18:03:21 <stevemar> nova is at 12.0.0
18:03:23 <bknudson> looks like a snowman
18:03:36 <stevemar> bknudson never fails to make me laugh
18:03:48 <stevemar> any questions about it?
18:04:00 <ayoung> That is going to break so many things
18:04:02 <breton> wwill the third number ever change?
18:04:05 <stevemar> aside from what the numbers look like, snowmen or otherwise
18:04:22 <ayoung> packaging is supposed to be monotonically increasing. OTOH, I think it will aslign with RDO
18:04:27 <breton> I mean, shall we have 8.0.1?
18:04:45 <stevemar> breton, the second and third will be reserved for if we need to release a stable version of keystone
18:04:53 <henrynash_> (sorry to be late)
18:04:55 <stevemar> like we do now
18:05:12 <breton> cool, thanks
18:05:23 <stevemar> instead of 2015.1.1 (the next stable release of kilo), it would be 8.0.1 (stable release for liberty)
18:05:31 <stevemar> or 8.1.0 depending on how much changes
18:05:45 <stevemar> we're also going to have 8.0.0b1 for milestone 1
18:05:57 <bknudson> is it actually following semver?
18:06:00 <stevemar> ayoung, sorry if it breaks things, this one is out of my hands :(
18:06:04 <stevemar> bknudson, i believe that's the intent
18:06:05 <bknudson> or it's just a number?
18:06:19 <gyee> stevemar, any objections from the packagers?
18:06:25 <gyee> besides ayoung
18:06:27 <ayoung> stevemar, I'll be fine.  RDO and RH-OSP are at 7 right now anyway
18:06:37 <ayoung> I'm just laughing to myself
18:06:38 <bknudson> the REST API is versioned separately so I guess this doesn't help us much
18:06:41 <stevemar> gyee, this was made at the TC level, i wasn't really involved, just relaying the decision
18:07:03 <stevemar> henrynash, 2 laps for being late
18:07:18 <stevemar> next?
18:07:20 <henrynash> stevemar: ok, agreed, two laps of the table underway
18:07:35 <stevemar> #topic Outcome of DB2 CI
18:07:36 <gyee> if the packages are not concerned about the version change, I guess we're fine
18:07:48 <stevemar> bknudson, did you want to take this one?
18:07:54 <bknudson> oh, sure...
18:08:01 <bknudson> I think the outcome is that DB2 CI isn't going to report
18:08:10 * stevemar throws bknudon under the bus
18:08:10 <bknudson> until we can show that it's more stable
18:08:41 <stevemar> currently it's at a 88% success rate right?
18:08:42 <bknudson> or we can get people in US time to be available to disable it when it's not working
18:08:51 <bknudson> that's the only number I've seen
18:09:02 <stevemar> and it only covers tempest tests
18:09:03 <bknudson> I don't think we have actual numbers.
18:09:13 <stevemar> probably not :P
18:09:28 <dstanek> where did the 88% number come from?
18:09:39 <bknudson> dstanek: it was from other projects, not keystone
18:09:48 <bknudson> DB2 CI is running on several other projects
18:10:01 <bknudson> so it might be accurate for keystone but I don't know.
18:11:13 <stevemar> bknudson, i guess we'll let the keystone team know if anything changes
18:11:26 <stevemar> but the db2 team will monitor it internally for now
18:11:45 <bknudson> y, I'm sure they'll talk to me again here when they're ready
18:11:56 <stevemar> skipping over the jamie topic
18:12:02 <stevemar> #topic It's time to fix Bug 1291157
18:12:04 <openstack> bug 1291157 in python-keystoneclient "idp deletion should trigger token revocation" [High,Triaged] https://launchpad.net/bugs/1291157 - Assigned to Navid Pustchi (npustchi)
18:12:06 <stevemar> marekd, the floor is yours
18:12:49 <marekd> hi, i wanted to get back to the bug and refreshed some knoweldge. I know some of you were tackling it.
18:12:57 <bknudson> stevemar: you reported that a long time ago
18:13:19 <stevemar> bknudson, i did, basically the description is pretty sufficient
18:13:21 <marekd> I will have an intern this summer and thought i could make him work on that, as clearly this bug is not something that can be fixed in 1-2 hours.
18:13:43 <stevemar> marekd, sounds like a good project for the intern
18:14:02 <stevemar> under your expert guidance of course ;)
18:14:19 <marekd> stevemar: i think so, as he would need to learn about revocations in keystone either way.
18:14:24 <marekd> stevemar: don't be sarcastic :P
18:14:38 <gyee> revoke by IdP will be fun
18:14:53 <marekd> stevemar: anyway, i think it's pretty straightforward how to tackle uuid tokens, yet it may need extending the db schema.
18:14:56 <gyee> we don't index the tokens by IdP do we?
18:15:07 <bknudson> is Navid the intern?
18:15:12 <marekd> bknudson: no
18:15:16 <stevemar> bknudson, navid was a utsc guy
18:15:19 <stevemar> i'll unassign
18:15:23 <marekd> stevemar: please.
18:15:27 <marekd> stevemar: please do
18:15:29 <stevemar> done
18:15:42 <lbragstad> utsc?
18:15:47 <marekd> utsa
18:15:50 <lbragstad> ahh
18:15:53 <stevemar> whoops
18:16:04 <stevemar> utsc is a canadian uni :P my bad
18:16:12 <marekd> i wanted to know what is the status of the revocation events...
18:16:15 <ayoung> stevemar, your very bad
18:16:16 <marekd> does it even work now?
18:16:21 <marekd> ayoung: ^^
18:16:28 <ayoung> nope
18:16:35 <bknudson> revocation events can be used in keystone server
18:16:37 <ayoung> I mean, not by IdP
18:16:47 <bknudson> you can disable revoke by list
18:16:50 <ayoung> acutally, I don't know.  I have not touched revocation events in a while
18:17:02 <marekd> bknudson: ok, so we must take into consideration while working on this bug
18:17:17 <amakarov> ayoung, and I still wait for them in ksc ))
18:17:33 <bknudson> y, you either need to support both since the best we could do now is deprecate one or the other
18:17:38 <bknudson> or both
18:17:40 <stevemar> marekd, it sucks that this depend on what kind of token is issued
18:17:52 <ayoung> amakarov, go for it.
18:18:00 <marekd> stevemar: that's the nature of different tokens....lots of things change :-)
18:18:05 <ayoung> amakarov, I'm done tilting at that particular Windmill.
18:18:29 <stevemar> marekd, even if it's a solution for just 1 token format, it's better than nothing
18:18:44 <amakarov> ayoung, let's drop revocations
18:18:50 <ayoung> OK
18:18:54 <marekd> uh...?
18:19:20 <marekd> stevemar: do you think it would need some specs, approved by June 21?
18:19:52 <stevemar> marekd, preferably, but i understand if your intern hasn't started yet and you want to put them through the process
18:20:10 <stevemar> this is also low impact, so i think it's OK to make it an exception
18:20:28 <marekd> stevemar: he will be here end of June, and i will need to make some intro to the Openstack world so it may few days :-)
18:20:31 <bknudson> this is a bug, so no blueprint or spec for that
18:20:38 <marekd> bknudson: ah, cool
18:20:41 <marekd> bknudson: right.
18:20:57 <stevemar> bknudson, if the outcome is a new API or feature then a spec might be needed
18:20:59 <marekd> ayoung: is there any vision on how you'd like to see it inrevocation events?
18:21:02 <ayoung> so...intern is going to work on revoke by IdP?
18:21:12 <marekd> ayoung: that's one of the ideas i had.
18:21:20 <bknudson> it does depend on the changes, since yo can't change the api for a bug, that would be a feature
18:21:26 <ayoung> marekd, yeah, lots of visions.  I think it was the Peyote
18:21:33 <ayoung> marekd, too long for me to derail here
18:21:34 <marekd> Peyote?
18:21:49 <marekd> ayoung: i will catch up with ya one day after the meeting.
18:22:04 <marekd> lbragstad: for fernet....
18:22:18 <ayoung> marekd, so,  revocation events in the client only make sense for PKI style tokens.  I am done trying to push that through
18:22:22 <marekd> lbragstad: any opinoins, or you already see any corner cases?
18:22:27 <anteaya> marekd: https://en.wikipedia.org/wiki/Peyote
18:22:33 <ayoung> tokens in geenral should live for 5 minutes, no revation necessary
18:23:01 <ayoung> any thing longer than 5 minutes gets a trust, or a better delegation agreement than we have now anyway
18:23:02 <lbragstad> marekd: the middleware will need the token revocation lists
18:23:07 <ayoung> but...not for Liberty
18:23:07 <marekd> do we all agree revocations shall die?
18:23:16 <amakarov> ayoung, ideally tokens should have single use!
18:23:26 <marekd> i don't want to make him work on something that will die
18:23:33 <marekd> anteaya: thanks.
18:23:38 <gyee> revocation shall die
18:24:06 <ayoung> marekd, my view is that dynamic policy is key to any future sanity coming out of Keystone
18:24:30 <henrynash> so in principle I agree…but we need to make sure we understand the path the point when revocations can really die
18:24:33 <ayoung> with that, we can then work on unfied delegation, and many other things besides
18:24:35 <marekd> lbragstad: ayoung how do we revoke fernet tokens?
18:24:39 <lbragstad> marekd: otherwise we are always stuck to online validation
18:25:03 <ayoung> marekd, let me defer for now...
18:25:11 <anteaya> marekd: np
18:25:12 <henrynash> what impact on client apps who (almost entirely today) grab a token and assume that it will never experie (well not likely when the user is still logged in)
18:25:45 <marekd> lbragstad: how do we revoke fernet tokens? online validation ?
18:25:49 <gyee> henrynash, the latest auth plugins handles token renewal pretty smoothly now
18:26:17 <lbragstad> marekd: a revocation event is built and the renovation list is checked on validation of a token
18:26:34 <henrynash> which is totally teh wrong thing to do….but us wishing it wasn’t so doesn’t make it any less true
18:26:40 <marekd> lbragstad: ok, so basically it's the same mechanism as with PKI ?
18:26:58 <lbragstad> marekd: maybe, I'm not all that familiar with pki
18:27:16 <ayoung> marekd, fernet uses revocation events
18:27:24 <ayoung> so, no revocation list
18:27:27 <lbragstad> marekd: we have a bunch of those test cases added to test_v3_auth.py
18:27:52 <marekd> ayoung: ouch, so you want revocation *lists* or *events* to die?
18:27:53 <breton> do we kill revocation events or lists?
18:27:54 <marekd> or both?
18:27:58 <henrynash> we should, imho: get a godo solution of short lived tokens (provided in parallel with the current ones), provide loads of wroking examples of client code that shows how to work with such things (how to “refresh”)
18:28:01 <marekd> breton: ++ :-)
18:28:06 <marekd> breton: same question
18:28:17 <ayoung> marekd, I *want* both to die. but I am not the decider.  I never wanted either, even though I wrote both
18:28:22 <gyee> henrynash, ++
18:29:07 <ayoung> I just have no desire to continue working on either, so I'll defer.  But Revoke by IdP would have been easy if we mapped 1 IdP to one domain
18:29:19 <marekd> ayoung: ok, so it looks like i will make my guy focus on uuid for now, this should be good for a warmup at least.
18:29:39 <gyee> marekd, what you do have for him to do for encore? :)
18:30:07 <gyee> if revoke by IdP is just a warmup
18:30:21 <marekd> gyee: so you claim it's hard or too easy? :-)
18:30:44 <gyee> its hard
18:30:44 <lbragstad> so, what's going to replace revocation events/lists if it's removed?
18:30:52 <ayoung> lbragstad, nothing!
18:30:56 <ayoung> lbragstad, short term tokens
18:30:57 <marekd> gyee: so, maybe i will not need any encore :-)
18:31:03 <dstanek> lbragstad: it's just a bad model
18:31:12 <marekd> he wil be there for 2 months and it's not a really full time job.
18:31:13 <ayoung> the idea is that a token should last such a short amount of time, that by the time you revoke it, it has expired
18:31:19 <lbragstad> token_expiration = 60 or something?
18:31:32 <breton> lbragstad: that's the point -- the token will die young and their exposure will not give anything
18:31:33 <ayoung> I say 5 minutes, as that seems to be the limit of click skew, but sure
18:31:39 <marekd> ok, i have a clearer vision. thanks for now.
18:31:42 <marekd> stevemar: ^^
18:31:42 <lbragstad> ok
18:31:44 <lbragstad> makes sense
18:31:45 <lbragstad> thanks
18:31:51 <ayoung> lbragstad, I'd like to see tokens themselves go away
18:32:09 <marekd> ayoung: in favor of what?
18:32:12 <marekd> saml assertions?
18:32:19 <ayoung> instead, I authenticate as me using X509 or Kerberos or SAML, and the remote server looks at the deleagtion ID I provide to see if Ia ma ctually authorized
18:32:22 * marekd please, not saml!
18:32:35 <breton> we didn't we use oauth instead of tokens?
18:32:42 <ayoung> marekd, SAML for those that want it, X509 or Kerberos for those of us that want it
18:32:54 <ayoung> breton, same same
18:33:07 <gyee> brethon, oath uses *tokens*
18:33:11 <stevemar> i think we're getting off topic ish
18:33:12 <ayoung> oauth and keystone are pretty similar,  as far as why...ask those who came before the project
18:33:13 <gyee> access tokens, refresh tokens, etc
18:33:18 <ayoung> yes we are
18:33:21 <ayoung> I tried to defer
18:33:38 <ayoung> everytime I think I'm out they pull.me.back.in!
18:33:42 <gyee> stevemar, next topic
18:33:44 <ayoung> next topic
18:33:46 <stevemar> let's end it here and give raildo htruta and rodrigods some time
18:33:47 <marekd> ++
18:33:47 <breton> ++ next topic
18:33:53 <stevemar> #topic New way to get a project scoped token by name with Reseller
18:33:56 <htruta> cool
18:34:01 <raildo> :D
18:34:09 <raildo> hey guys, as we had discussed last week, we created a etherpad with the alternatives to get a project scoped token by name after reseller
18:34:11 <rodrigods> so it's time to vote :)
18:34:16 <raildo> https://etherpad.openstack.org/p/reseller-project-token
18:34:16 <htruta> guess most of you guys have read the etherpad
18:34:33 <raildo> rodrigods, ++
18:34:43 <raildo> we decided to take a vote to choose the best option and after that we will write the spec.
18:35:20 <stevemar> raildo, htruta rodrigods go over the options quickly?
18:35:38 <gyee> I vote for 5
18:35:44 <raildo> stevemar, can be
18:35:51 <htruta> ok
18:35:53 <htruta> (1) Specify the project hierarchy up to the domain as a string separeted by a configurable delimiter
18:35:54 <stevemar> oh geez 6 options
18:36:08 <raildo> stevemar, sorry about that :(
18:36:09 <samueldmq> gyee, ++ I kind of agree, at least for now :)
18:36:10 <dstanek> gyee: +1000
18:36:13 <htruta> (2) Provide empty project name when intended to get a project scoped token to is_domain project.
18:36:15 <stevemar> everyone take a few minutes to read the options
18:36:28 <htruta> guess I don't need to paste them all here, write?
18:36:30 <henrynash> gyee: definitely disagree!
18:37:04 <raildo> I don't like the 5 option too :P
18:37:13 <gyee> if we allow intermix between project and domain, I see OSSA/Ns in the future
18:37:14 <stevemar> ewww to 2
18:37:16 <dstanek> henrynash: the problem i have is that Project<is_domain=True> should be treated like a domain and not a project5
18:37:37 <gyee> we already have project/service admin bleedover
18:37:44 <henrynash> no…becomes scope specifies we are looking for a project
18:37:46 <lbragstad> stevemar: ++
18:37:57 <stevemar> i kinda like 3
18:38:02 <htruta> if we choose the 5, we are not having domains as a feature of project
18:38:09 <breton> why do we even allow domain-scoped by name?
18:38:14 <htruta> which is on of the main proposals of reseller
18:38:21 <henrynash> stevemar: did I hint i liked that one as ell too strongly?
18:38:26 <bknudson> the eww factor only applies to the JSON representation. The client lib and CLI can make it look better
18:38:31 <breton> lets use uuids
18:38:47 <stevemar> henrynash, not at all
18:38:50 <henrynash> breton: we support both project and domain tokens today by name
18:38:51 <marekd> 3 looks more readible at hte 1st glance
18:39:12 <raildo> breton, imo the best way is provide tokens by uuids, but since we provide tokens by names, we will have this issue after reseller
18:39:16 <stevemar> i'm thinking 3 or 5
18:39:17 <breton> or make a new field, like slug.
18:39:22 <rodrigods> i dislike 3 because it Cons
18:39:24 <stevemar> whats the impact of 5?
18:39:47 <henrynash> breton: just that today they refer to seperate entites…which now get merger with “ a domain is represented as a project with teh is_domain attrbute set”
18:39:56 <htruta> stevemar: I think it will make if difficult to integrate with other services
18:39:57 <gyee> we need to clearly distinguish betwen project admin, service admin, and domain admin
18:39:58 <raildo> stevemar, as htruta said,  we are not having domains as a feature of project
18:40:06 <bknudson> I like option 1 where the hierarchy is a list instead of a string.
18:40:13 <dstanek> imo 5 keeps the domain/project dynamic much closer to what it is today and will be less confusing overall
18:40:22 <amakarov> #vote 5
18:40:23 <rodrigods> bknudson, bad for exporting vars
18:40:27 <htruta> we wanted to be able to treat all of them as project to make it easier to other OS services
18:40:27 <lhcheng_> dstanek: ++
18:40:32 <stevemar> amakarov, haven't started the vote yet :P
18:41:03 <stevemar> we could use the vote to narrow down options at least
18:41:10 <dstanek> if we don't do #5 i don't understand how a user know what is a domain or project and when to act is if it's either
18:41:10 <stevemar> and work through the details in the spec
18:41:10 <amakarov> stevemar, but you saw it :P
18:41:19 <henrynash> yep, remember that one of the goals here is to allow cilents to not have to worry about domain tokens….eveything should (in the end) be project tokens
18:41:34 <gyee> stevemar, or we can put +6 on a single choice :_
18:41:34 <htruta> henrynash: ++
18:41:38 <raildo> stevemar, and if we choose other option 1-4, we don't need, for example, provide domain scoped token to Horizon
18:41:41 <rodrigods> henrynash, ++
18:41:47 <raildo> henrynash, ++
18:42:24 <henrynash> a domin is just a funny kind of project that allows you to also hang users/groups off
18:42:31 <stevemar> everyone ready for a vote?
18:42:32 <lhcheng_> htruta: for other OS services what's the use case where they need to get domain scoped token?
18:42:39 <dstanek> henrynash: then why don't we drop support for them in general?
18:42:58 <htruta> lhcheng_: they won't. they'll keep using project scoped tokens
18:42:59 <raildo> dstanek, it's simple, if the is_domain=True, is a project that behaviour as a domain
18:43:11 <henrynash> dstanek: I think we are headed taht way…we are basically frezzingthe domain API and ding evyerting via teh project APi now
18:43:17 <gyee> security guys don't like ambiguity
18:43:23 <dstanek> raildo: what does that mean tho? what is the behavior?
18:43:46 <henrynash> dtsanek: e.g. you can create a “domain” with create_project if the attribute is_domain=True in the entity you apss in
18:43:52 <raildo> as a domain works today... create user, groups...
18:43:59 <dstanek> henrynash: i still don't get why we allow projects to have a parent that is not is_domain=True
18:44:02 <rodrigods> gyee, we intend to drop the ambiguity in the future
18:44:08 <lhcheng_> htruta: if other services won't use it, we're not making it easier for anyone. since no services is really going to use it. we might be just making it complicated.
18:44:25 <henrynash> dstanek: you mean project hierachy below a “domain”?
18:44:40 <dstanek> henrynash: yes
18:44:41 <samueldmq> lhcheng_, how does horizon do to create users ? what token does it use ?
18:45:17 <henrynash> dstanek: that’s so complex environemtn can model there projects better (and do thinsg like quotas that role up a tree etc,)
18:45:24 <lhcheng_> samueldmq: project token, horizon still doesn't support domain scoped token.
18:45:35 <htruta> lhcheng_: they do not use today and we are not making them use in the future. we're just ensuring that they cant handle the whole hierarchy, without even knowing what a domain is
18:45:48 <htruta> they can**
18:46:09 <dstanek> henrynash: it seems that the model would be much simpler to say a project's parent must alwasy be is_domain=True
18:46:16 <lhcheng_> samueldmq: still wip, because horizon have some issue consuming the keystone v3 policy files.
18:46:29 <gyee> funny project versus project is ambiguity
18:46:39 <henrynash> dtsanek: which is basically the model we have before any of the projec hierachy stuff arrived….!
18:46:40 <bknudson> lhcheng_: all policy files are v3.
18:46:45 <dstanek> gyee: ++ exactly
18:46:57 <rodrigods> should we vote?
18:47:05 <dstanek> henrynash: not true...you couldn't nest domains right?
18:47:09 <henrynash> bkundson: ++ ( I rue the date I named that sampel file the way I did!)
18:47:16 <henrynash> dstanake: nope
18:47:50 <henrynash> dstanek: all domains are at the top, each has a flat layer of projects….that was the original (pre-hierarchy) sitaution
18:47:50 <stevemar> vote time
18:47:52 <htruta> dstanek, henrynash, actually, you can
18:47:57 <lhcheng_> bknudson:  our default policy is not domain aware.
18:48:03 <dstanek> henrynash: to me a easier model for this would be a filesystem - directories(domain) contain other directories and files(projects)
18:48:06 <htruta> you'll be able to, in reseller
18:48:14 <henrynash> hruta: NOW you can yes, but not befor we had hieracrchys
18:48:53 <stevemar> #startvote option for getting a project scoped token? 1, 2, 3, 4, 5, 6
18:48:54 <openstack> Begin voting on: option for getting a project scoped token? Valid vote options are 1, 2, 3, 4, 5, 6.
18:48:55 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:49:00 <stevemar> #link https://etherpad.openstack.org/p/reseller-project-token
18:49:01 <bknudson> #vote 1
18:49:06 <gyee> #vote 5
18:49:07 <dstanek> #vote 5
18:49:07 <henrynash> dtsanek: (I did actually argue for that when hieracrhies came in.. that acyuallywhat we ewanted was domain hieracries not project hierachies)
18:49:10 <amakarov> #vote 5
18:49:11 <lbragstad> #vote 5
18:49:12 <raildo> #vote 3
18:49:16 <htruta> #vote 3
18:49:18 <henrynash> #vote 3
18:49:18 <iurygregory> #vote 3
18:49:19 <stevemar> #vote 3
18:49:20 <marekd> #vote 3
18:49:22 <rodrigods> #vote 3
18:49:25 <lhcheng_> #vote 5
18:49:25 <dstanek> henrynash: ++ yep
18:49:33 <david8hu> #vote 5
18:49:35 <stevemar> #showvote
18:49:36 <openstack> 1 (1): bknudson
18:49:37 <openstack> 3 (7): rodrigods, marekd, iurygregory, htruta, henrynash, raildo, stevemar
18:49:38 <openstack> 5 (6): gyee, dstanek, lbragstad, david8hu, amakarov, lhcheng_
18:49:39 <haneef> #vote 5
18:49:57 <stevemar> you had to tie things up haneef !
18:49:59 <henrynash> ouch!
18:50:01 <stevemar> #showvote
18:50:02 <openstack> 1 (1): bknudson
18:50:03 <openstack> 3 (7): rodrigods, marekd, iurygregory, htruta, henrynash, raildo, stevemar
18:50:03 <lhcheng_> haneef for the tie
18:50:04 <openstack> 5 (6): gyee, dstanek, lbragstad, david8hu, amakarov, lhcheng_
18:50:05 <gyee> k, no run-away ehre
18:50:20 <stevemar> haneef, can you vote again, without a leading space :)
18:50:31 <haneef> #vote 5
18:50:32 <rodrigods> bknudson, change to 3? :)
18:50:36 <stevemar> thx!
18:50:38 <stevemar> #showvote
18:50:39 <openstack> 1 (1): bknudson
18:50:40 <openstack> 3 (7): rodrigods, marekd, iurygregory, htruta, henrynash, raildo, stevemar
18:50:42 <raildo> haha
18:50:42 <openstack> 5 (7): gyee, dstanek, haneef, lbragstad, david8hu, amakarov, lhcheng_
18:50:43 <dstanek> dumb question about #3.... are all domain names unique?
18:50:49 <raildo> dstanek, yes
18:50:50 <rodrigods> dstanek, yes
18:50:50 <htruta> dstanek: yes, they are
18:51:06 <htruta> not only in 3, btw :P
18:51:24 <dstanek> how do we enforce that?
18:51:37 <stevemar> in the backends i believe
18:51:46 <henrynash> dtsanek, stevemar: yes
18:51:46 <dstanek> bummer :-(
18:51:53 <lbragstad> about 9 minutes remaining
18:52:19 <stevemar> so i'm ending the vote here, raildo rodrigods htruta take the 2 options going forward and present them in the spec
18:52:22 <stevemar> #endvote
18:52:23 <openstack> Voted on "option for getting a project scoped token?" Results are
18:52:24 <openstack> 1 (1): bknudson
18:52:25 <openstack> 3 (7): rodrigods, marekd, iurygregory, htruta, henrynash, raildo, stevemar
18:52:26 <openstack> 5 (7): gyee, dstanek, haneef, lbragstad, david8hu, amakarov, lhcheng_
18:52:33 <stevemar> thanks guys
18:52:46 <raildo> ok, thank you guys :)
18:52:48 <henrynash> stevemar: ++ it’s too close to call just here
18:52:49 <stevemar> really quickly going to gyee
18:52:58 <stevemar> #topic Should Endpoint Constraint Enforcement be its own middleware, or not?
18:53:02 <rodrigods> thanks guys
18:53:06 <marekd> ++
18:53:25 <gyee> stevemar, I need jamielennox on this one since he's the only one wants it to be a separate middleware
18:53:38 <gyee> I guess I can play this out in ML?
18:53:49 <stevemar> educate us us for 2 minutes?
18:53:59 <gyee> you guys have any strong opinion on this one?
18:54:13 <stevemar> theres also this: https://review.openstack.org/#/c/177661/
18:54:15 <gyee> basically for endpoint enforcement, it is currently part of auth_token middleware
18:54:37 <samueldmq> gyee, I kind of agree with him ... auth_token should only be doing what it is supposed to do (validte tokens)
18:54:40 <ayoung> gyee current thought make it its own middleware
18:54:46 <ayoung> and it shoudlbe for enforcing policy
18:54:46 <samueldmq> gyee, anything different should go in a separate middleware
18:54:47 <gyee> arguments for it were 1) it should be part of "token validation", and 2) it is less disruptive for CMS
18:55:26 <gyee> ayoung, right, I had it as separate middleware at the beginning
18:55:31 <ayoung> but...morgan was the one that wanted it unified
18:55:36 <ayoung> and we can;t make that call without him
18:55:39 <gyee> you and morganfainberg convinced me to merge it with auth_token
18:55:53 <ayoung> gyee, and you are OK with either approach, and really, so am I
18:55:58 <gyee> I am happy to separate it out again
18:56:05 <stevemar> gyee, prisoner to the whims of the ptl
18:56:18 <gyee> stevemar, :)
18:56:20 <ayoung> actually, who said split it besides Jamie?
18:56:34 <ayoung> I'm a pushover here..I just want progress
18:56:34 <gyee> ayoung, Jamie so far
18:56:40 <bknudson> what's the argument against splitting it?
18:56:55 <ayoung> put it to a vote, understanding that PTL would vote unified
18:56:56 <dstanek> i don't see the value of splitting it out
18:57:01 <gyee> bknudson, 1) it should be part of "token validation", and 2) it is less disruptive for CMS
18:57:10 <stevemar> bknudson, "endpoint/global policy enforcement is really part of "token validation""
18:57:10 <ayoung> review link?
18:57:14 <stevemar> https://review.openstack.org/#/c/177661/
18:57:17 <gyee> yay! lets vote
18:57:36 <gyee> frankly, I'm going with my magic 8 ball on this one
18:57:46 <ayoung> jamie's vote and morgan's will cancel out, I think
18:57:55 <stevemar> we'll let morgan decide this one when he's back
18:57:56 <ayoung> stevemar, put it up for vote, please?
18:58:05 <ayoung> stevemar, let's have the vote for him anyway
18:58:14 <gyee> oh com'on, we want democracy!
18:58:18 <gyee> we want freedom!
18:58:26 <gyee> vote damit!
18:58:29 <marekd> "money for nothing, chick for free"
18:58:34 <marekd> chicks
18:58:37 <bknudson> this is why canada still has a queen
18:58:43 <marekd> :D
18:58:45 <stevemar> #startvote should endpoint enforcement be it's own middleware? yes, no
18:58:46 <openstack> Begin voting on: should endpoint enforcement be it's own middleware? Valid vote options are yes, no.
18:58:48 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:58:51 <stevemar> fastest vote ever
18:58:54 <ayoung> #vote no
18:58:58 <gyee> #vote no
18:59:03 <dstanek> #vote no
18:59:04 <bknudson> #vote no
18:59:05 <henrynash> #vote no
18:59:06 <marekd> #vote no
18:59:06 <lbragstad> #vote no
18:59:07 <lhcheng> #vote no
18:59:12 <stevemar> #vote no
18:59:15 <samueldmq> #vote maybe ?
18:59:16 <openstack> samueldmq: maybe ? is not a valid option. Valid options are yes, no.
18:59:19 <bknudson> jamie will probably just put it in its own middleware later anyways
18:59:21 <david8hu> #vote no
18:59:23 <ayoung> samueldmq, just abstain
18:59:27 <lbragstad> bknudson: ++
18:59:28 <stevemar> lol
18:59:29 <morganfainberg> #vote really?we'rehavingthisvote?causeit'sillytobeseparatefromvalidation
18:59:29 <openstack> morganfainberg: really?we'rehavingthisvote?causeit'sillytobeseparatefromvalidation is not a valid option. Valid options are yes, no.
18:59:43 <stevemar> #endvote
18:59:44 <openstack> Voted on "should endpoint enforcement be it's own middleware?" Results are
18:59:45 <openstack> no (10): gyee, dstanek, ayoung, lhcheng, bknudson, marekd, lbragstad, david8hu, henrynash, stevemar
18:59:50 <stevemar> we're at time
18:59:56 <gyee> wow, its unanimous
18:59:57 <lbragstad> thanks all!
18:59:58 <stevemar> thanks all!
19:00:02 <marekd> o\
19:00:06 <henrynash> oh boy
19:00:06 <ayoung> we'll count it as 11 nos, 1 yes
19:00:14 <ayoung> cuz morganfainberg should have voted, but hey
19:00:16 <stevemar> sorry jamie :(
19:00:25 <stevemar> ayoung, its in the minutes :P
19:00:26 <morganfainberg> ayoung: what you didn't see my vote?
19:00:30 <morganfainberg> :P
19:00:45 <stevemar> #endmeeting