18:01:09 <stevemar> #startmeeting keystone
18:01:10 <openstack> Meeting started Tue Jul 12 18:01:09 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:12 <jaugustine> o/
18:01:15 <openstack> The meeting name has been set to 'keystone'
18:01:16 <knikolla> o/
18:01:18 <stevemar> of course they are testing the fire alarm now...
18:01:21 <nk2527> howdy
18:01:23 <bknudson_> hi
18:01:33 <dstanek> o/
18:01:35 <henrynash> stevemar: pardon? can;t hear you
18:01:35 <rderose_> o/
18:01:36 <stevemar> \o/
18:01:55 <samueldmq> hey folks o/
18:02:06 <gagehugo> hi
18:02:33 <stevemar> silenced it
18:02:37 <stevemar> okay, let's go!
18:02:39 <lamt> hello
18:02:45 <stevemar> lamt: hey!
18:02:48 <stevemar> agenda link: Newton-2 is being cut this week
18:02:50 <stevemar> err
18:02:54 <stevemar> agenda link: https://etherpad.openstack.org/p/keystone-weekly-meeting
18:02:56 <stevemar> copy paste fail
18:02:59 <gyee> \o
18:03:07 <stevemar> fun and full meeting today!
18:03:14 <stevemar> so many topics
18:03:19 <stevemar> #topic Newton-2 is being cut this week
18:03:27 <stevemar> this is just an update
18:03:39 <stevemar> friday we will propose our newton-2 driver
18:03:51 <stevemar> no serious bugs so far
18:04:06 <stevemar> i bumped the following blueprints to newton-3: I have bumped the following blueprints: pci-dss, microversions, schema-validation, project-tree-deletion
18:04:23 <stevemar> The credentials-encryption blueprint is the only one left targeted for newton-2: https://review.openstack.org/#/c/317169/
18:04:34 <stevemar> and it could use some eyes... dolphm ^ nonameentername ^
18:04:52 <nisha_> o/
18:05:25 <stevemar> there were no new specs that landed last week (henrynash's is still pending)
18:05:52 <stevemar> any questions / comments?
18:05:54 <samueldmq> stevemar: hmt spec ?
18:06:10 <stevemar> samueldmq: yes, that is henrynash's that i was referring to
18:06:19 <samueldmq> gotcha
18:06:21 <stevemar> but it's not approved, we agreed to wait til midcycle to discuss
18:06:33 <henrynash> stevemarL indeed
18:06:44 <stevemar> oh breton had a spec approved, can you create a blueprint for it and target newton-3?
18:06:45 * samueldmq nods
18:07:30 <breton> stevemar: yep
18:07:35 <stevemar> breton: thank you!
18:07:44 <stevemar> next topic ?
18:08:22 <stevemar> #topic keystone mascot/logo
18:08:26 <lbragstad> i think dstanek had a suggestion for our mascot...
18:08:35 <stevemar> this one is bound to be fun
18:08:43 <stevemar> there is a mailing list topic about it: http://lists.openstack.org/pipermail/openstack-dev/2016-July/099046.html
18:08:48 <nisha_> :D
18:08:57 <stevemar> The foundation wants consistent logos from each openstack project/service, they're taking suggestion based on things in the natural world: an animal, fish, plant, or natural feature such as a mountain or waterfall. A professional illustrator will be creating them for all projects
18:08:58 <henrynash> i added a few suggestions :-)
18:09:02 <stevemar> i think it's a great idea
18:09:09 <rderose_> ++
18:09:16 <stevemar> Deadline is July 27th
18:09:16 <stevemar> Info: http://www.openstack.org/project-mascots
18:09:16 <stevemar> Suggestions: https://etherpad.openstack.org/p/keystone-mascot
18:09:28 <raildo> #link https://www.youtube.com/watch?v=LOdsuNr2T-o for more informations
18:09:37 <dstanek> lbragstad: i'm pretty sure it wouldn't be allowed :-)
18:09:49 <stevemar> awww, sorry to whoever recommended fluffy, only *real* things are allowed
18:10:09 <stevemar> so no unicorns, dragons, 3 headed dogs, etc :)
18:10:48 <gyee> pikachu?
18:10:49 <amakarov> stevemar: A big fat burocrat sitting behind his desk!
18:10:49 <dstanek> what about a wombat?
18:10:52 <stevemar> Can my mascot be an imaginary animal/feature?
18:10:53 <stevemar> No. (Dragons, unicorns, centaurs, etc., are excluded.)
18:11:18 <stevemar> amakarov: are you calling me that or is that a logo suggestion? :]
18:11:31 <bknudson_> Do wombats actually exist?
18:11:37 <dstanek> we nicknamed a project wombat because it looks cool, but can also stand for 'waste of money brains and time' - management didn't know the second part
18:11:46 <amakarov> stevemar: Are you sitting behind a buro? ;)
18:11:51 <lbragstad> dstanek lol
18:12:03 <dstanek> unicorns exist
18:12:14 <samueldmq> yeah, there are many in Brazil
18:12:20 <gyee> dstanek, whatever you are smoking, I want some of that
18:12:39 <dstanek> next topic!
18:12:40 <lbragstad> what about the loch ness monster
18:12:42 <stevemar> oh i like the turtle idea
18:12:56 <dstanek> ....or i will waste all your times
18:13:07 <stevemar> anyway, please add +1's or i'll send out a survey soon
18:13:22 <amakarov> stevemar: http://www.stihi.ru/pics/2015/10/23/5845.jpg
18:13:29 <stevemar> thats me!
18:13:59 <stevemar> hehe
18:14:00 <samueldmq> lol
18:14:09 <stevemar> alright, so please add suggestions to the etherpad
18:14:36 <stevemar> i'll send out a poll EOW to anyone who has had a patch land this release or last
18:14:56 <notmorgan> I hear pokemon are real gyee,you just need an app on your phone to see them.
18:15:02 <stevemar> if i can figure that out :P
18:15:05 <dstanek> trolls under a bridge
18:15:18 <stevemar> next topic, should be quick
18:15:20 <breton> oh these non-tech topics
18:15:22 <notmorgan> may i recommend a "keystone" animal
18:15:25 <gyee> notmorgan, I know! :-)
18:15:40 <stevemar> breton: they get more participation :P
18:15:41 <notmorgan> look it up :)
18:15:48 <stevemar> #topic Keystone API sprint
18:15:54 <stevemar> it's tomorrow!
18:16:03 <amakarov> notmorgan: squeezed Scrappy from Ice Age? ;)
18:16:07 <stevemar> details here: https://etherpad.openstack.org/p/keystone-api-sprint
18:16:22 <samueldmq> notmorgan: hmm, looks like there is something called "keystone species"
18:16:23 <samueldmq> :)
18:16:24 <stevemar> i'll add a google hangout link to the etherpad
18:16:28 <samueldmq> oops, topic changed, sorry
18:16:34 <notmorgan> samueldmq: yes.
18:16:50 <stevemar> you can see the APIs are being pulled from the keystone repo now
18:17:23 <stevemar> let's remove them from the keystone-specs repo, and have a single source of truth
18:18:06 <samueldmq> stevemar: ++
18:18:12 <stevemar> looking forward to it
18:18:20 <samueldmq> stevemar: a good thing is that the code merges with the API change
18:18:20 <stevemar> #topic Midcycle sprint agenda
18:18:32 <stevemar> samueldmq: yep
18:18:34 <samueldmq> as separate from the spec, so the code *always* match the API docs
18:18:49 <stevemar> midcycle is coming up: https://etherpad.openstack.org/p/keystone-newton-midcycle
18:19:18 <stevemar> keep the etherpad for the agenda, use the wiki to find information about the location and such
18:19:28 <stevemar> it'll be fun to see everyone soon!
18:19:55 <stevemar> i'll cancel next weeks meeting since we'll be traveling
18:20:29 <stevemar> no questions, good, got through all this in 20 minutes!
18:20:34 <stevemar> #topic microversions
18:20:37 <stevemar> henrynash: ^
18:20:52 <henrynash> ok  right
18:20:55 <stevemar> breton: you have your wish :)
18:21:22 <henrynash> so we merged a spec for this…but questions is…should we do it anyway….or only if we have a chnage to the API that needs it?
18:21:49 <samueldmq> I think we should start with a real use for it
18:21:49 <henrynash> (however, you *could* argue that any change to the API should be microversioned, even teh addtion of a new attribute)
18:22:14 <samueldmq> otherwise seems unnecessary ?
18:22:16 <henrynash> like rderose’s password_valid_to attribute
18:22:43 <rderose_> * password_expires_at :)
18:22:45 <rodrigods> should be used only if it is impossible to keep API compatbility without it
18:22:47 <dstanek> i don'
18:22:47 <henrynash> oops, sorry
18:22:50 <breton> stevemar: huh?
18:22:55 <dstanek> t think adding should be microversioned
18:23:28 <dstanek> i don't think it would be bad to start supporting it now. that way we get it in and get some experience before we're under the gun
18:23:36 <jamielennox> so we've always had the incrementing API version, just noone really uses it
18:23:40 <stevemar> breton: we're finally on a technical topic :)
18:23:45 <knikolla> dstanek: ++
18:23:49 <samueldmq> when we add we create a new version anyways (keystone 3.6, 3.7 and so on)
18:23:59 <henrynash> jamielennox: yep…and there is no way of asking for an API for any other version that the current one
18:24:02 <topol> o/ catching up
18:24:10 <jamielennox> i'm not sure anyone would use the microversions either unless we had a reason people had to for different behaviour
18:24:34 <samueldmq> henrynash: jamielennox but generally changes that add things are backward compat
18:24:40 <jamielennox> henrynash: well it means that every new addition to the API has been optional, the old behaviour is just not adding the new options
18:24:54 <samueldmq> so new arguments are optional making it still possible to use an old version...
18:25:09 <gyee> I don't think OCLI have a generic way to facilitate microversion right now
18:25:10 <bknudson_> is the change to add password_expires_at backwards compatible? If I start sending that to an old keystone it's not going to work as expected.
18:25:19 <stevemar> gyee: true
18:25:55 <jamielennox> bknudson_: that could be argued for every API change > 3.0
18:26:04 <gyee> there will be a whole bunch of changes, including the way we load the plugins
18:26:22 <henrynash> samueldmq: … and a on old client would get slight different things back if they spoke to an old and a new server at the moment
18:27:08 <samueldmq> henrynash: speaking to 2 different versions of keystone ?
18:27:16 <samueldmq> the same client? that seems odd
18:27:20 <dstanek> samueldmq: i do it all the time
18:27:23 <bknudson_> for example is_domain on projects... that would break using old keystone.
18:27:33 <henrynash> bknduson:_: yep
18:28:02 <samueldmq> hmm, so other projects can't decide whether is_domain is available or not ... e.g if version is 3.6 then is_domain exists
18:28:07 <henrynash> smaueldmq: imagine access differnet pubcl cloud kestones with agiven client, how would you know what you would get
18:28:14 <samueldmq> but there is no way to differentiate things inside 3.x
18:28:15 <bknudson_> you can get the version from keystone.
18:28:21 <rderose_> bknudson: password_expires_at is only returned in the response object
18:28:43 <rderose_> bknudson: so response now has the new attribute, but not allowed in the request
18:28:50 <samueldmq> bkeller`: you're correct
18:29:04 <stevemar> i don't think we've thought about how to fully use microversions end to end
18:29:15 <stevemar> osc doesn't have support for it :(
18:29:29 <stevemar> so how are keystone users going to take advantage of microversions
18:29:32 <henrynash> stvevemar: not generic support, no
18:30:07 <jamielennox> i realy don't think it's something that should ever be exposed to users via OSC
18:30:18 <dstanek> i would really like to start baking in the support first and before we expose things to the end user.
18:30:24 <jamielennox> but i'm pretty sure i lost that
18:30:41 <dstanek> lots of details need to be looked at...how do have support different validation for different versions...etc
18:30:48 <henrynash> dstanek: that’s kind of my feeling…..
18:30:58 <samueldmq> dstanek: ++
18:31:28 <stevemar> yep, thats what i was referring to
18:31:33 <samueldmq> otherwise we endup as driver versioning
18:31:40 <bknudson_> doesn't sound like we have an immediate need for microversions so let's not add the complexity
18:31:48 <samueldmq> (which we are droping support now)
18:31:50 <stevemar> agreed
18:32:02 <stevemar> bknudson_: that somewhat brings up the next topic
18:32:04 <rderose_> bknudson_++
18:32:19 <bknudson_> the next person to propose a backwards-incompatible change is going to have technical debt to deal with
18:32:27 <gyee> ++
18:32:32 <henrynash> ok, so general feelin is..whait till we nned it
18:32:41 <bknudson_> and hopefully we can get them to pay down the debt rather than just adding more.
18:32:51 <stevemar> henrynash: cue the topic change?
18:32:54 <henrynash> yep
18:32:56 <dstanek> fwict keystone have never been backward compatible between releases
18:32:59 <jamielennox> yep, i don't think we need it yet
18:33:07 <samueldmq> ++
18:33:07 <stevemar> #topic Booleans or key-only query attributes in our Identity spec
18:33:22 <dstanek> that's a little scarry...(to wait)...but alright
18:33:45 <notmorgan> dstanek: fwiw, people have run keystone with older openstacks usually if they upgrade one component
18:33:50 <notmorgan> vs. all
18:33:52 <henrynash> ok, query attributes as booleans
18:34:04 <notmorgan> we are mostly compatible in most cases.
18:34:08 <henrynash> so we have mixture in our API
18:34:22 <bknudson_> great, now we're going to find out we need microversion.
18:34:25 <henrynash> some are key-only, some are booleans (where we expect ‘0’ for flase)
18:35:00 <rodrigods> booleans are the "more" correct
18:35:07 <henrynash> the api guidlines group are discussing this, but no conclusion
18:35:08 <rodrigods> at least, for the API spec
18:35:10 <jamielennox> please go booleans
18:35:13 <topol> please keep interoperability in mind as we discuss things like microversions, etc
18:35:27 <gyee> where's the API working group when we need them?
18:35:32 <jamielennox> i really dislike the raw flag, particularly if it then doesn't check like ?nocatalog=0 for false
18:35:34 <gyee> this is API consistency matter
18:35:55 <henrynash> if the API working have a leaning, it appears to be for booleans rather than key-only
18:35:55 <rodrigods> gyee, yes... but we started using key-only
18:36:01 <notmorgan> as long as you don't change that "0" works if it works today
18:36:01 <gyee> I mean guidelines should come from API working group
18:36:08 <notmorgan> again, don't break backwards compatibility
18:36:09 <rodrigods> and then realised they are not so great
18:36:15 <gyee> I don't care what it is so as long as it is consistent for ALL APIs
18:36:22 <notmorgan> you can prefer booleans
18:36:27 <notmorgan> ut if 0 works today, maintain it
18:36:30 <rderose_> gyee++
18:36:40 <bknudson_> I'd prefer no booleans but instead essentially enums
18:36:56 <bknudson_> e.g. ?catalog=none
18:37:06 <notmorgan> bknudson_: i like that the best.
18:37:16 <dstanek> when we say boolean we are talking 'false' instead of 0?
18:37:19 <rodrigods> bknudson_, ++ not "booleans" but key/value pair
18:37:20 <notmorgan> but again, if we support it today, don't break it.
18:37:28 <stevemar> what does the API working group recommend?
18:37:34 <notmorgan> also do not make a config flag that changes behavior.
18:37:40 <henrynash> the challenge for booleans is that there isn’t really a standard for what should match true/false as aI said we chsoe ‘0’ for false and anyting eles mans true (including myvalue=’false’)
18:37:40 <rodrigods> key-only generates weirdness like: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/base.py#L357-L364
18:38:07 <lbragstad> there also isn't a python library to convert key/value query strings, is there?
18:38:16 <rodrigods> henrynash, that challenge was introduced by key-only
18:38:23 <bknudson_> requests or our crappy library not supporting key-only is a poor argument.
18:38:34 <dstanek> lbragstad: sure is
18:38:36 <rodrigods> lbragstad, sure
18:38:40 <rodrigods> key-only doesn't
18:38:46 <lbragstad> ah - gotcha
18:38:51 <notmorgan> also shouldn't ?nocatalog
18:38:54 <notmorgan> just work
18:38:58 <notmorgan> even without a value?
18:39:05 <gyee> nocatalog works
18:39:07 <raildo> notmorgan, I believe so
18:39:41 <notmorgan> so, key-only seems to be api breaking. fwiw
18:40:04 <gyee> while we are at it, should names be case-sensitive? :-)
18:40:07 <samleon> ?include_names, without value still works, what's confusing is ?include_names=false, it returns true
18:40:10 <henrynash> dolphm: you here  - I know you have some string feelings here…?
18:40:31 <lbragstad> henrynash dolphm is on vacation today i believe
18:40:43 <rodrigods> accepting all kind of "positive" values with key-only was the first mistake
18:40:47 <notmorgan> it is easy to convert values to booleans fwiw
18:40:50 <rodrigods> but now we need to be backwards compatible
18:41:05 <lbragstad> so can we deprecate the use of key-only?
18:41:16 <jamielennox> >>> parse.parse_qs('test=1&nocatalog')
18:41:16 <jamielennox> {'test': ['1']}
18:41:22 <notmorgan> {'false', False, 0, "0", None}[key.tolower()]
18:41:25 <bknudson_> we can introduce a microversion to change the arguments
18:41:26 <henrynash> lbragstad: with a microversion :-)
18:41:27 <lbragstad> and introduce key/value instead?
18:41:34 <notmorgan> or well
18:41:35 <rodrigods> jamielennox, ++
18:41:48 <jamielennox> so it's not just a requests/client problem
18:41:54 <jamielennox> it means we have to scan the string manually
18:42:00 <notmorgan> or whatever. but you can check the string
18:42:12 <notmorgan> basically make it a set.
18:42:21 <notmorgan> and lower it.
18:42:32 <henrynash> notmorgan: which is how I think I tried to write it orgionally way back when we first added passing filter queries down to SQL…but go shot down
18:43:18 <henrynash> notmorgan: what abour foreign languages? do we have support Non, Neit etc.?
18:43:30 <gyee> hahah, nice one
18:43:34 <rodrigods> lol
18:43:43 <notmorgan> henrynash: we only support documented python falses.
18:43:43 <rodrigods> não :)
18:43:47 <stevemar> can we not just document how it'll work if there's a key-only and deal with the technical debt
18:43:55 <gyee> nocatalog=是
18:44:11 <notmorgan> it is all we can expect to support.
18:44:22 <rodrigods> stevemar, makes sense
18:44:25 <notmorgan> but in either case, this is api incompatible change
18:44:32 <notmorgan> but i'm tired of harping on this point
18:44:32 <henrynash> notmorgan: I agree with you (but not everyone did at the time)
18:44:37 <amakarov> gyee: i18n for keys too! ftw ))
18:44:45 <bknudson_> are there proposals for new query arguments?
18:45:01 <bknudson_> how about document what should be done for new ones?
18:45:04 <notmorgan> going forward and new query argts we can be much more strict
18:45:06 <notmorgan> and we should be
18:45:07 <jamielennox> so we can't break backwards compat, future API should all use booleans
18:45:19 <notmorgan> jamielennox: yes.
18:45:32 <gyee> let me ask again, what is OpenStack API working group for?
18:45:33 <notmorgan> and we should be very explicit goring forward and very strict
18:45:47 <dstanek> jamielennox: what is the value of a boolean? 0/1, 'false'/'true'?
18:45:57 <rodrigods> dstanek, 0/1
18:46:17 <bknudson_> how about "maybe"?
18:46:26 <rodrigods> haha
18:46:29 <dstanek> 'roll dice'
18:46:33 <notmorgan> bknudson_: "sortof"
18:46:35 <jamielennox> dstanek: as dfeined by: https://github.com/openstack/oslo.utils/blob/master/oslo_utils/strutils.py#L111
18:46:44 <notmorgan> bknudson_: ?nocatalog=sortof
18:46:59 * notmorgan stops joking
18:47:05 <bknudson_> I'd be worried about using the library since they change the lib to add more and our API changes.
18:47:06 <amakarov> shreddinger_arg=0/1
18:47:10 <jamielennox> dstanek: not my favourite way to do it, but it's predefined
18:47:16 <notmorgan> true/false imo is the boolean i'd support
18:47:18 <jamielennox> 1/0 as what we would recomment
18:47:23 <jamielennox> recommend
18:47:32 <dstanek> jamielennox: is anything else false?
18:47:34 <notmorgan> but 1/0 is also fine.
18:47:50 <bknudson_> we should define what happens if the value is not one that's expected
18:47:55 <bknudson_> e.g., maybe 400
18:47:58 <dstanek> 1/0 would be my preference....certainly for the docs even if we support other values
18:48:03 <notmorgan> i'd look at http spec/jaascript/rfcs for general consistency
18:48:05 <dstanek> bknudson_: ++
18:48:10 <jamielennox> dstanek: you can strict=True
18:48:18 <henrynash> ok, so proposal is: 1) document how it works today (since I don’t think we really do that), and s2) omehow when you introce a new boolean define how it should work…which would be different exits booleans (yuk)
18:48:39 <amakarov> bknudson_: why not 'true/yes' is TRUE, and FALSE - everything else?
18:49:04 <dstanek> amakarov: i'd rather have a strict false value
18:49:08 <bknudson_> OpenStack seems to be moving towards being less lenient.
18:49:11 <lbragstad> dstanek ++
18:49:15 <notmorgan> be strict / explicit
18:49:26 <notmorgan> other web services tend to not be "true" or "yes"
18:49:32 <rodrigods> http://webmasters.stackexchange.com/questions/78512/how-to-fail-in-case-of-incorrect-uri-parameter
18:49:33 <notmorgan> they tend to expect a single "true" value
18:49:35 <notmorgan> if boolean
18:49:49 <stevemar> notmorgan: what if unspecified?
18:49:56 <dstanek> otherwise we'll get in a situation where we want 'yes', 'no' or 'it depends' and we'll be talking about backward compatibility again
18:50:08 <notmorgan> stevemar: most apps throwout/ignore invalid params unless they are filters
18:50:11 <notmorgan> iirc
18:50:43 <rodrigods> fallback to default values
18:50:56 <jamielennox> i don't like to ignore things you don't understand, always better to error
18:51:21 <stevemar> got a point
18:51:35 <bknudson_> we'll definitely need microversions if we don't ignore unexpected inputs
18:51:43 <amakarov> rodrigods: the question I see, what if client passes "param=yep" and expects it treated as true
18:51:49 <stevemar> yeah, can't start tossing up errors
18:52:10 <notmorgan> amakarov: just be clear going forward what is expected
18:52:15 <amakarov> I'm agree about ignoring
18:52:16 <rodrigods> notmorgan, ++
18:52:22 <notmorgan> amakarov: doesn't matter what the client does after that
18:52:38 <stevemar> henrynash: can you recap again, but include what happens if value is not present :)
18:52:46 <notmorgan> amakarov: if it doesn't conform ... it isn't valid
18:53:22 <samleon> stevemar, if value not there, it will be true
18:53:35 <henrynash> stevemar: so in today’s spec we have two different types of “booleans”…we weither say they are key-only (and no value is epcted) or “real” boolean
18:53:38 <amakarov> notmorgan: yes, the concern is: should we ignore the parameter of throw an error
18:53:50 <rodrigods> should *always* be key/value
18:53:51 <gyee> samleon, I wish that how we count votes in election day :-)
18:54:04 <rodrigods> imo
18:54:10 <notmorgan> amakarov: specify for new params the response.
18:54:13 <henrynash> if keyonly, then if it;s in there we say it is true, irrespective of value (if one was supplied0
18:54:14 <samleon> gyee++
18:54:18 <dstanek> amakarov: i would ingore unknows params, but 400 on know params with invalid values
18:54:30 <henrynash> if boolean, if value is ‘0’ it is false, anything else is true
18:54:41 <stevemar> dstanek: +++++
18:54:43 <amakarov> notmorgan, dstanek: why? :)
18:54:54 <dstanek> amakarov: why which part?
18:54:55 <notmorgan> amakarov: because it's the common behavior
18:55:04 <notmorgan> go to any webapp
18:55:10 <notmorgan> pass random query args
18:55:15 <dstanek> notmorgan: ++
18:55:17 <notmorgan> they are thrownout/mostly ignored
18:55:21 <amakarov> dstanek: I mean: do we have some measurables to say: yes - this approach is true
18:55:27 <stevemar> so let's live with the existing ones and document the behaviour that we want (ugh)
18:55:40 <henrynash> so one challenge is that if we intrioduce the “new improved boolean”, that operates different to the old boolenas, it might be pretty confusing
18:55:45 <stevemar> if we go forward with microversions, this'll be item #1 to fix :P
18:55:48 <bknudson_> we could add a microversion and bring the existing behavior up to spec.
18:55:55 <bknudson_> oops, behaviour
18:55:58 <dstanek> amakarov: we will define what values are acceptable for true/false
18:56:00 <notmorgan> bknudson_: ++
18:56:08 <stevemar> bknudson_: thanks for speaking canadian
18:56:37 <anteaya> eh?
18:56:38 <gyee> nice one
18:56:46 <stevemar> jamielennox: you have 3 minutes
18:56:50 <henrynash> stevemar: “document what we want”….you mean what we supprot today?
18:56:59 <jamielennox> oh, gah
18:57:25 <stevemar> henrynash: both, what we support today vs what we just agreed upon
18:57:34 <jamielennox> So quickly i proposed https://review.openstack.org/#/c/339356/
18:57:43 <stevemar> #topic Require auth_context middleware
18:57:58 <stevemar> i don't see the issue with depending on auth_context
18:57:59 <jamielennox> it would make auth_context required in the pipeline and remove the last of the places where keystone again validates a token
18:58:18 <gyee> jamielennox, ++
18:58:26 <jamielennox> looking around at how auth_context is used i think you would find a bunch of edge cases that fail if you don't have auth_context enabled today
18:58:50 <topol> jamielennox waiting for the downside
18:58:51 <gyee> does auth_context always need a token?
18:58:54 <gyee> it shouldn't
18:58:58 <stevemar> notmorgan: dolphm y'all are the history buffs here, any thoyghts?
18:59:04 <stevemar> or even thoughts
18:59:11 <jamielennox> so mostly it's an awareness thing, i want everone to know it's happening and a chance to stop it if you know anywhere we will have problems
18:59:23 <amakarov> jamielennox: according to the last phrase the solution looks like a workaround...
18:59:26 <bknudson_> I think you're saying that auth_context is actually required now?
18:59:27 <henrynash> I just raised the concern to make sure we’re not going to break any deployments
18:59:33 <gyee> jamielennox, make sure token is NOT required
18:59:46 <jamielennox> gyee: it would be enforced in @protected
18:59:52 <gyee> that's good
18:59:59 <jamielennox> so it will only be required in places where you are already going to do a policy check
19:00:04 <stevemar> let's just to -keystone to continue
19:00:07 <stevemar> #endmeeting