Monday, 2014-07-21

*** gabriel-bezerra has quit IRC00:08
*** gabriel-bezerra has joined #openstack-keystone00:09
*** mitz has joined #openstack-keystone00:26
*** ncoghlan has joined #openstack-keystone00:50
*** xianghui has quit IRC01:07
*** ncoghlan is now known as ncoghlan_afk01:11
*** xianghui has joined #openstack-keystone01:12
*** ncoghlan_afk is now known as ncoghlan01:13
*** ayoung has joined #openstack-keystone01:23
ayoungjamielennox, can I run something by you?  It has to do with sessions, unscoped and scoped tokens.01:24
jamielennoxayoung: of course01:24
ayoungjamielennox, OK, so if we push for the rule that we can only go from unscoped to scoped tokes, would "scoping" down a token result in a new session, or would the session "remember" the last scoped token, and use that, except for getting a new, differently scoped token?01:25
ayoungI'm thinking one session, as the current Horizon approach is to revoke the old (scoped) session after rescoping01:26
jamielennoxayoung: so we have a 1 token per auth plugin policy, however the auth plugin can be specified at request time01:27
ayoungthe Password plugin creates the unscope token01:27
jamielennoxin the majority of cases for nova or someone they are only going to have one token and it's attached to the session01:27
ayoungthen you create a new Token plugin to use with that, and get scoped toke ns01:27
jamielennoxin the case of horizon or someone i'm expecting that they will never attach a token to the session and pass the auth plugin that they want to use around with each call.01:28
ayoungthen all work is done against nova using the scoped tokens...in the unified case01:28
ayoungheh, I am rewritng at that code...Horizon will do what we decide here01:28
jamielennoxright, for someone dealing with lots of different sessions i expect they will still have to do some token/auth plugin management01:29
jamielennoxit's possible i should never have allowed a session to have an auth plugin and that you should have always passed them around as different objects - that's kind of what the SDK is doing01:29
jamielennoxbut i don't know yet01:30
*** dims__ has joined #openstack-keystone01:30
ayoungso you would never want to hold on to the password plugin01:30
jamielennoxso yes, you will need to use a password plugin to get an unscoped token, then use the token plugin to scope it01:31
ayoungcuz you don't want to have the password hanging around01:31
jamielennoxayoung: i expect you would have to as it's the only way you can extend the session time01:31
ayoungMy thought:  Horizon will persist the scoped token to the session verbatim01:31
jamielennoxyou can't exchange a token for a longer scoped token at the moment01:31
ayoungand the unscoped tokens will be stuck in memcache, with a hash in the session cookie01:31
ayoungHorizon will persist the scoped token to the session *cookie* verbatim01:32
jamielennoxand in general we are wanting people to stop exchanging a scoped token for a different scoped token so you need to keep the unscoped around01:32
ayoungso I have a BP for the "extend the session" part01:32
jamielennoxyea, i hadn't realized it got discussed a fair bit at the mid-cycle01:32
jamielennoxmorganfainberg_Z and i were talking about it the other day01:33
*** gabriel-bezerra has quit IRC01:33
ayoungnot that much...but I've been heads down working it over01:33
ayoungSo,  one session with multiple tokens? One unscoped, stored for future use, one scoped?01:33
*** gabriel-bezerra has joined #openstack-keystone01:34
jamielennoxayoung: i would just not store the auth on the session at all01:35
jamielennoxyou can pass auth as a param to request: https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/session.py#n17201:35
jamielennoxi honestly am not sure how practical that is though01:35
jamielennoxbecause the managers code is crap and you can't always pass things down from users.list(auth=auth)01:36
jamielennoxthat was how i was *hoping* it would work01:37
ayoungSo...remove the auth plugin from the session after we have a scoped token, and stick the unscoped token back in the session, to be passed back in when we need to list projects and rescope?01:37
jamielennoxwhy stick it back?01:37
jamielennoxoh, hack around not being able to pass auth01:37
jamielennoxit might be your only option unfortunately01:37
jamielennox(passing this is exactly the point of https://review.openstack.org/#/c/106658/ )01:38
ayounghe...stick the unscoped token in the session cookie01:40
ayoungjamielennox, so the user will only ever have one session, right?01:45
ayoungin the CLI case, I guess we would take the unscoped token, stick in python keyring?01:46
jamielennoxi would think so01:46
jamielennoxin the case of horizon i think horizon would probably only have one session01:46
ayoungI think I want to leave the unscoped in the keystoneclient session.  It lets keystoneclient manage extending the life of the unscoped token01:47
jamielennoxthe only reason i can think of for people to have multiple sessions is for different client certs - and that's just because i don't have a way to have that handled by the auth plugin yet01:48
jamielennoxayoung: it won't automatically extend - only if it is used, so it doesn't matter about leaving it there01:48
ayoungyeah, one session.  THe other reason I could see to have multiple would be to copy a resource from one project to another, but download upload to do that is kindof dumb and expensive01:49
ayoungyup01:49
*** renlt has joined #openstack-keystone01:49
jamielennoxnot sure what you mean there01:50
jamielennoxbut anyway horizon should be a big winner of this because all horizon communications should go down the same keep-alive connections01:50
*** diegows has quit IRC01:51
*** mberlin has quit IRC01:51
*** mberlin1 has joined #openstack-keystone01:51
ayoungjamielennox, if you needed to move an image from one project to another in glance, there is no way to do that now.  No multip-project tokens.01:55
jamielennoxayoung: oh, right - yea i've got nothing that can help that01:55
jamielennoxayoung: is there any raw SAML support in IPA?01:58
ayoungnah...simo is doing that with Ipsilon01:58
jamielennoxayoung: yea, i figured that out after a lot of wasted time01:58
jamielennoxjust making sure01:58
ayoungsorry01:58
jamielennoxalso realized just how rare SAML ECP is01:58
jamielennoxi don't mind the kerberos everthing approach of IPA but i was going for a basic federation setup and there really isn't one02:00
ayoungNope02:00
ayoungwe are going to have the first with mod_lookup_identiy02:00
jamielennoxbut you can't do that without being an ipa-client right?02:01
ayoungactually, yeah, you could02:01
ayoungit would just be sssd LDAP in that case02:01
jamielennoxwith a kerberos ticket?02:02
ayoungyou could do it with a different login mechanism02:04
ayoungeven Basic_Auth would work02:05
*** ncoghlan is now known as ncoghlan_afk02:09
*** renlt has quit IRC02:11
jamielennoxayoung: do you remember what you needed for SSSD that didn't work at the time with mod_identity_lookup? http://adam.younglogic.com/2014/05/mod_lookup_identity/02:13
*** ncoghlan_afk is now known as ncoghlan02:43
*** dims__ has quit IRC03:09
*** dims__ has joined #openstack-keystone03:35
*** dims__ has quit IRC03:40
ayoungjamielennox, the big thing I needed was https://review.openstack.org/#/c/107873/04:00
*** ayoung is now known as ayoung_ZZZzzz04:00
*** dims__ has joined #openstack-keystone04:36
*** dims__ has quit IRC04:40
*** chandankumar has joined #openstack-keystone04:50
*** ajayaa has joined #openstack-keystone05:11
*** chandankumar has quit IRC05:12
*** shausy has joined #openstack-keystone05:22
*** stevemar has quit IRC05:29
*** dims__ has joined #openstack-keystone05:37
*** dims__ has quit IRC05:42
*** ayoung_ZZZzzz has quit IRC05:44
*** ayoung_ZZZzzz has joined #openstack-keystone05:53
*** ukalifon1 has joined #openstack-keystone06:14
*** k4n0 has joined #openstack-keystone06:16
*** ukalifon1 has quit IRC06:19
*** gabriel-bezerra has quit IRC06:23
*** afazekas has joined #openstack-keystone06:34
*** chandankumar has joined #openstack-keystone06:34
*** dims__ has joined #openstack-keystone06:37
*** gabriel-bezerra has joined #openstack-keystone06:39
*** dims__ has quit IRC06:42
*** tomoiaga has joined #openstack-keystone07:17
*** chandankumar has quit IRC07:33
*** jamielennox is now known as jamielennox|away07:36
*** dims__ has joined #openstack-keystone07:38
*** dims__ has quit IRC07:43
ajayaadolphm: How do I add a  configuration options in unit tests for keystone? for e.g. I want to add an option cache_time in group catalog.07:47
*** atallguyfriend has joined #openstack-keystone07:51
*** gabriel-bezerra has quit IRC07:51
*** atallguyfriend has left #openstack-keystone07:51
*** gabriel-bezerra has joined #openstack-keystone07:52
*** gabriel-bezerra has joined #openstack-keystone07:55
*** gabriel-bezerra has joined #openstack-keystone07:57
*** gabriel-bezerra has joined #openstack-keystone07:58
*** gabriel-bezerra has joined #openstack-keystone08:01
*** gabriel-bezerra has joined #openstack-keystone08:03
*** bvandenh has joined #openstack-keystone08:11
*** ajayaa has quit IRC08:19
*** ajayaa has joined #openstack-keystone08:31
*** chandankumar has joined #openstack-keystone08:32
*** dims__ has joined #openstack-keystone08:39
*** shausy has quit IRC08:39
*** ncoghlan has quit IRC08:39
*** ajayaa has quit IRC08:41
*** shausy has joined #openstack-keystone08:41
*** BAKfr has joined #openstack-keystone08:43
*** dims__ has quit IRC08:43
*** shausy has quit IRC08:51
*** ajayaa has joined #openstack-keystone08:54
*** kwss has joined #openstack-keystone09:14
*** Dafna has joined #openstack-keystone09:16
*** gabriel-bezerra has quit IRC09:19
*** gabriel-bezerra has joined #openstack-keystone09:19
*** afazekas has quit IRC09:23
*** afazekas has joined #openstack-keystone09:35
*** chandankumar has quit IRC09:46
*** afazekas has quit IRC10:00
*** ajayaa has quit IRC10:09
*** chandankumar has joined #openstack-keystone10:10
*** chandankumar has quit IRC10:11
*** chandankumar has joined #openstack-keystone10:11
*** afazekas has joined #openstack-keystone10:13
*** ajayaa has joined #openstack-keystone10:21
*** ajayaa has quit IRC10:32
*** dims__ has joined #openstack-keystone10:40
*** dims__ has quit IRC10:45
*** ajayaa has joined #openstack-keystone10:48
*** ajayaa has quit IRC10:58
*** ajayaa has joined #openstack-keystone11:10
*** ajayaa has quit IRC11:19
*** ajayaa has joined #openstack-keystone11:32
*** diegows has joined #openstack-keystone11:39
*** dims__ has joined #openstack-keystone11:41
*** RockKuo_Office has quit IRC11:42
*** dims__ has quit IRC11:46
*** dims__ has joined #openstack-keystone11:50
*** andreaf has joined #openstack-keystone12:04
*** rodrigods has joined #openstack-keystone12:18
*** rodrigods has joined #openstack-keystone12:18
*** hrybacki has joined #openstack-keystone12:20
*** k4n0 has quit IRC12:28
*** joesavak has joined #openstack-keystone12:40
*** gabriel-bezerra has quit IRC12:40
*** radez_g0n3 is now known as radez12:40
*** gabriel-bezerra has joined #openstack-keystone12:40
*** ajayaa has quit IRC12:49
*** dims__ has quit IRC12:50
*** dims__ has joined #openstack-keystone12:50
*** gabriel-bezerra has quit IRC12:50
*** gabriel-bezerra has joined #openstack-keystone12:51
*** stevemar has joined #openstack-keystone12:54
marekdwhat is the deadline for approving specs for J ?12:55
*** topol has joined #openstack-keystone13:05
*** dims has joined #openstack-keystone13:08
*** ayoung_ZZZzzz is now known as ayoung13:08
*** dims__ has quit IRC13:09
*** lbragstad has joined #openstack-keystone13:09
*** nkinder has quit IRC13:16
*** gabriel-bezerra has quit IRC13:16
*** gabriel-bezerra has joined #openstack-keystone13:16
*** bknudson has joined #openstack-keystone13:17
*** topol has quit IRC13:26
*** diegows has quit IRC13:28
marekddolphm: ^^ ?13:37
*** diegows has joined #openstack-keystone13:40
*** dhellmann is now known as dhellmann_13:41
*** richm has joined #openstack-keystone13:55
dolphmmarekd: according to https://wiki.openstack.org/wiki/SpecApprovalDeadline it would be this week13:55
*** richm has left #openstack-keystone13:55
marekdfriday, right?13:57
marekddolphm: and specs proposing changes to the API are still landable, right?13:58
dolphmlbragstad: flake8 violation on https://review.openstack.org/#/c/86483/ - which is breaking the whole series. can you apply the fix and get them back up?14:00
dolphmmarekd: yes14:00
marekddolphm: thanks.14:00
marekddolphm: well, yes was an answer to my question about friday or changing API ?14:00
dolphmmarekd: regarding friday, we never really picked a day. technically it'd be more like wednesday :-/14:00
lbragstaddolphm: yep, I can14:01
marekddolphm: ack14:01
dolphmlbragstad: i'm guessing that patch passed flake8 before we merged the i18n module last week14:01
lbragstaddolphm: ahh... yep, that's right14:05
*** nkinder has joined #openstack-keystone14:10
*** KimJ has joined #openstack-keystone14:14
lbragstaddolphm: what do you think about dstanek's comment here: https://review.openstack.org/#/c/86483/23/keystone/common/validation/parameter_types.py14:15
lbragstadthe internationalization one?14:15
dolphmlbragstad: oh yeah, that pattern won't fly14:15
lbragstadyeah, I didn't think about that until dstanek said something14:16
dolphmlbragstad: i can't think of what we can reasonably validate on name beyond length14:17
lbragstaddolphm: so, just check that it is a string and it's not longer than 25514:17
dolphmlbragstad: what's with the boolean schema? (why is it allowed to be a string?)14:17
dolphmlbragstad: minLength of 1 works too14:17
lbragstaddolphm: that was something that I saw in the nova v3 api validation.14:18
lbragstadwe can make that more strict though14:18
lbragstadby removing 'True', 'TRUE', 'true', and '1', saying use a real boolean value14:19
lbragstadand only accepting True14:19
dolphmlbragstad: yeah, just require a real boolean14:19
lbragstadok14:19
dolphmlbragstad: we used to have really badly written clients, hence strings-as-booleans, but that predates v314:20
lbragstadok, so moving away from that then14:20
*** kwss has quit IRC14:23
*** lbragstad has quit IRC14:26
*** erecio has joined #openstack-keystone14:26
*** lbragstad has joined #openstack-keystone14:28
*** dhellmann_ is now known as dhellmann14:30
*** rwsu has joined #openstack-keystone14:32
*** gabriel-bezerra has quit IRC14:39
*** gabriel-bezerra has joined #openstack-keystone14:41
*** lbragstad has quit IRC14:47
*** thedodd has joined #openstack-keystone14:49
*** doddstack has joined #openstack-keystone14:52
*** topol has joined #openstack-keystone14:53
*** thedodd has quit IRC14:54
*** morganfainberg_Z is now known as morganfainberg14:56
*** lbragstad has joined #openstack-keystone14:59
hrybackiayoung: do you have time today to discuss your comments on https://review.openstack.org/#/c/105031/4/keystonemiddleware/auth_token.py ?15:00
*** chandankumar has quit IRC15:00
*** openstackgerrit has joined #openstack-keystone15:02
ayoung yeah15:06
ayounghrybacki, looking at your responses now...15:06
*** richm has joined #openstack-keystone15:07
ayounghrybacki, OK, we have a need for V3.0 everywhere.  I don't think that doing sessions without V3 support is viable, even just for authenticating tokens.  UserID does not require Domain in order to get a token with V315:08
*** david-lyle has joined #openstack-keystone15:08
hrybackiayoung: okay -- so that means a majority re-write of that code, yes?15:09
*** gabriel-bezerra has quit IRC15:09
ayounghrybacki,  I'd be OK with dropping the requirement to push the changes to the client, so long as all the Url building was confined to its own class15:09
*** tomoiaga has quit IRC15:10
ayoung_http request, _json_request ...15:10
*** gabriel-bezerra has joined #openstack-keystone15:10
ayoung path = '/v2.0/tokens/%s' % user_token15:10
ayoung'/v2.0/tokens/revoked',15:10
hrybackiyeah, I'15:11
ayoungyeah...big rewrite to do everything right....OK,  lets leave that for now, and just encapsulate the URL construction15:11
hrybackiwant to understand why you want that stuff pulled out15:11
ayoung embedded string handling is a major smell of bad code15:12
hrybackioaky15:12
ayoung self._http_request('GET',   has an cleaner analog in the requests library15:12
ayoungI understand why it was written that way at first.15:12
ayoungWe really should have cleaned this up before splitting middleware into its own repo.  Its braindead that python build tools force that.  This kind of refactoring should be second nature, and we force it into a major undertaking15:13
ayounghrybacki, hmmm, so the question is how far to take this patch?  I guess the rule of thumb is "make nothing V2.0 specific."15:15
hrybackinot to sound thick but I'm not sure exactly what you are wanting me to do here15:15
*** gyee has joined #openstack-keystone15:20
ayounghrybacki, I'm willing to punt on "move everything to client"  to another patch.  THis patch should just make sure everything works with both v2 and v3 of the API.15:21
hrybackiokay and as it stands it only works with v2, yes?15:21
dstanekdolphm, lbragstad: just catching up - i think we still accept ints for at least some of the boolean values15:21
ayoungideally, you would  encapsulate the URL building as part of that so that we can move the code over to the client in a single patch.15:22
dstanekayoung: URL building in the client?15:22
dolphmdstanek: oh that's true i think15:22
hrybackiayoung: hmmm okay15:22
ayoungdstanek, URL building in auth_token middleware15:22
ayoungdstanek, https://review.openstack.org/#/c/105031/4/keystonemiddleware/auth_token.py15:23
dstanekdolphm, lbragstad: yeah, disabled uses this http://git.openstack.org/cgit/openstack/keystone/tree/keystone/clean.py#n4715:24
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Extracting get group roles for project logic to drivers.  https://review.openstack.org/8602515:24
dstanekayoung: i violently agree with your comment.15:25
bknudsononce we get JSON-Home support then we won't have to build URLs15:25
bknudsonquery the JSON-Home document for the rel you need and it gives you the URL15:25
bknudsonthen just need to do any replacements if it's a template15:26
morganfainbergdstanek, violent agreement eh?15:28
hrybackidstanek: to which comment specifically?15:28
*** cjellick has joined #openstack-keystone15:30
dstanekhrybacki: about not composing the URL15:30
dstanekhrybacki: mucking with the URL (beyond URL templates) is an indicator that the API is not a REST API15:30
hrybackihmm-m-m15:30
openstackgerritDavid Stanek proposed a change to openstack/keystone: Regenerate sample config file  https://review.openstack.org/10840515:31
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixed tox cover environment to share venv  https://review.openstack.org/10840615:31
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds coverage report to py33 test runs  https://review.openstack.org/10840715:31
hrybackiSo when ayoung says refactor that by encapsulating URL building what does he mean? I want to code it. I'm just not sure what it is yet15:31
*** cjellick has quit IRC15:35
*** cjellick has joined #openstack-keystone15:35
*** cjellick has quit IRC15:36
ayounghrybacki, create a helper class,  lets call it the client_bridge until we come up with a better name.  Anything that is V2 or V3 specific goes into a subclass of client_bridge15:37
hrybackiThere is a lot of hardcoded paths throughout auth_token15:37
*** gabriel-bezerra has quit IRC15:37
*** cjellick has joined #openstack-keystone15:37
hrybackiokay15:37
*** gabriel-bezerra has joined #openstack-keystone15:37
ayoungits probably not a full blown bridge design pattern, but the client kindof plays that role...15:38
ayounghttp://en.wikipedia.org/wiki/Bridge_pattern15:38
ayounghrybacki, in this diagram  the   V2 vs V3  stuff is the abstractions.    http://en.wikipedia.org/wiki/Bridge_pattern#Structure15:39
ayounglet me say that better15:39
ayoung _verify_uuid_token  is the  abstraction15:40
*** henrynash has joined #openstack-keystone15:40
ayoungthe refined abstraction will be the code that calls  the v2 vs v3 version of the API15:40
* hrybacki nods15:41
henrynashayoung: keen to get the specs for endpint by policy ID as well as explict request for unscoped token agreed…can I help with those?15:42
ayoungYES YES YES.  Er  Ahem.  Ok henrynash15:42
henrynashayoung: do you want me to take one of them?  if so, let me know your preference15:43
ayounghenrynash,  unscoped token is my priority15:43
*** erecio has quit IRC15:43
ayoungwhich is your?15:43
henrynashayoung: probably both….but if you want to push that one, I’ll grab the policy by endpint ID one15:44
ayounghenrynash, I am going to be working on the unscoped stuff.  If you help keep that moving, I'll help keep the endpoint policy moving.  Deal?15:45
henrynashayound: deal!15:45
*** afazekas has quit IRC15:47
*** Guest32427 is now known as mfisch15:54
*** shakamunyi has joined #openstack-keystone15:54
*** doddstack has quit IRC15:54
*** mfisch is now known as Guest6083115:54
ayounghenrynash, any deep thoughts on how to assign policy?   Is the first step just "global"  and "specific to this endpoint" or is there going to be any grouping in between?  I was thinking Regions, but an endpoint might not be restricted to a single region.  Endpoing groups don't work for the same reason15:56
henrynashayoung: I need to go away and think about it tonight….but I do think that first is global or specific endpoint….but region is tempting….15:57
henrynashayoung: btw, related but seperate…whats the proposed change that makes endpoint filtering checked at API executipon tme…is that token binding?15:59
ayounghenrynash, token endpoint binding, not to be confused with binding the token to a specific auth mechanism.  The latter actually was implemented a while ago by jamiec16:00
ayounger jamielennox|away16:00
*** Guest60831 has quit IRC16:01
henrynashayoung: is there a bp /spec for token endpoint binding?16:01
ayounghenrynash, mmmmaybe?  It looks like dolphm did a blueprint cleanout and I'll have to see if it was one of the ones he nacked16:01
ayoungactually, maybe he didn't...might have been a transient view thing that made it look like they were gone...lookin16:02
ayounghenrynash, https://blueprints.launchpad.net/keystone/+spec/endpoint-scoped-tokens16:03
*** gabriel-bezerra has quit IRC16:03
ayoungjust that, I think16:03
henrynashayoung: ok, thanks16:03
*** gabriel-bezerra has joined #openstack-keystone16:03
dstanekthis would go much faster it the tests didn't take forever!16:05
*** chandankumar has joined #openstack-keystone16:07
*** thedodd has joined #openstack-keystone16:09
dolphmlbragstad: p.s. ping me when you have a patch up on https://review.openstack.org/#/c/86483/ - i want to get that moving ASAP16:09
dolphmhenrynash: ooh, this too =) https://review.openstack.org/#/c/106893/16:10
dolphmhenrynash: replaced all the self.v3_request(method='GET', ...) with self.get(...)16:10
lbragstaddolphm: will do.. about to push a new version16:10
henrynashdolphm: ok, looking now16:10
dolphmhenrynash: which was an artifact of me debugging :(16:10
lbragstaddolphm: looking into the one comment you had on more specific error messages with json schema...16:10
lbragstadchecking jsonschema Exception object16:11
dolphmlbragstad: that's just a nice to have in the long run; don't need to pursue it right now16:11
*** gabriel-bezerra has quit IRC16:11
lbragstaddolphm: ok, new patch on the way16:12
*** gabriel-bezerra has joined #openstack-keystone16:12
hrybackiayoung: just to verify -- you are wanting middleware authtoken to use the client_bridge to call on functions such as _verify_uuid_token from keystoneclient authtoken. Or.. are you saying you just want parts of those functions to to use the client_bridge?16:12
ayounghrybacki, I'll let you write the code with my guidance, and see what you come up with.  I don't want to micromanage this, just keep an eye to encapsulation and refactoring.16:13
openstackgerritLance Bragstad proposed a change to openstack/keystone: Initial implementation of validator  https://review.openstack.org/8648316:13
*** jvrbanac has joined #openstack-keystone16:13
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Policy V3 API  https://review.openstack.org/10406516:13
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Catalog V3 resources  https://review.openstack.org/9626616:13
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Assignment V3 resources  https://review.openstack.org/8648416:13
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Trust V3 API  https://review.openstack.org/10406616:13
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Credential V3  https://review.openstack.org/9852216:13
hrybackiokay16:13
*** marcoemorais has joined #openstack-keystone16:14
henrynashdolphm: done16:15
morganfainbergdolphm, wanted to run this by you before i do the implementation (cc henrynash, dstanek) any issues with re-implementing (for the interim) the AccessInfo classes from keystoneclient in Keystone to provide the v2<->v3 token stuff? the ksc stuff has a bunch of "go ask keystone for this information" logic, and i think I want to work with jamielennox|away to develop the "right way" for both cases long term.16:15
morganfainbergit'll be pretty easy to convert once we update everything, but, not sure i want to update ksc to update keystone and not run into issues on one side or the other blocking non-persistent tokens16:16
*** fish_ has joined #openstack-keystone16:16
fish_hi16:16
morganfainbergtalked with ayoung about that last week and it seemed to be the most sane approach.16:16
ayoungmorganfainberg, ++16:17
fish_quick question: i'm working on a docker container to run keystone and was wondering: is it save to run db_sync on every start?16:17
*** joesavak has quit IRC16:19
morganfainbergfish_, in an ideal world db_sync is a no-op if the db schema is up to date16:19
*** gabriel-bezerra has quit IRC16:19
morganfainbergfish_, i always err on the side of don't do db_sync unless you *really* mean it and intend it16:19
*** chandankumar has quit IRC16:19
morganfainbergfish_, so i wouldn't do it on every startup (if you had different versions of keystone startup and reference the same DB you could break the db / keystone)16:20
ayoungfish_, would there be multiple Keystones pointing at the same DB?16:20
morganfainbergfish_, but there is nothing saying you *can't*16:20
ayoungYou wouldn't want to upgrade a db with Keystone running16:20
*** gabriel-bezerra has joined #openstack-keystone16:20
morganfainbergayoung, ++16:20
fish_ayoung: hrm good point16:21
ayoungfish_, unfortunately, I don't think we provide an easy way to say "is this database out of sync"16:21
ayoungideally we would have db_version and  something that says  db_versions_required16:21
ayoungI guess we should, too....16:21
dstanekmorganfainberg: what would happen with the implementation already in the client?16:21
morganfainbergdstanek, it does network calls to ask for information and tokens from keystone16:21
ayoungmorganfainberg, what happens if we run code against an out-of-sync db?  No real warning, just random failures,right?16:22
openstackgerritA change was merged to openstack/keystone: project disabled/deleted notification recommendations  https://review.openstack.org/10684516:22
openstackgerritA change was merged to openstack/keystone: Consolidate `assert_XXX_enabled` type calls to managers  https://review.openstack.org/10722016:22
fish_can I run db_sync on a differnt "system" (in that case docker container) than keystone-all?16:22
fish_it doesn't work just via the http api, that's what I got so far. but what does it actually need to access? I suppose the config and db..?16:22
morganfainbergayoung, you get a broken keystone, probably 500 ISEs because code will expect schema X and get result Y. SQLA gets picky about models also matching the schema16:23
dstanekmorganfainberg: sounds sane to me too16:23
lbragstaddolphm: all comments addressed on https://review.openstack.org/#/c/86483/ waiting on Jenkins16:23
morganfainbergfish_, as long as the migration scripts (and you know the version you want the db at) you can run db_sync from anywhere that can access the db16:23
morganfainbergfish_, but i would make sure keystone is turned off before updating the db :)16:23
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/10620816:24
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/10623216:24
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/10621016:28
henrynashdolphm: in https://review.openstack.org/#/c/106893/6/keystone/catalog/controllers.py did you mean to just have collection_name…as opposed to member_name (not that I think either will get used)16:30
*** chandankumar has joined #openstack-keystone16:33
fish_morganfainberg: / ayoung: thanks! got it now :)16:35
*** packet has joined #openstack-keystone16:37
ayoungdolphm, please remove the -2 https://review.openstack.org/#/c/107873/16:38
*** gabriel-bezerra has quit IRC16:38
*** hrybacki_ has joined #openstack-keystone16:39
*** chandankumar has quit IRC16:39
*** gabriel-bezerra has joined #openstack-keystone16:40
*** hrybacki has quit IRC16:43
*** gabriel-bezerra has quit IRC16:43
*** BAKfr has quit IRC16:43
*** hrybacki_ has quit IRC16:43
*** gabriel-bezerra has joined #openstack-keystone16:45
*** david-lyle has quit IRC16:46
*** gabriel-bezerra has quit IRC16:46
*** joesavak has joined #openstack-keystone16:48
*** erecio has joined #openstack-keystone16:49
*** david-lyle has joined #openstack-keystone16:52
*** gabriel-bezerra has joined #openstack-keystone16:52
*** chandankumar has joined #openstack-keystone16:53
*** gabriel-bezerra has quit IRC16:54
*** gabriel-bezerra has joined #openstack-keystone16:55
ayoungSo...I've set up Keystone to handback and endpoint URL of https://ayoungf20packstack.cloudlab.freeipa.org/keystone/admin  and this breaks everything;  all of the calls are coming through without /v3  even though they are via the v3 client.  I gues this means that once Keystone client gets back the endpoint url, it needs to do a GET of it to find  /versions, and store that value as the url?16:57
*** mfisch has joined #openstack-keystone16:57
*** mfisch has quit IRC16:57
*** mfisch has joined #openstack-keystone16:57
*** hrybacki has joined #openstack-keystone17:00
*** alex_xu has quit IRC17:01
ayoungbknudson, wouldn't it be much friendlier if we added Accept: application/openstack-identity-v3+json17:05
dstanekmorganfainberg: is there a reason that our manager are all singletons?17:05
ayoungdstanek, because singletons are abused17:05
ayoungdstanek, stricly speaking, you can't have a true singleton in Python.  People want to be able to resolve instances of classes by python namespacing17:06
ayoungdstanek, termie implemented that in his KSL rewrite17:06
dstanekayoung: you can have singletons, but it's not enforced the same way as Java - i'd rather not do that anyway17:07
ayoungdstanek, ++17:07
dstaneki have a series of patches that remove some of the singleton behavior as a way to get rid of the magic DI and move towards by-hand DI17:08
ayoungdstanek, I could argue, but it would be quibbling, and I agree with you on the "rather not"17:08
ayoungdstanek, I have been looking forward to this for a long time17:08
ayoungsince at least http://adam.younglogic.com/2012/03/di-python/  march of 201217:09
*** harlowja_away is now known as harlowja17:12
ayoungdstanek, it always seemed to me that we were having too many constructors that pulled magic parameters out of kwargs.  A cleaner approach would be to always have a context (dictoryary) and say d = DI.get_instance(which_instance, context)17:12
ayoungthat is what I was going with https://github.com/admiyo/python-resolver/17:12
ayoungwhere17:12
dstanekayoung: for me this all started with a test to port to snakeguice - right now i've just rewritten to accept all deps in the __init__17:13
ayoungdstanek, so what is your plan?17:14
dstanekright now17:14
dstaneki'm trying to make the deps more obvious17:14
ayoungdstanek, so the goal was to just be able to do, say Identity.manager() and the client would not have to know about any of the dependencies17:16
dstanekayoung: no, the goal was to use the real DI pattern where dependencies are passed in from the caller. this effectively make the caller create the dependency.17:17
dstanekfrom there a DI framework could actually help by hiding the boilerplate17:18
ayoungdstanek, that is a half way solution.  THe caller should not know about the deps, either17:18
ayoungthe caller needs to ask the framework for the object17:18
ayoungI *think* we are saying similar, but not identica; things17:19
dstanekayoung: yes, halfway. this is the first step of many17:19
ayoungdstanek, out, end state to me would look like this:  before "main"  all of the "components" get registered, each with a corresponding scope:  application, session, request.  A request time, compose a dictionary of values from the request, session variables, and application  variables.  Then all workflow uses that context to access instances of components.17:20
ayoungwe have, like, 90% of this built already, but the paste pipeline is, well, wrongly restrictive as well as  forcing you to declare things in a language that is not python that really should be declared in python17:21
dstanekayoung: i don't like the idea of a dictionary of stuff - why can't an object be passed an instance of credenial_api directly?17:23
ayoungdstanek, it is.  THe dictionary of stuff is for creating credential_api in the first place17:23
ayoungeach object has a hard interface in its constructor17:23
ayoungyou use the context to get the *right* instance17:23
ayoungso if there is already a credential_api object in the proper scope, fetch it out of the context17:24
dstanekthat's similar to SG - it uses a construct called scopes to manage some of that17:24
ayoungdstanek, I am sure.  I didn't invent any of this, just used it time and again in multiple frameworks17:24
dstanekayoung: if you have time take a look at the SG API tests to get a feel for how it works. i'd love the feedback17:25
ayoungalthough I am a little proud of my C++ impl, but mostly I've used and done this in Java17:25
ayoungdstanek, I know I looked at one point, let me look again.17:25
ayoungI hate the name, BTW17:25
dstanekthe snake or the guice?17:26
ayoungthe G comes from Google, and this it more baseline than that17:26
ayoungI think DI should be a base python utility, and the naming should reflect that17:26
dstanekit's a re-implementation of Guice17:26
ayoungand it implies that we are going to be using the same desing decisions of Guice, which I want the free reign to override17:27
dstanekayoung: like what?17:27
ayoungNo idea.17:27
ayoungI dpn17:28
ayoungI don't know Guice well enough17:28
ayoungbut I've seen enough bad DI that I don't want to be tied to someone elses mistakes.17:28
ayounghttp://stackoverflow.com/questions/2026016/google-guice-vs-picocontainer-for-dependency-injection  interesting...I liked pico back in the day17:29
ayoungI'd be more prone to name something after Pico than Guice.  Pico was really close to "done right"  as I recall.  It was written pre-generics, and thus was not as type safe as I would have liked,17:31
raildohenrynash: ping17:31
dstanekayoung: the naming is not arbitrary - i uses the basic design elements or Guice - modules, scope, etc.17:32
*** hrybacki has quit IRC17:32
ayoungdstanek, Java had annotations come along, which as I recall, Guice used, and I thought it was a bad design17:32
ayoungsetter injection is also a work around for lack of info in Java17:33
*** erecio has quit IRC17:33
ayoungactaully, until recently, Java couldn't do proper DI.17:33
ayounghttp://adam.younglogic.com/2014/05/parameter-names-in-java-8/17:33
ayoungNot guices fault17:33
ayoungdstanek, OK, let me lay out the requirements as I see them17:34
dstaneki'm pretty sure pico is also based on  annotations17:34
dstanekactually there is a JSR for it17:34
ayoungnope1: need to be able to pull in17:34
ayoungdstanek, nope, pico predated that17:34
ayoungyou used Java code to link them together17:34
ayoungthen Nano was built on Pico using XML17:34
ayoungthere might be a Pico binding to the annotations since I last looked, though17:35
ayoungwould not be surprised17:35
dstanekayoung: any language can do DI it's just a pattern for building objects17:35
ayoungannotations in Java are a grand mistake.17:35
*** afazekas has joined #openstack-keystone17:35
ayoungdstanek, heh,  I would argue that No language can actually do DI correctly.  C++ comes closest of the ones I've worked with.17:35
* ayoung is purist17:36
dstanekayoung: how do you define DI then?17:36
ayoungdstanek, Napolean Principal:  "he would hold out his hand and just expect a ribbon or medal to be placed in it"  basically, the end use asks for an instnace of a Class and gets the right one based on context.  Type safe, and distinguished between two identical Classes by additional context17:37
ayounglet me clarify17:37
ayoungsay I say " I need a Database connection"17:37
ayoungand there are two Database connections available17:37
ayoungI need to say either "give me the default one" or "give me the one that is for the reports Database"17:38
dstanekayoung: that is not how i understand DI - an object should not ask for dependencies (Factory pattern) it should be handed them during construction17:39
*** gabriel-bezerra has quit IRC17:39
ayoungEven if both Were instance of the class  "DatabaseConnection"  there is still "reports"  versus "orders"  or "idm"17:39
ayoungdstanek, it should register for dependencies before construction17:39
ayoung"objects"  don't ask for anything17:39
ayoungusers as for objects from the DI framework17:39
*** gabriel-bezerra has joined #openstack-keystone17:39
ayoungdstanek, let me try a concrete example17:39
ayounglets take our authenticate call17:40
ayoungit takes in a JSON object  with the Auth data.17:40
ayoungNow, this is obviously request scope17:40
ayoungd17:40
*** thedodd has quit IRC17:40
ayoungin order to validate it, we need to pull in first the set of auth plugins, and validate the authentication17:40
ayoungauth_plugins are application scoped17:41
ayoungsome would call them "stateless"17:41
ayoungsome auth plugins also need the Identity API17:41
dstanekbut the authenticate call should know of care about the scope of the objects it receives17:41
ayoungthe authenticate call starts the whole thing off17:41
dstanekit takes a dict and will get passed on by the caller17:41
ayoungso when it gets an request for the password auth plugin (assuming for now it has never been created) it creates one.  But the Password plugin needs the Identity API17:42
ayoungso the Identity API is created on demand, too17:42
ayoungthe ID API needs a driver17:42
ayoungand, with Henry's code, it now needs many drivers17:42
ayoungthese are instance of components, potentially identical in class name, but distinguished by IdPs17:43
ayoungNow, Keystone does not have Sessions.  It only has Tokens.17:43
ayoungWell, really, Tokens are Auth Context17:43
*** tziOm has quit IRC17:43
ayoungSo we need to recreate the Auth context on a call from the Token data....or potentially from other parameters in the future, if we want Tokenlesscalls17:44
*** tziOm has joined #openstack-keystone17:45
*** gabriel-bezerra has quit IRC17:45
*** shakamunyi_ has joined #openstack-keystone17:45
*** gabriel-bezerra has joined #openstack-keystone17:46
ayoungdstanek, the cool thing is that once you have all of the instances demand created, you can optimize by pre-creating the ones you need early on17:46
ayoungmight need to do that to avoid some threading issues, too17:46
*** shakamunyi has quit IRC17:49
ayoungdstanek, so lets start here: https://code.google.com/p/snake-guice/wiki/UsingProviders17:50
ayoung @provide(session=session_provider)17:50
ayoungthat is showing the lack of type safety in Python, and attempting to use annotations to work around it.  It is not DI17:51
*** vhoward has left #openstack-keystone17:51
ayoung    @inject(filename=Config('app.cfg:logger:filename'),17:51
ayoung            loglevel=Config('app.cfg:logger:loglevel'))17:51
morganfainbergdstanek, our managers are sort-of-singletons17:51
ayoungsee, now you are linking a class to the implementation.  Those two thing should be separated17:52
dstanekayoung: since Python doesn't have a standard way to label types - i used decorators to do that17:52
ayoungdstanek, a rule of thumb, the python code you are managing should be agnostic of the DI framework.  Only the start of the use case should know about it17:52
dstanekayoung: what class is being linked to the implementation?17:53
ayoungdstanek, that is fine.  Its just not DI17:53
ayoungfrom snakeguice import inject, Injected, Config17:53
ayoungclass MyLogger(object):17:53
ayoungMy logger should know nothing about snakeguice17:53
ayoungMyLogger is a class, and requires a filename and a loglevel17:54
ayoungfine,  make that one class17:54
dstanekayoung: that isn't really a big deal because the decorators can some from anywhere any be linked to SG17:54
ayoungthe registration of the component is external17:54
ayoungso  somewhere else:17:54
ayoungit should be17:54
dstanekayoung: Modules are how something is registered17:54
dstanekclasses using SG don't know what implementation they'll get. only that it conforms to an interface.17:55
ayoungdstanek, Then don't call it MyLogger,  call it RegisterMyLogger.  But I don't think that is what you are saying17:56
ayoungAnd Snakeguice should not be part of the interface definition either17:56
henrynashraildo: hi17:56
ayoungdstanek, look here:17:56
ayounghttps://github.com/admiyo/python-resolver/blob/master/test/resolver_test.py#L2317:56
ayoungnow, this is a single file for a test case, and I have not fully developed it, but17:57
dstanekthe SG decorators can be hidden from the class itself - it's just that there really isn't much point in doing that17:57
ayoungthis is the factory.  This creates a new instance.17:57
ayoungIt is nt what the end user calls17:57
ayoungthey call17:57
dstanekhttps://code.google.com/p/snake-guice/source/browse/tests/system/test_api.py#5817:58
ayoung op = res.resolve(SampleOp)17:58
raildohenrynash: I wonder if you got any doubt in the spec about hierarchical multitenancy and domains17:58
ayoungand then   op.operation(),17:58
*** thedodd has joined #openstack-keystone17:58
raildohenrynash: I answered you there, and do not know if you saw.17:58
henrynashraildo: let me look17:58
ayoung @inject(hero=ch.Person, villian=ch.Person, victim=ch.Person)17:58
ayoung        @annotate(hero='good', villian='evil')17:58
dstanekayoung: what if SampleOp needs depencencies?17:59
ayoungit gets them chained...17:59
raildohttps://review.openstack.org/#/c/101017/9/specs/juno/hierarchical_multitenancy.rst17:59
ayoungit would look like this17:59
morganfainbergayoung, so, let me get this straight, you instantiate a new provider per object that needs it injected?17:59
ayoungdstanek, actually it does already17:59
morganfainbergayoung, /me is catching up on the convo17:59
ayounghttps://github.com/admiyo/python-resolver/blob/master/test/resolver_test.py#L2917:59
henrynashraildo: so here was my last comment (that I don’t see answered):17:59
henrynashOK, so given that hierarchy, tell me again how Joe creates his users and Samantha creates hers? They HAVE to be in separate domains (that's the only place users can be created). So are each of project hierarchy below each of these two domains separate? In which case, it's unclear to me how the hierarchy is helping achieve the objectives outlined....sorry to sound like a broken record, but we need to explain an real example of how the propos18:00
henrynashchange actual solves the user cases identified.18:00
ayoungin this case sample_op depends on base18:00
ayoungdo_something is a bad name18:00
ayoungdstanek, lets start here https://github.com/admiyo/python-resolver/blob/master/test/resolver_test.py#L5618:01
ayoungoutside of the classes to be managed, we register 3 components18:01
*** marcoemorais has quit IRC18:01
*** erecio has joined #openstack-keystone18:01
ayoungthey use the baseclass name to indicate what they provide18:01
*** marcoemorais has joined #openstack-keystone18:01
ayoungresolver.register(SampleOp, do_something)18:01
*** marcoemorais has quit IRC18:02
ayoungfor the simple case, you could use a lambda18:02
openstackgerritA change was merged to openstack/keystone: Extracting get group roles for project logic to drivers.  https://review.openstack.org/8602518:02
*** marcoemorais has joined #openstack-keystone18:02
ayoungor possibly even just drop the second parameter and have a default that called the no-arg constructor18:02
*** joesavak has quit IRC18:02
raildohenrynash: Ok, I'll explain better the example, but the answer was clear, correct?18:02
ayoungSo A logger for logging to StandardOut, for example would not need to depend on anything else.18:03
ayoungthat could be18:03
*** nkinder has quit IRC18:03
ayoungresolver.register(StandardOutLogger)  but it would not be right, as that should really be registered against the Base Class18:03
dstanekayoung: doesn't this lead of factory explosion? it looks like you would have to create lots of factories18:03
ayoungso better to do18:04
ayoungresolver.register(Logger,    lambda (return StandardOutLogger()) )18:04
morganfainbergdstanek, ++18:04
*** afazekas has quit IRC18:04
ayoungdstanek, elliding the simple cases is pretty straight forward18:04
*** joesavak has joined #openstack-keystone18:04
henrynashraildo: well, actually, I don;t think we describe how projects and domains interact with each other in releation to the use cases we are describing18:04
morganfainbergayoung, so you'd be creating a new instance of StandardOutLogger on each dependency injected?18:05
dstanekayoung: let me come up with a quick example and you can show me how it would be implemented18:05
morganfainbergayoung, that uses logger18:05
henrynashraildo: as I have said before, most use cases you list seem to want hierachical domains not hierachical projects…so no, I’m not sold yet18:05
morganfainberghenrynash, i would say domains and projects should be the same thing18:06
morganfainberghenrynash, removing the distinction.18:06
henrynashmorganfainberg: I agree… and “domain-ness” should be an attribute of projects18:06
morganfainberghenrynash, ++ and that resolves the hierarchical domain vs project argument18:07
henrynashmorganfainberg: which probably only means an achor point at which you can create users18:07
morganfainberghenrynash, it wouldn't matter.18:07
henrynashmorganfainberg, raildo: …and my point is that this has to go into the spec…since otherwise, standalone, the spec does not deliver on the use cases18:08
morganfainberghenrynash, it could be at multiple anchor points. I'd just call a 'domain' (for sake of a full heirarchy tree) the anchor point below the 'root' object18:08
morganfainberghenrynash, not arguing that point. :)18:08
raildothis is a good solution,I agree that would solve the problem but this change seems a little expensive for Juno.18:08
morganfainberg(also domain being the top is just for compatibility)18:08
morganfainbergthe way i saw it is domain is just a way to maintain compatibility pre-hierarchy.18:09
henrynashmorganfainberg: (agree there could be multiple anchor points, and we require there has to be at least one in each hierachy, at the top)18:09
morganfainbergand the [root] object is the software "keystone" root allowing for a well defined entry point, any parentless projects are domains and are implicity the direct children of [root] (or [keystone], whatever)18:10
henrynashraildo: so if we don’t want to do that part of it for Juno, we need to state in the spec what the interaction is between domains and projects - e.g. I have a proejct hierachy…do they all have to be from the same domain?18:11
morganfainbergso .list_domains is simply a get me all prjects with no parent18:11
dstanekayoung: DI by hand https://gist.github.com/dstanek/bd4a642f694de01ef9a918:11
morganfainberghenrynash, oh projects can't have hiearchy and be in different domains. that would be awful.18:11
morganfainbergall relationships parent->child needs to be in the same domain,18:12
raildohenrynash:  should be created a hierarchical projects within each domain, this is the relationship between domains and h-m18:12
henrynashmorgainfainberg: so I agree…but if that cant happen AND we don;t want to “fix” domains in Juno, then teh spec can;t deliver on it use cases…18:12
morganfainbergit doens't make sense to have ProjecT(DOMAIN-X)->project(DOMAIN-Y)18:12
morganfainberghenrynash, ++18:12
morganfainbergso we "fix" domains.18:13
raildomorganfainberg: ++18:13
henrynashraildo: Ok (and here I go again)….so tell me how Joe and Samantha create their users while at the same time are part of the same project hierachy18:13
morganfainbergraildo, which is what you said was expensive for Juno18:13
*** amcrn has joined #openstack-keystone18:13
morganfainbergdstanek, ok so any dependency just becomes part of the constructor?18:14
morganfainbergdstanek, based on your by-hand example?18:14
*** nkinder has joined #openstack-keystone18:15
*** tellesnobrega has joined #openstack-keystone18:16
dstanekmorganfainberg: that's the simple way the view DI yes18:16
raildohenrynash: IMO, there is no difference between Joe and Sam users. Users are in the domain where they belong. Just like today, if I create a project for Sam and a profect for Joe will not have difference.18:17
morganfainbergdstanek, ok, yeah was looking over your SG implementation as well18:17
morganfainbergdstanek, makes sense to me.18:17
dstanekmorganfainberg: i've got a simple example with credentails that i'm working through now18:17
morganfainbergdstanek, cool.18:18
henrynashraildo: but they have to be in different domains….since you don’t want Joe deleting Samantha’s users (you say in the use case that both Joe and Samantha want to be able to create their own users)18:18
raildomorganfainberg: I think it's expensive make project and domain the same thing. They have many tests and methods that must be changed.18:20
openstackgerritSam Leong proposed a change to openstack/keystone: Disable a domain will revoke domain scoped tokens  https://review.openstack.org/10719418:20
henrynashraildo: and if they are in separte domains…and Joe’s & Samantha’s projects are in different domains…how is it that hierachy projects are helping Martha offer her services?18:20
henrynashraildo: this is my big disconnect…unless we change the domain construct, I don’t see how hierachial projects help18:21
raildohenrynash: No, what I mean is that Martha, (which act as a cloud admin) users can handle the two projects. Marta who is at a higher level, can control their hierarchy.18:22
henrynashbut she can do that today without a hieracy18:22
henrynashraildo: but she can do that today without a hierachy18:23
openstackgerritSam Leong proposed a change to openstack/keystone: Disable a domain will revoke domain scoped tokens  https://review.openstack.org/10719418:24
*** gabriel-bezerra has quit IRC18:25
openstackgerritSam Leong proposed a change to openstack/keystone: Disable a domain will revoke domain scoped tokens  https://review.openstack.org/10719418:25
openstackgerritSam Leong proposed a change to openstack/keystone: Disable a domain will revoke domain scoped tokens  https://review.openstack.org/10719418:26
*** gabriel-bezerra has joined #openstack-keystone18:26
raildohenrynash: yes she can, but there other advantages described (as hierarchical quotas, Sam and Joe subprojects) that currently do not have this support. I understand what you're thinking and I agree that we have to define it better. Just do not know if this impact is so great for a first release.18:27
*** harlowja has quit IRC18:27
*** thedodd has quit IRC18:28
henrynashraildo: so that’s fine…but we either have to describe the actual use cases we initially solve with hierachies if we don’t change domains (and this will be much less than currently implied), or we do change domains and cali the “full monty”18:30
henrynash..and claim the “ful monty"18:31
*** marcoemorais has quit IRC18:33
*** marcoemorais has joined #openstack-keystone18:33
openstackgerritA change was merged to openstack/keystone: Fixes a Python3 syntax error  https://review.openstack.org/10273418:34
*** hrybacki has joined #openstack-keystone18:35
*** harlowja has joined #openstack-keystone18:35
*** hrybacki_ has joined #openstack-keystone18:37
*** mgarza has joined #openstack-keystone18:38
*** diegows has quit IRC18:38
dstanekayoung: sg version starts on line 48 - https://gist.github.com/dstanek/94a4142a097c92cf900218:39
*** hrybacki has quit IRC18:40
ayoungdstanek, will look in a moment.  Elbows deep in the client right now18:40
raildohenrynash: OK,   i will try explain better the use case18:42
henrynashraildo: great18:42
*** marcoemorais has quit IRC18:48
*** marcoemorais has joined #openstack-keystone18:48
*** diegows has joined #openstack-keystone18:50
*** erecio has quit IRC18:52
*** chandankumar has quit IRC18:52
*** gabriel-bezerra has quit IRC18:52
*** chandankumar has joined #openstack-keystone18:53
*** gabriel-bezerra has joined #openstack-keystone18:54
ayoungdstanek, ah...client stuff is going to take way too long, OK let me take a look18:56
*** bklei has joined #openstack-keystone18:56
ayoungdstanek, so the *Module classes is where you are registering the factories?18:57
dstanekayoung: where is where you wire up the objects and say which concrete implementation should be used with an interface18:59
ayoungSo to get an instance of a FileLogger, I need to know that I have to call Injector(FileModule()).get_instance(DomainObject)19:00
dstanekso when the framework goes to create an object is looks at the types it expects and finds the concrete mapping19:00
ayoungHow would I say, without knowing that, give me a Logger?19:00
dstanekif you want a FileLogger you can say 'injector.get_instance(FileLogger)'19:01
dstanekin the given example DomainObject needs a logger - and the FileModule wires it up to use the FileLogger19:01
*** gabriel-bezerra has quit IRC19:01
dstanekthe idea of the injector is that it gives you the entire fulfilled dependency graph19:02
*** thedodd has joined #openstack-keystone19:02
*** gabriel-bezerra has joined #openstack-keystone19:02
*** henrynash has quit IRC19:04
openstackgerritguang-yee proposed a change to openstack/keystone-specs: X.509 SSL certificate authentication  https://review.openstack.org/10591319:08
*** afazekas has joined #openstack-keystone19:12
ayoungdstanek, looks right....19:18
*** afazekas has quit IRC19:21
*** nkinder has quit IRC19:37
*** jsavak has joined #openstack-keystone19:38
*** joesavak has quit IRC19:39
openstackgerritLance Bragstad proposed a change to openstack/keystone: Initial implementation of validator  https://review.openstack.org/8648319:46
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Policy V3 API  https://review.openstack.org/10406519:46
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Catalog V3 resources  https://review.openstack.org/9626619:46
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Assignment V3 resources  https://review.openstack.org/8648419:46
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Trust V3 API  https://review.openstack.org/10406619:46
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Credential V3  https://review.openstack.org/9852219:46
openstackgerritA change was merged to openstack/python-keystoneclient: Only conditionally import working keyring  https://review.openstack.org/10771919:49
openstackgerritA change was merged to openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/10623219:51
openstackgerritLance Bragstad proposed a change to openstack/keystone: Initial implementation of validator  https://review.openstack.org/8648319:56
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Policy V3 API  https://review.openstack.org/10406519:56
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Catalog V3 resources  https://review.openstack.org/9626619:56
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Assignment V3 resources  https://review.openstack.org/8648419:56
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Trust V3 API  https://review.openstack.org/10406619:56
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Credential V3  https://review.openstack.org/9852219:56
morganfainberglbragstad, spam! :)19:56
lbragstadmorganfainberg: WHOOP!19:56
*** chandankumar has quit IRC19:56
* lbragstad watches for flying nerf darts from dolphm19:56
morganfainbergyeah you gotta watchf ro that now, dontcha19:57
dolphmlbragstad: apparently gerrit sucks at unicode19:57
dstanekdolphm: everybody sucks at unicode!19:57
dolphmlbragstad: i actually had alphba-betta-gamma-delta in the unicode string here https://review.openstack.org/#/c/86483/27/keystone/tests/test_validation.py19:57
*** jsavak has quit IRC19:57
dolphmlbragstad: not just question marks, which is what it's showing up as now for me19:57
morganfainbergdolphm, that doesn't surprise me (re: gerrit and unicode)19:58
dolphmlbragstad: u'αβγδ'19:58
lbragstadah.. really?19:58
dolphmlbragstad: yeah - i wanted a test that would have failed against one of the earlier patchsets with the regex20:00
morganfainberghrybacki_, i think the scripts that generate those sample.jsons are in the same directory20:00
morganfainberghrybacki_, if you just pipe the output through | python -mjson.tool'20:00
hrybacki_morganfainberg: ++20:00
morganfainberghrybacki_, it should be good20:00
morganfainberg*should*20:00
dolphmlbragstad: also, i don't think your tests will run in py33, so i was hoping you'd add test_validation to tox.ini's py33 job and fix them :)20:00
hrybacki_morganfainberg: /me adds to his growing todo list20:01
morganfainberghrybacki_, we also need to wire up some tests for the output of those scripts, not sure if you want to take that on, e.g. "output files, and validate valid tokens come out the other end/ valid data / whatever"20:01
morganfainberghrybacki_, :)20:01
hrybacki_sure -- when/where is the generating script called? During setup of keystone/client/middleware?20:02
morganfainberghrybacki_, i think it's called out-of-band just whenever we want to do an update?20:02
morganfainberghrybacki_, as in.. we've run it a handful of times at best20:03
hrybacki_morganfainberg: ohhh. okay20:03
morganfainberghrybacki_, ayoung might have more info on specifics i think he wrote them, and wiring them up for tests was on the "we really need this as a follow up" list20:04
dolphmmorganfainberg: can haz juno-2 review? https://review.openstack.org/#/c/106893/20:04
hrybacki_morganfainberg: hah, okay. He's got me on another thing that I don't really understand but am working on as well :P20:04
morganfainbergdolphm, does it involve chezburgerz?20:04
hrybacki_morganfainberg: how to test that... hrm20:04
morganfainberghrybacki_, yeah no worries if you don't get to it20:04
dolphmmorganfainberg: no but i know what's for dinner all the sudden20:04
morganfainberghrybacki_, we can circle back in J3 for that20:04
ayoungI gave up on the scripts getting in20:05
morganfainbergdolphm, are we going to move it to /auth/catalog?20:05
hrybacki_all -- https://review.openstack.org/#/c/81166/ could use another review :)20:05
morganfainbergayoung, ah i thought we merged the scripts too20:05
dolphmmorganfainberg: there's a subsequent patch to change it to that if that's approved/etc20:05
hrybacki_morganfainberg: should I put something in launchpad for the tests? Is that worthy of that sort of thing20:05
morganfainbergdolphm, ah ok cool20:06
ayoungmorganfainberg, the client scripts?20:06
ayoungNope20:06
morganfainberghrybacki_, ah, nvm if we didn't merge the scripts strike it as something to worry about20:06
dolphmmorganfainberg: for reference, https://review.openstack.org/#/c/108043/20:06
hrybacki_morganfainberg: the script to pipe to mjson.tool or the script to test the outputs for validity?20:06
hrybacki_although piping it to mjson.tool w/o being valid would cause it to error anyway20:07
morganfainberghrybacki_, the script part20:07
*** gabriel-bezerra has quit IRC20:07
morganfainberghrybacki_, not just validating the data20:07
hrybacki_AH20:07
hrybacki_got it20:07
*** gabriel-bezerra has joined #openstack-keystone20:07
hrybacki_morganfainberg: will those ever be merged?20:07
morganfainberghrybacki_, the scripts aren't merged so don't worry about them. validating those .json files is cake in comparison20:07
morganfainberghrybacki_, uh. hopefully :P but not right now20:08
morganfainbergayoung, ok so lets see if we can come up with something to do about that in J3, since it wont affect anything to get them in (besides adding some tests)20:08
ayoungmorganfainberg, no, you've broken my spirit20:09
ayoung:)20:09
morganfainbergayoung, HAH20:09
lbragstaddolphm: I can do that20:09
ayoungmy focus is on Client right now.  Its a mess.20:09
ayoungThe scripts are handy in exercising it20:09
morganfainbergayoung, right20:09
hrybacki_ayoung: you break my spirit too :) it's okay -- adapt, overcome, excel. Right? :P20:09
ayoungInstigate and Escalate is the way I remember it.20:10
hrybacki_Hah, OLC and PLDC must have their differences20:10
morganfainbergdolphm, https://review.openstack.org/#/c/106893/6/keystone/tests/test_v3_catalog.py assertValidError isn't needed there?20:10
morganfainbergassertValidErrorResponse20:10
hrybacki_morganfainberg: do you still want a test suite for the validity of the json examples?20:11
morganfainberghrybacki_, if you get a chance, it would be good :)20:11
morganfainberghrybacki_, but it can happen in J3 or whenever, it would be a nice-to-have20:11
ayoungUSMA and IOBC actually20:12
hrybacki_morganfainberg: ++ that _shouldn't_ (I saw that and feel the hairs on the back of my neck rise thinking of the last test suite) be difficult20:12
*** bvandenh has quit IRC20:12
hrybacki_ayoung: mad respect -- I couldn't have done USMA20:13
ayounghrybacki_, and nowadays I don't know if I would get in20:13
ayoungYou know a school is good when you still have nightmares induced by it 20+ years later20:14
hrybacki_ayoung: I only know one person who went -- she was a beast, physically and mentally20:14
morganfainbergdolphm, +2 on the catalog bit20:17
ayoungWhat do I need to do to convince Horizon I really mean it when I say use Identity V3.0?  Where do I add the "please" keyword?20:17
morganfainbergdolphm, 2 in-line questions/comments but i'm fine with it as is.20:17
david-lyleayoung?20:17
ayounghttps://ayoungf20packstack.cloudlab.freeipa.org/keystone/main/v2.0/auth/tokens20:17
ayoungdavid-lyle, heh...I'm a hacking20:18
morganfainbergdavid-lyle, i see you use the same trick I do, get notifications on someone saying your project's name20:18
ayoungdavid-lyle, you don't really want to know....its along the lines of Laws and Sausages....20:18
morganfainbergdavid-lyle, ;)20:18
david-lyleayoung :)20:18
ayoungdavid-lyle, I'm working on converting django-openstack-auth to using Keystone sessions.   It works for auth, but then when Horizon directly askes for the project list, it goes to V2.0 for some reason20:19
ayoungvery likely something I did20:19
david-lylemorganfainberg: I'm not that sophisticated sadly, I was trolling trying to figure out a way to domain admin role with current keystone policy engine20:19
morganfainbergdavid-lyle, ah20:19
ayoungsee the URL above?  V3  portion at the end, but I suspect the /v2.0/ part got in there as I hack the "make the URL look right for the expected version" code in D-O-A20:20
ayoungdavid-lyle, policy.json with the cloudsampleversion20:20
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n720:21
david-lyleayoung: are you setting the OPENSTACK_API_VERSION for identity in local_settings.py?20:21
ayoungAHHHH PANDORA, STOP PLAYING URLS for REPORTING UNLICENSED OFFICE SOFTWARE!20:21
ayoungdavid-lyle, I  don't think so20:21
david-lyleayoung, I don't think that actually works there's no domain info that get's added to the creds20:22
ayoungdavid-lyle, Default domain for V2 tokens20:22
david-lyleayoung: https://github.com/openstack/horizon/blob/master/openstack_dashboard/local/local_settings.py.example#L3620:23
*** henrynash has joined #openstack-keystone20:23
ayoungdavid-lyle, actually, I do have:  OPENSTACK_API_VERSIONS = {20:23
ayoung    "identity": 320:23
ayoung}20:23
ayoungdavid-lyle, my code is pretty different from the original D-O-A code...let me see what is actually triggereing it20:24
ayoungdavid-lyle, I've evn hacked def get_keystone_version():20:25
ayoung    return getattr(settings, 'OPENSTACK_API_VERSIONS', {}).get('identity', 3.0)20:25
ayoungOK...I have a <  where I should hava >20:25
* ayoung duncecap20:25
dstanekok, i've spent almost an hour looking at a weird dependency issue - http://dpaste.com/3Y8T7G820:26
dstanekit seems that 'super(class, self).__init__' is actually the wrapper function - no idea why20:26
*** bvandenh has joined #openstack-keystone20:27
dstanekin my simple test cases this doesn't happen20:27
openstackgerritDolph Mathews proposed a change to openstack/python-keystoneclient: use embedded URLs for hyperlinks in the README  https://review.openstack.org/10363620:28
ayoungdstanek, loking20:28
ayounglooking20:28
*** nkinder has joined #openstack-keystone20:30
ayoungdstanek, is it possible that super(class, self).__init__  is not the wrapper, but rather the wrapper is triggered by a calling it?20:31
dstanekayoung: no, i printed the value to see what it was20:31
ayoungyuck20:31
ayoungdstanek, this is because the ec2 controller @depends on the controller?20:32
*** jvrbanac has left #openstack-keystone20:35
dolphmhenrynash: followed up on https://review.openstack.org/#/c/106893/20:37
*** arunkant has quit IRC20:39
henrynashdolphm: ok, yep - fine, just +2/A20:39
dolphmhenrynash: thanks!20:39
*** lbragstad has quit IRC20:39
*** hrybacki_ is now known as hrybacki20:39
dstanekayoung: i don't think so, but who knows20:39
dstanekayoung: i need a break from this...bbiab20:43
*** arunkant has joined #openstack-keystone20:49
openstackgerritSam Leong proposed a change to openstack/keystone: Disable a domain will revoke domain scoped tokens  https://review.openstack.org/10719420:54
*** arunkant has quit IRC20:54
*** arunkant has joined #openstack-keystone20:55
*** bvandenh has quit IRC20:58
henrynashayoung: btw, did you intend for there to be two separate specs for policy by endpoint?21:06
henrynashayoung: oen to ensuring endpoint_id is passed into the policy reading…and one for how we define which policy is right for a given endpint ID?21:07
ayounghenrynash, I thik I had some vague notion that they were slightly different21:08
ayounghenrynash, we need at least 2 specs21:09
ayoungone for fetching policy, on for assigning21:09
henrynashayoung: ok, agrred21:09
ayoungthe assigning part is what we need to nail down,  as fetching will accept endpoint Id as a way to disabuiatify21:09
ayoungsorry, typo21:09
*** gabriel-bezerra has quit IRC21:09
*** lbragstad has joined #openstack-keystone21:10
ayoungshould have read disambiguiatify21:10
*** gabriel-bezerra has joined #openstack-keystone21:10
henrynashayoung: ok21:11
*** lbragstad has quit IRC21:14
*** lbragstad has joined #openstack-keystone21:18
* morganfainberg glares at requirements gate job that is > 1 hr and only 50% done.21:22
morganfainbergbecause i need the keystone change behind it to merge before i can fix the next in the chain21:22
*** shakamunyi_ has quit IRC21:24
lbragstaddolphm: yeah, the validation stuff breaks on unicode.... hard21:29
dolphmlbragstad: is it jsonschema's fault?21:29
*** rodrigods has quit IRC21:29
lbragstaddolphm: I *think* so... doing some checking21:30
lbragstaddolphm: this says differently though: http://spacetelescope.github.io/understanding-json-schema/reference/string.html21:31
dolphmlbragstad: what's the failure you're seeing?21:31
lbragstaddolphm: http://paste.openstack.org/show/87486/21:32
lbragstaddolphm: test case: http://paste.openstack.org/show/87487/21:33
dolphmlbragstad: i can barely read the first paste http://paste.openstack.org/raw/87486/21:34
lbragstadyeah.. it's messed up21:36
lbragstadencoding issues or something...21:36
*** henrynash has quit IRC21:37
*** topol has quit IRC21:39
openstackgerritA change was merged to openstack/keystone: Example JSON files should be human-readable  https://review.openstack.org/10821221:43
openstackgerritA change was merged to openstack/keystone: implement GET /v3/catalog  https://review.openstack.org/10689321:44
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/10620821:46
morganfainbergdolphm, do you see https://review.openstack.org/#/c/107560 in zuul? i'm not seeing it, like the gate job ... disappeared?21:50
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/10621021:50
morganfainbergdolphm, nvm just issued a reverify21:51
dolphmmorganfainberg: i've seen that happen before... lost messages?21:51
morganfainbergdolphm, no, 100% success on check, just... no gate score and not in queue21:51
morganfainbergit i'll rebase it while i'm at it. need it rebased anyway21:52
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Mark the 'check_vX_token' methods deprecated  https://review.openstack.org/10756021:52
dolphmmorganfainberg: +A21:55
morganfainbergdolphm, cool21:55
* morganfainberg now goes and rebases the persistence change.21:55
*** gabriel-bezerra has quit IRC21:58
*** gabriel-bezerra has joined #openstack-keystone21:59
*** dims has quit IRC22:01
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Move token persistence classes to token.persistence module  https://review.openstack.org/10756122:01
*** rwsu has quit IRC22:02
stevemarmorganfainberg, dolphm did we somehow lose endpoint id's in the service catalog w.r.t. keystonemiddleware22:04
dolphmlbragstad: got a fix for you22:04
lbragstaddolphm: ?22:05
lbragstaddolphm: I'm still screwing with it, what did you do?22:05
morganfainbergstevemar, ?22:05
dolphmlbragstad: http://pastebin.com/raw.php?i=hESMWC5y22:05
morganfainbergstevemar, are you seeing endpoint IDs in the middleware from keystoneclient and not from keystonemiddleware?22:06
dolphmlbragstad: you have to tell python that the source contains unicode pep 263 http://legacy.python.org/dev/peps/pep-0263/22:06
stevemarmorganfainberg, if it's not ringing any bells, dont worry, i'll have to actually dig into the problem22:07
stevemarmorganfainberg, that is what a colleague is saying22:07
morganfainbergyeah not ringing a bell22:07
*** hrybacki has quit IRC22:07
morganfainbergthat seems unlikely22:07
morganfainbergbut stranger things have occured22:07
*** marekd has quit IRC22:08
stevemarmorganfainberg, the guy is seeing the endpoint id in the catalog being returned from keystone server, but when he's looking at ceilometer the service catalog's endpoints don't have id's22:09
morganfainbergstevemar, i wouldn't be surprised it that was the case.22:09
stevemarwhich makes me think auth token middleware22:09
lbragstaddolphm: so you added the encoding to the file?22:09
morganfainbergmiddleware might squash that out22:09
*** marekd has joined #openstack-keystone22:09
stevemarmorganfainberg, why would it?22:09
morganfainbergstevemar, but i don't think it's something that has changed from keystonecleint -> keystonemiddleware22:09
dolphmlbragstad: yep, just put # -*- coding: utf-8 -*-  on L122:09
*** gmurphy has quit IRC22:09
stevemarmorganfainberg, i'm not sure which one he's using22:10
morganfainbergstevemar, we have code to do some explicit v3->v2 catalog stuff and not all catalogs have endpoint ids?22:10
morganfainbergstevemar, shouldn't matter which he uses. results should be the same22:10
lbragstaddolphm: gotcha, didn't see that top line there22:10
morganfainbergstevemar, fairly certain templated catalog wont have IDs22:10
stevemarhttps://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L38522:11
lbragstaddolphm: sweet, good catch, works now. Pushing the initial implementation22:14
dolphmlbragstad: woot22:14
lbragstaddolphm: thoughts on https://review.openstack.org/#/c/86483/28/keystone/tests/test_validation.py ?22:15
lbragstadlooks like henry left22:16
*** gabriel-bezerra has quit IRC22:16
dolphmlbragstad: he's correct22:16
dolphmlbragstad: it's in pep25722:16
dolphmlbragstad: which i just realized he linked to :P22:16
*** gabriel-bezerra has joined #openstack-keystone22:16
lbragstadhttp://legacy.python.org/dev/peps/pep-0257/#multi-line-docstrings22:16
stevemarmorganfainberg, would keystone still return endpoint id's if using the templated catalog?22:16
morganfainbergstevemar, don't think so, but middleware might collapse to lowest common featureset? honestly haven't looked22:17
morganfainbergstevemar, let me know if you need help digging into that - i need food.22:17
* morganfainberg goes for a late lunch22:17
morganfainbergvery late22:18
stevemarmorganfainberg, yeah, i think middleware narrows down to common elements22:18
dolphmlbragstad: """Exception raised when passing a string of 255+ chars.22:19
dolphmlbragstad: summarize in the first line then elaborate in a paragraph if you want22:19
*** bknudson has quit IRC22:20
*** gabriel-bezerra has quit IRC22:21
lbragstaddolphm: sounds good, breaking them apart now22:21
*** gabriel-bezerra has joined #openstack-keystone22:21
*** packet has quit IRC22:25
*** cjellick has quit IRC22:25
*** dims has joined #openstack-keystone22:28
*** cjellick has joined #openstack-keystone22:31
*** cjellick has quit IRC22:31
*** cjellick has joined #openstack-keystone22:31
*** cjellick has quit IRC22:32
*** cjellick has joined #openstack-keystone22:32
*** dims has quit IRC22:32
*** henrynash has joined #openstack-keystone22:33
openstackgerritguang-yee proposed a change to openstack/keystone: X.509 SSL certificate authentication plugin  https://review.openstack.org/10373622:33
*** thedodd has quit IRC22:41
*** stevemar has quit IRC22:44
*** browne has joined #openstack-keystone22:44
*** browne has left #openstack-keystone22:45
*** henrynash has quit IRC22:52
openstackgerritLance Bragstad proposed a change to openstack/keystone: Initial implementation of validator  https://review.openstack.org/8648322:52
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Policy V3 API  https://review.openstack.org/10406522:52
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Catalog V3 resources  https://review.openstack.org/9626622:52
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Assignment V3 resources  https://review.openstack.org/8648422:52
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Trust V3 API  https://review.openstack.org/10406622:52
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Credential V3  https://review.openstack.org/9852222:52
*** shakamunyi_ has joined #openstack-keystone22:53
*** lbragsta_ has joined #openstack-keystone22:54
*** lbragstad has quit IRC22:58
*** lbragsta_ has quit IRC22:59
*** nkinder has quit IRC23:01
*** gmurphy has joined #openstack-keystone23:17
*** marcoemorais has quit IRC23:20
*** marcoemorais has joined #openstack-keystone23:21
*** marcoemorais has quit IRC23:21
*** marcoemorais has joined #openstack-keystone23:21
*** david-lyle has quit IRC23:24
*** bknudson has joined #openstack-keystone23:28
*** dims has joined #openstack-keystone23:28
*** KimJ has quit IRC23:29
*** shakamunyi_ has quit IRC23:33
*** dims has quit IRC23:33
*** jamielennox|away is now known as jamielennox23:36
*** ncoghlan has joined #openstack-keystone23:36
*** browne has joined #openstack-keystone23:41
openstackgerritJamie Lennox proposed a change to openstack/keystone-specs: Add a catalog to an unscoped token  https://review.openstack.org/10733323:43
*** mgarza has quit IRC23:45
*** gabriel-bezerra has quit IRC23:45
*** gabriel-bezerra has joined #openstack-keystone23:46
*** nkinder has joined #openstack-keystone23:54
jamielennoxdolphm: have a moment to talk about your -1 on https://review.openstack.org/#/c/104734/23:56
jamielennox?23:56

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!