18:05:03 <henrynash> #startmeeting keystone
18:05:03 <openstack> Meeting started Tue Jan 12 18:05:03 2016 UTC and is due to finish in 60 minutes.  The chair is henrynash. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:05:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:05:07 <openstack> The meeting name has been set to 'keystone'
18:05:10 <bknudson_> hi
18:05:20 <shaleh> o/
18:05:39 <lbragstad> courtesy ping
18:05:39 <lbragstad> ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rodrigods, roxanaghe, samueldmq, shaleh, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub, rderose, samleon, xek, MaxPC, tjcocozz
18:05:55 <htruta> \o
18:06:08 <MaxPC> \o
18:06:12 <henrynash> Ok, let’s get started anyway….Steve can take over when he gets here
18:06:13 <rodrigods> hello
18:06:46 <henrynash> I’m sure he will have some comments on the midcyle, will let him raise those
18:06:59 <henrynash> #topic Bug 1490804: PKI Token Bypass
18:07:01 <openstack> bug 1490804 in OpenStack Security Advisory "PKI Token Revocation Bypass (CVE-2015-7546)" [Undecided,Confirmed] https://launchpad.net/bugs/1490804
18:07:05 <tjcocozz> Hello with this patch: https://bugs.launchpad.net/keystone/+bug/1490804  we were wondering if it was possible to backport the debate came to a draw and we were wondering if bknudson_ could be the tie breaker.
18:07:41 <henrynash> tjcocozz: maybejust summarize teh issue?
18:08:18 <tjcocozz> tbh i don't know the exact issue
18:08:54 <dolphm> tjcocozz: there are no -1's on the backports? have a link to the issue?
18:09:06 <bknudson_> we usually do allow backports for security fixes.
18:09:10 <tjcocozz> what is happening is that there is an extra key added to a dict.  I can get the log
18:09:31 <notmorgan> i am worried about the middleware change causing issues with people who have not gotten audit id responses in the rev list
18:09:38 <bknudson_> Some deployments might not like that listing revoked tokens is going to be slower (perhaps much slower)
18:09:45 <notmorgan> aka, an upgrade of middleware w/o the similar upgrade to keystone
18:10:07 <notmorgan> i didn't want to -1 but wanted to raise that as a real concern since it requires fixes on both sides.
18:10:08 <dstanek> i think line 247 here is the issue https://review.openstack.org/#/c/266022/2/keystone/token/persistence/backends/sql.py - adding new data to the response
18:10:08 <bknudson_> the code was written such that auth_token works with the old and new reponses
18:10:16 <notmorgan> ok. i was seeing failures.
18:10:22 <notmorgan> that was why i wanted to raise the concern
18:10:41 <bknudson_> oh, well that's broken then. I didn't see failures in my own testing... maybe I didn't do it right
18:10:55 <notmorgan> it might have been something else
18:11:14 <henrynash> notmoran, bknudson_: ok so the goal was for it to cope with both formats?
18:11:24 <notmorgan> also i expect folks to complain that we're breaking them because they will be doing something weird with the data in the revocation list
18:11:26 <bknudson_> yes, auth_token middleware should work with and without audit_id
18:11:35 <bknudson_> let me see if I can find the code.
18:11:42 <notmorgan> but i can't use that as a reason to block this.
18:11:45 <notmorgan> nor would it
18:12:12 <notmorgan> i just know touching token and revocation list data has historically netted us "OMG YOU BROKE US" because they expect specific datasets even in dicts
18:12:17 <notmorgan> non-python code consuming
18:12:45 <notmorgan> with master, i am less worried as it is an upgrade cost, stable push can sneak up on people depending on how they deploy
18:12:56 <bknudson_> https://review.openstack.org/#/c/265988/3/keystonemiddleware/auth_token/_revocations.py -- x['audit_id'] for x in revoked_tokens if 'audit_id' in x
18:13:17 <notmorgan> so, bknudson_ if you think it's a non-issue i'm fine with it
18:13:17 <henrynash> i’m kind of surprised for revocation lists that peopel process it that way, but hey, I’m ofetn surprised
18:13:21 <bknudson_> so if there's no audit_id in the revocation list entry you just get an empty list and it doesn't validate by audit id
18:13:32 <notmorgan> henrynash: people do silly things =/
18:14:42 <henrynash> Ok, so sounds to me like we are (tentively) ok to do this….I’ll run it by Steve since may have a view (I know he wante dit discussed here)
18:14:44 <gyee> adding fields in the token shouldn't cause trouble right?
18:14:53 <notmorgan> gyee: shouldn't but has in the past
18:15:20 <henrynash> #action Tentative Go for making Bug 1490804: PKI Token Bypass fix, stevemar to confirm
18:15:21 <openstack> bug 1490804 in OpenStack Security Advisory "PKI Token Revocation Bypass (CVE-2015-7546)" [Undecided,Confirmed] https://launchpad.net/bugs/1490804
18:15:53 <henrynash> #topic Bug 1527759: Revert domain ownership check
18:15:56 <openstack> bug 1527759 in OpenStack Identity (keystone) "Default domain no longer lets keystone tenant-list work" [Undecided,Fix released] https://launchpad.net/bugs/1527759 - Assigned to Morgan Fainberg (mdrnstm)
18:16:13 <henrynash> this is actually steve’s…anyone want to pick up on it, or I will defer
18:16:32 <henrynash> (well Steve put his name against it on the agenda)
18:16:41 <henrynash> notmorgan: comment?
18:16:45 <notmorgan> henrynash: hmm?
18:16:51 <henrynash> good comment
18:16:53 <notmorgan> the master fix landed
18:17:00 <notmorgan> the stable/* are pending
18:17:24 <notmorgan> from what steve told me the revert of non-default domain user/projects in v2 tokens was the root
18:18:11 * stevemar sneaks in
18:18:13 <stevemar> thanks notmorgan
18:19:29 <henrynash> notmorgan, stevemar: so not sure what the question in here…is it whether we should backport?
18:19:36 <stevemar> henrynash: yep
18:19:47 <stevemar> henrynash: notmorgan proposed the backport
18:19:57 <notmorgan> henrynash: we should backport it imo.
18:20:03 <stevemar> but gyee mentioned some sort of swift concern
18:20:04 <notmorgan> this broke real deployments.
18:20:14 <notmorgan> swift worked with the previous behavior
18:20:14 <stevemar> yeah, it broke at least 2 people
18:20:20 <henrynash> can’t really think why we would not….gyee?
18:20:20 <stevemar> i think it goes all the way to kilo
18:20:36 <gyee> swift ACLs allows names only
18:20:42 <notmorgan> and the fix for wift was "don't use v2 specific middleware with the ACLs"
18:20:49 <notmorgan> we can't keep this in tree
18:20:58 <notmorgan> the non-reverted setup that is
18:21:06 <notmorgan> because of the real world deployment breakage
18:21:36 <henrynash> ok, any objections to backport?
18:21:56 <gyee> no objection, so as long as people understand the implications
18:21:58 <stevemar> i think we need to reverse it
18:22:10 <stevemar> gyee: you propose we send an email out to the list?
18:22:20 <gyee> stevemar, yes, we should
18:22:29 <stevemar> gyee: you volunteering? :)
18:22:37 <gyee> stevemar, sure, OK
18:22:44 <stevemar> yay
18:22:45 <notmorgan> fwiw, this was a behavior swift coped with back before we "fixed" it
18:23:06 <notmorgan> the changes gyee is pointing to were documented in 2014
18:23:35 <notmorgan> just as a data point.
18:23:37 <gyee> hey, two wrongs make it right :-)
18:23:41 <henrynash> #action gyee to send email to list with implications of reversal detailed in https://bugs.launchpad.net/keystone/+bug/1527759
18:23:42 <openstack> Launchpad bug 1527759 in OpenStack Identity (keystone) "Default domain no longer lets keystone tenant-list work" [Undecided,Fix released] - Assigned to Morgan Fainberg (mdrnstm)
18:24:08 <henrynash> and we are backporting to L and K ?
18:24:19 <notmorgan> yes
18:24:25 <notmorgan> fixes are proposed
18:24:27 <stevemar> yeah, it was reported with kilo.2
18:24:37 <stevemar> we need someone to propose it to kilo https://review.openstack.org/#/q/I4a303a5fcc8c2dacef5960e9e26ad9402f34a790,n,z
18:24:41 <notmorgan> the other deployment broke with upgrade to liberty
18:24:49 <notmorgan> stevemar: there is a kilo fix proposed
18:24:56 <notmorgan> just gerrit ui is wonky
18:25:03 <henrynash> #action go ahead with Liberty and Kilo backports of https://bugs.launchpad.net/keystone/+bug/1527759
18:25:04 <openstack> Launchpad bug 1527759 in OpenStack Identity (keystone) "Default domain no longer lets keystone tenant-list work" [Undecided,Fix released] - Assigned to Morgan Fainberg (mdrnstm)
18:25:21 <notmorgan> https://review.openstack.org/#/c/265019/
18:25:26 <notmorgan> kilo fix ^
18:25:29 <notmorgan> #link https://review.openstack.org/#/c/265019/
18:25:31 <henrynash> excellent
18:25:44 <henrynash> ok moving on
18:25:49 <henrynash> #topic v2 deprecation/v3 support
18:25:51 <notmorgan> the search for the changeid doesn't work for some reasons...
18:26:05 <stevemar> notmorgan: link me?
18:26:05 <stevemar> oh i found it
18:26:18 <stevemar> yeah, same change id
18:26:20 <stevemar> thats weird
18:26:41 <henrynash> htruta, raldo: you’re up
18:26:48 <stevemar> stable maint folks, review: https://review.openstack.org/#/c/265019/ and https://review.openstack.org/#/c/265023/ :)
18:27:03 <htruta> so, raildo and I have been investigating what's left to do in Mitaka to maximize the amount of things that we can deprecate of improve v3 support
18:27:44 <htruta> and as talked yesterday with notmorgan and jamielennox, looks like the main services in general have good support
18:28:05 <samueldmq> yes, core services already support it
18:28:18 <bknudson_> do we have a gate where there's no v2?
18:28:21 <htruta> I wonder what else we can do at short-term, besides putting the patch stevemar mentioned in the agenda forward
18:28:26 <samueldmq> bknudson_: yes, in devstack as nonvoting
18:28:33 <htruta> samueldmq: ++
18:28:57 <stevemar> make it voting :)
18:29:04 <htruta> In liberty jamielennox said it was too soon to make v3 default in devstack
18:29:11 <stevemar> deprecate v2 calls, like the patch
18:29:15 <notmorgan> it should be doable in mitaka
18:29:18 <samueldmq> bknudson_: the idea is to propose it in tempest as well, and make it voting (cc mtreinish)
18:29:21 <notmorgan> default in devstack that is
18:29:32 <samueldmq> stevemar: yes taht's the idea, I can work on that with qa
18:29:34 <stevemar> start moving clients and other projects to v3 setups by default
18:29:42 <stevemar> and clients to keystoneauth
18:29:44 <htruta> notmorgan: I mean, using v3 in devstack when doing . openrc
18:29:50 <htruta> which is not what we currently have
18:30:07 <notmorgan> and we should have a gate (voting) job that ensures no v2 stuff is enabled/everything still works
18:30:15 <notmorgan> htruta: right, statement stands :)
18:30:45 <samueldmq> notmorgan: agreed, isn't v3 default in devstack already ? for roles and other entities, I remember jamie had a couple of patches which merged isn't v3 default in devstack already ? for roles and other entities, I remember jamie had a couple of patches which merged
18:30:50 <htruta> notmorgan: how so? I still had to export some env variables when created a v3 only devstack
18:30:52 <samueldmq> sorry for duplicate
18:31:15 <notmorgan> htruta: things that need to be fixed.
18:31:21 <notmorgan> but we should be able to do it
18:31:40 <notmorgan> most everything should "work".
18:31:41 <htruta> samueldmq, notmorgan: in that case, what do you mean by v3 by default?
18:31:55 <stevemar> htruta: samueldmq: you could start re-writing the the v2 keystone methods to call v3 functions
18:31:59 <henrynash> I really think we have to nail this for Mitaka….we can’t go another cycle with anything other than v3 being the defacto standard
18:32:00 <htruta> everything work, but in default, they use v2... that's my point
18:32:08 <notmorgan> htruta: sorry ensure that .openrc is only v3, that v2 can be disabled with no impact on stacking up/tempest [except v2 specific checks]
18:32:10 <stevemar> htruta: samueldmq make sure the clients are using keystoneauth
18:32:32 <notmorgan> clients using keystoneauth is a work in progress, but using ksc.session should be fine for this
18:32:44 <samueldmq> notmorgan: exactly
18:33:07 <htruta> stevemar: we're doing that
18:33:14 <gyee> off topic, where does devstack ppl usually hang out? #openstack-devstack?
18:33:14 <samueldmq> notmorgan: I think this is how devstack works with v2 completely disabled, usign sessions
18:33:24 <samueldmq> gyee: -qa
18:33:33 <henrynash> ok, so plan of action……1)  make v3 teh default - htruta, are you on that one
18:33:37 <gyee> samueldmq, thanks
18:33:43 <htruta> henrynash: sure
18:33:48 <samueldmq> gyee: devstack, tempest and grenade are under qa
18:34:00 <henrynash> 2) maek it gating I assume?
18:34:16 <gyee> looks like cinder is broker when USE_SSL is set to true
18:34:21 <gyee> I need to chase people down
18:34:26 <gyee> broken
18:34:36 <henrynash> do we need to disable v2 in that gating test?
18:34:46 <dolphm> htruta: get in touch with me before you "rewrite the v2 keystone methods to call v3 functions" - that's not quite how it should be done!
18:35:01 <raildo> gyee: I found similar error on trove
18:35:18 <notmorgan> samueldmq: i need to ask you a question post meeting re paste things
18:35:20 <htruta> henrynash: I don't think we need to disable v2
18:35:30 <notmorgan> stevemar: ^ uou too
18:35:36 <raildo> gyee: https://bugs.launchpad.net/trove/+bug/1293826
18:35:38 <samueldmq> notmorgan: sure sir
18:35:39 <openstack> Launchpad bug 1293826 in Trove "Trove doesn't work with Keystone that accepts HTTPS connections" [Low,In progress] - Assigned to Amrith (amrith)
18:35:45 <htruta> maybe making the v3 gate voting is enough for now
18:35:49 <htruta> dolphm: sure
18:36:44 <samueldmq> htruta: yes
18:36:54 <henrynash> htruta: OK,
18:36:56 <samueldmq> disabling v2 is the way we found to make sure everything is working with v3
18:36:57 <stevemar> and reviewing the patch to deprecate v2 API calls :)
18:37:00 <htruta> I also think that we can create extra tests in tempest, like using domain scoped tokens and projects in different domain than default tokens
18:37:09 <samueldmq> and not making mixed calls with v2 and v3 later
18:37:20 <stevemar> dolphm: thanks for knowing what i meant :)
18:37:36 <bknudson_> we could get a gate that uses ldap!
18:38:01 <stevemar> bknudson_: :O
18:38:05 <htruta> henrynash, samueldmq: I mean... we don't need to disable all v2 tests in devstack... but the v3 only gate totally disables v2, if that's what you mean
18:38:06 <stevemar> that would be good too!
18:38:06 <henrynash> bknudson_: oh, boy
18:38:31 <samueldmq> dolphm: should we make an adpter for v2->v3 controllers (as we have for versioned drivers) ?
18:38:36 <htruta> stevemar: btw, are you working on removing the resource ldap backend? :(
18:38:45 <henrynash> htruta: ok, that’s what i meant… our v3 gating test ensures v2 is off
18:39:34 <amrith> hello, did I miss something?
18:39:49 <samueldmq> :)
18:40:02 <henrynash> amrith: the answer to that question is always going to be yes
18:40:04 <stevemar> htruta: i keep getting sidetracked and it's a PITA to remove
18:40:11 <samueldmq> henrynash: ++
18:40:21 <samueldmq> henrynash: action point for this topic ?
18:40:43 <stevemar> henrynash: also, ayoung added something to the meeting agenda
18:40:52 <notmorgan> samueldmq: the v2 auth miht need to be maintained va an adapter
18:40:55 <amrith> sorry, I just saw irc blink and my name seems to be referenced with some bug. how can I help.
18:41:38 <henrynash> #action htruta to ensure v3 default is proposed along with gating v3 only tests
18:41:38 <notmorgan> bknudson_: heh i tried at one point ldap was so poorly supported....
18:42:05 <notmorgan> bknudson_: now thjat we don't have writable or assignment it would prob. be more doable
18:42:20 <henrynash> stevemar: ah , got ti
18:42:26 <htruta> an action to review https://review.openstack.org/#/c/251530/ too?
18:43:12 <henrynash> #action: cores to review https://review.openstack.org/#/c/251530/ as well, we’ve been working up t this for w ahile :-)
18:43:22 <henrynash> ok new topic
18:43:27 <htruta> henrynash: thanks
18:43:38 <henrynash> #topic Enforce token Bind based on Catalog
18:43:48 <henrynash> ayoung, gyee: you’re up
18:43:54 <gyee> do it!
18:44:05 <henrynash> gyee: succinct, as ever
18:44:15 <shaleh> :-)
18:44:45 <shaleh> henrynash: only on a terminal. In person he can really go for a while :-)
18:44:48 <henrynash> is this just a request for reviews…or are there some concerns we need to discuss here
18:45:11 <gyee> where's Craig Lee and others, they are using it to implement VOs, afaik
18:45:25 <gyee> and we are using it to control service activation and visibility
18:45:55 <bknudson_> we never implemented checking endpoint in service catalog in auth_token?
18:45:56 <gyee> so there are production use cases on endpoint filtering already
18:46:04 <notmorgan> -1
18:46:10 <notmorgan> we should never muck with the catalog
18:46:12 <gyee> bknudson_, there's a patch
18:46:19 <notmorgan> catalog should be as static as possible
18:46:33 <notmorgan> don't change the catalog based on user/project/etc
18:46:33 <gyee> normorgan, we had a session at Mitaka summit about it
18:46:35 <shaleh> are we really going to have this conversation again
18:46:39 <notmorgan> and i'm still -1 on it
18:46:55 <notmorgan> shaleh: yes.
18:46:58 <gyee> what's the point of advertising endpoints user have no access to?
18:47:16 <notmorgan> gyee: the catalog is about discovery of services. either use roles or a separate field.
18:47:20 <gyee> there are UX benefits as well
18:47:23 <notmorgan> don't actually change the catalog itself
18:47:43 <notmorgan> endpoint filtering should never have landed - i am sorry i let that through in hindsight
18:47:46 <dstanek> gyee: what's the point of Google indexing a page that you don't have access to?
18:47:48 <gyee> what are you going to do with endpoints you have no access to?
18:48:07 <dstanek> gyee: ask for access if you feel you need them
18:48:12 <shaleh> dstanek: how often do you find a google search result you cannot access?
18:48:16 <henrynash> notmorgan: I’d say that the catalog still as static as it’s every been, just that you don’t necessarily haev the rights to see it all
18:48:32 <notmorgan> henrynash: and i disagree with the need to mutate it
18:48:34 <dstanek> shaleh: all the time. lot's of news sites have pay walls
18:48:38 <notmorgan> based upon user/etc
18:48:40 <notmorgan> dstanek: ++
18:48:43 <henrynash> (ignore that we always had things like project_id substitutions in it!)
18:48:57 <notmorgan> henrynash: those are going away :) so i treat them as if they don't exist
18:49:07 <shaleh> I am not going through this again. You guys can argue the same points all over
18:49:11 <notmorgan> henrynash: [active work to solve that is landing in mitaka]
18:49:43 <gyee> we are doing the same thing with federation, filter service providers
18:49:52 <samueldmq> and we're also extending endpoint filter (for me in the wrong place) to serve as sp filtering
18:50:04 <notmorgan> samueldmq: i want to deprecate endpoint filtering
18:50:08 <notmorgan> samueldmq: to be honest
18:50:25 <henrynash> appreacite that others will have differning views, but I don;t send there is sufficent weight for blocking this, we are already down this path of a “filterable catalog”…this patch is just hardening an existing filter
18:50:31 <notmorgan> SP filtering != filtering catalog
18:50:32 <gyee> we are having double standards here
18:50:34 <notmorgan> erm endpoints
18:50:45 <marekd> notmorgan: ++
18:50:49 <gyee> endpoint filter have production use cases
18:51:05 <notmorgan> henrynash: i didn't -2 the change [yues i feel that strong] because i wanted to talk about it in the meeting
18:51:16 <henrynash> whcih we are!
18:51:28 <gyee> SP are identified by endpoints
18:51:28 <samueldmq> notmorgan: endpoints filtering != filtering catalog ?
18:51:29 <notmorgan> henrynash: but i still feel strong enough that this is something we should back away from
18:51:43 <marekd> gyee: what?
18:51:45 <notmorgan> samueldmq: endpoint/services shouldn't be filtered
18:52:05 <gyee> marekd, how do you access an SP?
18:52:07 <henrynash> comments from others….
18:52:10 <henrynash> ?
18:52:16 <notmorgan> the fact the SPs are in the catalog was conviencne and probably an incorrect choicce but we have to live with it.
18:52:25 <samueldmq> notmorgan: cool and in the case endpoint is too big ? should we make it globally available (catlog, as it won't change ?)
18:52:38 <notmorgan> samueldmq: "endpoint too big"?
18:52:45 <marekd> i have to reauth
18:52:48 <marekd> gyee: ^^
18:52:53 <samueldmq> notmorgan: catalog I meant
18:52:59 <gyee> service provider need to be able to control how they advertise their services
18:53:07 <gyee> they don't have to discuss all the services globally
18:53:10 <notmorgan> gyee: then add a different field.
18:53:11 <gyee> disclose
18:53:34 <notmorgan> gyee: the discovery part of the catalog should not change.
18:53:36 <notmorgan> at all
18:54:04 <notmorgan> i am not saying don't have enforcement i'm saying don't "change the catalog itself" the catalog shouldn't change based upon user/project/etc
18:54:04 <gyee> not sure what you mean by add another field
18:54:17 <gyee> how can I control what NOT to discover?
18:54:18 <bknudson_> we still have the templated catalog?
18:54:25 <notmorgan> bknudson_: sadly
18:54:31 <notmorgan> gyee: you don't get to.
18:54:42 <notmorgan> gyee: in my view that is a new keystone
18:55:07 <notmorgan> gyee: why are you "preventing" disclosure of endpoints?
18:55:15 <gyee> that's the whole point, we need to be able to control the services we are not advertising to the end users
18:55:28 <notmorgan> gyee: i don't buy it
18:55:29 <ayoung> so...that is not the same as binding the endpoint.
18:55:31 <notmorgan> give me a real usecase
18:55:48 <gyee> notmorgan, service activation
18:55:51 <ayoung> binding is saying the token can only be used on that endpoint...that is the part I want to nail down
18:55:52 <notmorgan> not a "we want x cause we have some thing we think we need" which is what i've gotten from this.
18:55:54 <gyee> region access
18:56:13 <notmorgan> gyee: don't see that as a real use
18:56:14 <gyee> don't tell me I have to create a role for each endpoints
18:56:15 <notmorgan> sorry
18:56:30 <notmorgan> endpoint bindging would be a good solution
18:56:47 <gyee> what is endpoint binding?
18:57:00 <henrynash> ok, coming up on teh end of our slot here
18:57:10 <ayoung> gyee, token must have endpoint in its catalog to be used on endpoint
18:57:14 <notmorgan> it's hooking into the work ayoung did to say you need KRB5 or such to work with an endpoint
18:57:23 <notmorgan> but i don't want us to do filtering on the catalog
18:57:26 <gyee> ayoung, that's endpoint filter
18:57:28 <ayoung> notmorgan, ah, binding to auth...
18:57:29 <notmorgan> make it explicit list not filtering
18:57:34 <ayoung> notmorgan, nah, that is dead
18:57:37 <ayoung> that was a PKI thing.
18:57:37 <gyee> that patch was the enforcement part of it
18:57:57 <notmorgan> well i stand by my -1. i am >< close to a -2 but obviously i'm in the minority here
18:58:04 <henrynash> notmorgan: does this proposed change make teh catalog any less static…are we not just enforcing something we already do?
18:58:04 <notmorgan> i very much think we're doing this wrong.
18:58:23 <notmorgan> henrynash: it is driving us down the "use endpoint filtering" path
18:58:29 <notmorgan> and we should remove that functionality
18:58:31 <ayoung> notmorgan, I think it is very right to say "I want a token with roles 1,2,3 for endpoint e1
18:58:32 <notmorgan> it is terrible.
18:58:49 <ayoung> filtering is related, but this is doable even without filtering
18:59:06 <ayoung> this is more "this token should only be used for Neutron"
18:59:09 <henrynash> I’m not disputing taht you have concerns over whether we should be doing filtering at all, just seems taht this change is completing work we arleady approved, releasd….which we can schose to retire in teh fiture if we havea better aternaitive
18:59:10 <gyee> ayoung, you ended up with a much compact catalog either way
18:59:15 <notmorgan> ayoung: if we are going down that path we should just make it a specific field added saying it
18:59:25 <ayoung> gyee, true, but side effect
18:59:27 <notmorgan> not change the catalog that is my complaint.
18:59:37 <gyee> we are not changing the format of it
18:59:38 <notmorgan> i don't want to see the catalog change between auths
18:59:47 <notmorgan> it's not the format it's the contant that shouldn't change
18:59:48 <gyee> we are controlling what to advertise
18:59:50 <ayoung> notmorgan, no change to the format.  It is only a change to the request
19:00:02 <henrynash> ok, sounds like we need to contoinue this discussion….probably set some tiem ot teh midcylce, stevmar?
19:00:03 <ayoung> what I request a token, I say "and only endpoint E"
19:00:04 <samueldmq> henrynash: time's over, infra time ?
19:00:05 <notmorgan> the catalog should not be different depending on scope
19:00:09 <henrynash> #endmeeting