*** gabriel-bezerra has quit IRC | 00:08 | |
*** gabriel-bezerra has joined #openstack-keystone | 00:09 | |
*** mitz has joined #openstack-keystone | 00:26 | |
*** ncoghlan has joined #openstack-keystone | 00:50 | |
*** xianghui has quit IRC | 01:07 | |
*** ncoghlan is now known as ncoghlan_afk | 01:11 | |
*** xianghui has joined #openstack-keystone | 01:12 | |
*** ncoghlan_afk is now known as ncoghlan | 01:13 | |
*** ayoung has joined #openstack-keystone | 01:23 | |
ayoung | jamielennox, can I run something by you? It has to do with sessions, unscoped and scoped tokens. | 01:24 |
---|---|---|
jamielennox | ayoung: of course | 01:24 |
ayoung | jamielennox, 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 |
ayoung | I'm thinking one session, as the current Horizon approach is to revoke the old (scoped) session after rescoping | 01:26 |
jamielennox | ayoung: so we have a 1 token per auth plugin policy, however the auth plugin can be specified at request time | 01:27 |
ayoung | the Password plugin creates the unscope token | 01:27 |
jamielennox | in the majority of cases for nova or someone they are only going to have one token and it's attached to the session | 01:27 |
ayoung | then you create a new Token plugin to use with that, and get scoped toke ns | 01:27 |
jamielennox | in 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 |
ayoung | then all work is done against nova using the scoped tokens...in the unified case | 01:28 |
ayoung | heh, I am rewritng at that code...Horizon will do what we decide here | 01:28 |
jamielennox | right, for someone dealing with lots of different sessions i expect they will still have to do some token/auth plugin management | 01:29 |
jamielennox | it'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 doing | 01:29 |
jamielennox | but i don't know yet | 01:30 |
*** dims__ has joined #openstack-keystone | 01:30 | |
ayoung | so you would never want to hold on to the password plugin | 01:30 |
jamielennox | so yes, you will need to use a password plugin to get an unscoped token, then use the token plugin to scope it | 01:31 |
ayoung | cuz you don't want to have the password hanging around | 01:31 |
jamielennox | ayoung: i expect you would have to as it's the only way you can extend the session time | 01:31 |
ayoung | My thought: Horizon will persist the scoped token to the session verbatim | 01:31 |
jamielennox | you can't exchange a token for a longer scoped token at the moment | 01:31 |
ayoung | and the unscoped tokens will be stuck in memcache, with a hash in the session cookie | 01:31 |
ayoung | Horizon will persist the scoped token to the session *cookie* verbatim | 01:32 |
jamielennox | and in general we are wanting people to stop exchanging a scoped token for a different scoped token so you need to keep the unscoped around | 01:32 |
ayoung | so I have a BP for the "extend the session" part | 01:32 |
jamielennox | yea, i hadn't realized it got discussed a fair bit at the mid-cycle | 01:32 |
jamielennox | morganfainberg_Z and i were talking about it the other day | 01:33 |
*** gabriel-bezerra has quit IRC | 01:33 | |
ayoung | not that much...but I've been heads down working it over | 01:33 |
ayoung | So, one session with multiple tokens? One unscoped, stored for future use, one scoped? | 01:33 |
*** gabriel-bezerra has joined #openstack-keystone | 01:34 | |
jamielennox | ayoung: i would just not store the auth on the session at all | 01:35 |
jamielennox | you can pass auth as a param to request: https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/session.py#n172 | 01:35 |
jamielennox | i honestly am not sure how practical that is though | 01:35 |
jamielennox | because the managers code is crap and you can't always pass things down from users.list(auth=auth) | 01:36 |
jamielennox | that was how i was *hoping* it would work | 01:37 |
ayoung | So...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 |
jamielennox | why stick it back? | 01:37 |
jamielennox | oh, hack around not being able to pass auth | 01:37 |
jamielennox | it might be your only option unfortunately | 01:37 |
jamielennox | (passing this is exactly the point of https://review.openstack.org/#/c/106658/ ) | 01:38 |
ayoung | he...stick the unscoped token in the session cookie | 01:40 |
ayoung | jamielennox, so the user will only ever have one session, right? | 01:45 |
ayoung | in the CLI case, I guess we would take the unscoped token, stick in python keyring? | 01:46 |
jamielennox | i would think so | 01:46 |
jamielennox | in the case of horizon i think horizon would probably only have one session | 01:46 |
ayoung | I think I want to leave the unscoped in the keystoneclient session. It lets keystoneclient manage extending the life of the unscoped token | 01:47 |
jamielennox | the 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 yet | 01:48 |
jamielennox | ayoung: it won't automatically extend - only if it is used, so it doesn't matter about leaving it there | 01:48 |
ayoung | yeah, 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 expensive | 01:49 |
ayoung | yup | 01:49 |
*** renlt has joined #openstack-keystone | 01:49 | |
jamielennox | not sure what you mean there | 01:50 |
jamielennox | but anyway horizon should be a big winner of this because all horizon communications should go down the same keep-alive connections | 01:50 |
*** diegows has quit IRC | 01:51 | |
*** mberlin has quit IRC | 01:51 | |
*** mberlin1 has joined #openstack-keystone | 01:51 | |
ayoung | jamielennox, 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 |
jamielennox | ayoung: oh, right - yea i've got nothing that can help that | 01:55 |
jamielennox | ayoung: is there any raw SAML support in IPA? | 01:58 |
ayoung | nah...simo is doing that with Ipsilon | 01:58 |
jamielennox | ayoung: yea, i figured that out after a lot of wasted time | 01:58 |
jamielennox | just making sure | 01:58 |
ayoung | sorry | 01:58 |
jamielennox | also realized just how rare SAML ECP is | 01:58 |
jamielennox | i don't mind the kerberos everthing approach of IPA but i was going for a basic federation setup and there really isn't one | 02:00 |
ayoung | Nope | 02:00 |
ayoung | we are going to have the first with mod_lookup_identiy | 02:00 |
jamielennox | but you can't do that without being an ipa-client right? | 02:01 |
ayoung | actually, yeah, you could | 02:01 |
ayoung | it would just be sssd LDAP in that case | 02:01 |
jamielennox | with a kerberos ticket? | 02:02 |
ayoung | you could do it with a different login mechanism | 02:04 |
ayoung | even Basic_Auth would work | 02:05 |
*** ncoghlan is now known as ncoghlan_afk | 02:09 | |
*** renlt has quit IRC | 02:11 | |
jamielennox | ayoung: 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 ncoghlan | 02:43 | |
*** dims__ has quit IRC | 03:09 | |
*** dims__ has joined #openstack-keystone | 03:35 | |
*** dims__ has quit IRC | 03:40 | |
ayoung | jamielennox, the big thing I needed was https://review.openstack.org/#/c/107873/ | 04:00 |
*** ayoung is now known as ayoung_ZZZzzz | 04:00 | |
*** dims__ has joined #openstack-keystone | 04:36 | |
*** dims__ has quit IRC | 04:40 | |
*** chandankumar has joined #openstack-keystone | 04:50 | |
*** ajayaa has joined #openstack-keystone | 05:11 | |
*** chandankumar has quit IRC | 05:12 | |
*** shausy has joined #openstack-keystone | 05:22 | |
*** stevemar has quit IRC | 05:29 | |
*** dims__ has joined #openstack-keystone | 05:37 | |
*** dims__ has quit IRC | 05:42 | |
*** ayoung_ZZZzzz has quit IRC | 05:44 | |
*** ayoung_ZZZzzz has joined #openstack-keystone | 05:53 | |
*** ukalifon1 has joined #openstack-keystone | 06:14 | |
*** k4n0 has joined #openstack-keystone | 06:16 | |
*** ukalifon1 has quit IRC | 06:19 | |
*** gabriel-bezerra has quit IRC | 06:23 | |
*** afazekas has joined #openstack-keystone | 06:34 | |
*** chandankumar has joined #openstack-keystone | 06:34 | |
*** dims__ has joined #openstack-keystone | 06:37 | |
*** gabriel-bezerra has joined #openstack-keystone | 06:39 | |
*** dims__ has quit IRC | 06:42 | |
*** tomoiaga has joined #openstack-keystone | 07:17 | |
*** chandankumar has quit IRC | 07:33 | |
*** jamielennox is now known as jamielennox|away | 07:36 | |
*** dims__ has joined #openstack-keystone | 07:38 | |
*** dims__ has quit IRC | 07:43 | |
ajayaa | dolphm: 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-keystone | 07:51 | |
*** gabriel-bezerra has quit IRC | 07:51 | |
*** atallguyfriend has left #openstack-keystone | 07:51 | |
*** gabriel-bezerra has joined #openstack-keystone | 07:52 | |
*** gabriel-bezerra has joined #openstack-keystone | 07:55 | |
*** gabriel-bezerra has joined #openstack-keystone | 07:57 | |
*** gabriel-bezerra has joined #openstack-keystone | 07:58 | |
*** gabriel-bezerra has joined #openstack-keystone | 08:01 | |
*** gabriel-bezerra has joined #openstack-keystone | 08:03 | |
*** bvandenh has joined #openstack-keystone | 08:11 | |
*** ajayaa has quit IRC | 08:19 | |
*** ajayaa has joined #openstack-keystone | 08:31 | |
*** chandankumar has joined #openstack-keystone | 08:32 | |
*** dims__ has joined #openstack-keystone | 08:39 | |
*** shausy has quit IRC | 08:39 | |
*** ncoghlan has quit IRC | 08:39 | |
*** ajayaa has quit IRC | 08:41 | |
*** shausy has joined #openstack-keystone | 08:41 | |
*** BAKfr has joined #openstack-keystone | 08:43 | |
*** dims__ has quit IRC | 08:43 | |
*** shausy has quit IRC | 08:51 | |
*** ajayaa has joined #openstack-keystone | 08:54 | |
*** kwss has joined #openstack-keystone | 09:14 | |
*** Dafna has joined #openstack-keystone | 09:16 | |
*** gabriel-bezerra has quit IRC | 09:19 | |
*** gabriel-bezerra has joined #openstack-keystone | 09:19 | |
*** afazekas has quit IRC | 09:23 | |
*** afazekas has joined #openstack-keystone | 09:35 | |
*** chandankumar has quit IRC | 09:46 | |
*** afazekas has quit IRC | 10:00 | |
*** ajayaa has quit IRC | 10:09 | |
*** chandankumar has joined #openstack-keystone | 10:10 | |
*** chandankumar has quit IRC | 10:11 | |
*** chandankumar has joined #openstack-keystone | 10:11 | |
*** afazekas has joined #openstack-keystone | 10:13 | |
*** ajayaa has joined #openstack-keystone | 10:21 | |
*** ajayaa has quit IRC | 10:32 | |
*** dims__ has joined #openstack-keystone | 10:40 | |
*** dims__ has quit IRC | 10:45 | |
*** ajayaa has joined #openstack-keystone | 10:48 | |
*** ajayaa has quit IRC | 10:58 | |
*** ajayaa has joined #openstack-keystone | 11:10 | |
*** ajayaa has quit IRC | 11:19 | |
*** ajayaa has joined #openstack-keystone | 11:32 | |
*** diegows has joined #openstack-keystone | 11:39 | |
*** dims__ has joined #openstack-keystone | 11:41 | |
*** RockKuo_Office has quit IRC | 11:42 | |
*** dims__ has quit IRC | 11:46 | |
*** dims__ has joined #openstack-keystone | 11:50 | |
*** andreaf has joined #openstack-keystone | 12:04 | |
*** rodrigods has joined #openstack-keystone | 12:18 | |
*** rodrigods has joined #openstack-keystone | 12:18 | |
*** hrybacki has joined #openstack-keystone | 12:20 | |
*** k4n0 has quit IRC | 12:28 | |
*** joesavak has joined #openstack-keystone | 12:40 | |
*** gabriel-bezerra has quit IRC | 12:40 | |
*** radez_g0n3 is now known as radez | 12:40 | |
*** gabriel-bezerra has joined #openstack-keystone | 12:40 | |
*** ajayaa has quit IRC | 12:49 | |
*** dims__ has quit IRC | 12:50 | |
*** dims__ has joined #openstack-keystone | 12:50 | |
*** gabriel-bezerra has quit IRC | 12:50 | |
*** gabriel-bezerra has joined #openstack-keystone | 12:51 | |
*** stevemar has joined #openstack-keystone | 12:54 | |
marekd | what is the deadline for approving specs for J ? | 12:55 |
*** topol has joined #openstack-keystone | 13:05 | |
*** dims has joined #openstack-keystone | 13:08 | |
*** ayoung_ZZZzzz is now known as ayoung | 13:08 | |
*** dims__ has quit IRC | 13:09 | |
*** lbragstad has joined #openstack-keystone | 13:09 | |
*** nkinder has quit IRC | 13:16 | |
*** gabriel-bezerra has quit IRC | 13:16 | |
*** gabriel-bezerra has joined #openstack-keystone | 13:16 | |
*** bknudson has joined #openstack-keystone | 13:17 | |
*** topol has quit IRC | 13:26 | |
*** diegows has quit IRC | 13:28 | |
marekd | dolphm: ^^ ? | 13:37 |
*** diegows has joined #openstack-keystone | 13:40 | |
*** dhellmann is now known as dhellmann_ | 13:41 | |
*** richm has joined #openstack-keystone | 13:55 | |
dolphm | marekd: according to https://wiki.openstack.org/wiki/SpecApprovalDeadline it would be this week | 13:55 |
*** richm has left #openstack-keystone | 13:55 | |
marekd | friday, right? | 13:57 |
marekd | dolphm: and specs proposing changes to the API are still landable, right? | 13:58 |
dolphm | lbragstad: 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 |
dolphm | marekd: yes | 14:00 |
marekd | dolphm: thanks. | 14:00 |
marekd | dolphm: well, yes was an answer to my question about friday or changing API ? | 14:00 |
dolphm | marekd: regarding friday, we never really picked a day. technically it'd be more like wednesday :-/ | 14:00 |
lbragstad | dolphm: yep, I can | 14:01 |
marekd | dolphm: ack | 14:01 |
dolphm | lbragstad: i'm guessing that patch passed flake8 before we merged the i18n module last week | 14:01 |
lbragstad | dolphm: ahh... yep, that's right | 14:05 |
*** nkinder has joined #openstack-keystone | 14:10 | |
*** KimJ has joined #openstack-keystone | 14:14 | |
lbragstad | dolphm: what do you think about dstanek's comment here: https://review.openstack.org/#/c/86483/23/keystone/common/validation/parameter_types.py | 14:15 |
lbragstad | the internationalization one? | 14:15 |
dolphm | lbragstad: oh yeah, that pattern won't fly | 14:15 |
lbragstad | yeah, I didn't think about that until dstanek said something | 14:16 |
dolphm | lbragstad: i can't think of what we can reasonably validate on name beyond length | 14:17 |
lbragstad | dolphm: so, just check that it is a string and it's not longer than 255 | 14:17 |
dolphm | lbragstad: what's with the boolean schema? (why is it allowed to be a string?) | 14:17 |
dolphm | lbragstad: minLength of 1 works too | 14:17 |
lbragstad | dolphm: that was something that I saw in the nova v3 api validation. | 14:18 |
lbragstad | we can make that more strict though | 14:18 |
lbragstad | by removing 'True', 'TRUE', 'true', and '1', saying use a real boolean value | 14:19 |
lbragstad | and only accepting True | 14:19 |
dolphm | lbragstad: yeah, just require a real boolean | 14:19 |
lbragstad | ok | 14:19 |
dolphm | lbragstad: we used to have really badly written clients, hence strings-as-booleans, but that predates v3 | 14:20 |
lbragstad | ok, so moving away from that then | 14:20 |
*** kwss has quit IRC | 14:23 | |
*** lbragstad has quit IRC | 14:26 | |
*** erecio has joined #openstack-keystone | 14:26 | |
*** lbragstad has joined #openstack-keystone | 14:28 | |
*** dhellmann_ is now known as dhellmann | 14:30 | |
*** rwsu has joined #openstack-keystone | 14:32 | |
*** gabriel-bezerra has quit IRC | 14:39 | |
*** gabriel-bezerra has joined #openstack-keystone | 14:41 | |
*** lbragstad has quit IRC | 14:47 | |
*** thedodd has joined #openstack-keystone | 14:49 | |
*** doddstack has joined #openstack-keystone | 14:52 | |
*** topol has joined #openstack-keystone | 14:53 | |
*** thedodd has quit IRC | 14:54 | |
*** morganfainberg_Z is now known as morganfainberg | 14:56 | |
*** lbragstad has joined #openstack-keystone | 14:59 | |
hrybacki | ayoung: 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 IRC | 15:00 | |
*** openstackgerrit has joined #openstack-keystone | 15:02 | |
ayoung | yeah | 15:06 |
ayoung | hrybacki, looking at your responses now... | 15:06 |
*** richm has joined #openstack-keystone | 15:07 | |
ayoung | hrybacki, 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 V3 | 15:08 |
*** david-lyle has joined #openstack-keystone | 15:08 | |
hrybacki | ayoung: okay -- so that means a majority re-write of that code, yes? | 15:09 |
*** gabriel-bezerra has quit IRC | 15:09 | |
ayoung | hrybacki, 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 class | 15:09 |
*** tomoiaga has quit IRC | 15:10 | |
ayoung | _http request, _json_request ... | 15:10 |
*** gabriel-bezerra has joined #openstack-keystone | 15:10 | |
ayoung | path = '/v2.0/tokens/%s' % user_token | 15:10 |
ayoung | '/v2.0/tokens/revoked', | 15:10 |
hrybacki | yeah, I' | 15:11 |
ayoung | yeah...big rewrite to do everything right....OK, lets leave that for now, and just encapsulate the URL construction | 15:11 |
hrybacki | want to understand why you want that stuff pulled out | 15:11 |
ayoung | embedded string handling is a major smell of bad code | 15:12 |
hrybacki | oaky | 15:12 |
ayoung | self._http_request('GET', has an cleaner analog in the requests library | 15:12 |
ayoung | I understand why it was written that way at first. | 15:12 |
ayoung | We 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 undertaking | 15:13 |
ayoung | hrybacki, 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 |
hrybacki | not to sound thick but I'm not sure exactly what you are wanting me to do here | 15:15 |
*** gyee has joined #openstack-keystone | 15:20 | |
ayoung | hrybacki, 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 |
hrybacki | okay and as it stands it only works with v2, yes? | 15:21 |
dstanek | dolphm, lbragstad: just catching up - i think we still accept ints for at least some of the boolean values | 15:21 |
ayoung | ideally, 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 |
dstanek | ayoung: URL building in the client? | 15:22 |
dolphm | dstanek: oh that's true i think | 15:22 |
hrybacki | ayoung: hmmm okay | 15:22 |
ayoung | dstanek, URL building in auth_token middleware | 15:22 |
ayoung | dstanek, https://review.openstack.org/#/c/105031/4/keystonemiddleware/auth_token.py | 15:23 |
dstanek | dolphm, lbragstad: yeah, disabled uses this http://git.openstack.org/cgit/openstack/keystone/tree/keystone/clean.py#n47 | 15:24 |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Extracting get group roles for project logic to drivers. https://review.openstack.org/86025 | 15:24 |
dstanek | ayoung: i violently agree with your comment. | 15:25 |
bknudson | once we get JSON-Home support then we won't have to build URLs | 15:25 |
bknudson | query the JSON-Home document for the rel you need and it gives you the URL | 15:25 |
bknudson | then just need to do any replacements if it's a template | 15:26 |
morganfainberg | dstanek, violent agreement eh? | 15:28 |
hrybacki | dstanek: to which comment specifically? | 15:28 |
*** cjellick has joined #openstack-keystone | 15:30 | |
dstanek | hrybacki: about not composing the URL | 15:30 |
dstanek | hrybacki: mucking with the URL (beyond URL templates) is an indicator that the API is not a REST API | 15:30 |
hrybacki | hmm-m-m | 15:30 |
openstackgerrit | David Stanek proposed a change to openstack/keystone: Regenerate sample config file https://review.openstack.org/108405 | 15:31 |
openstackgerrit | David Stanek proposed a change to openstack/keystone: Fixed tox cover environment to share venv https://review.openstack.org/108406 | 15:31 |
openstackgerrit | David Stanek proposed a change to openstack/keystone: Adds coverage report to py33 test runs https://review.openstack.org/108407 | 15:31 |
hrybacki | So 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 yet | 15:31 |
*** cjellick has quit IRC | 15:35 | |
*** cjellick has joined #openstack-keystone | 15:35 | |
*** cjellick has quit IRC | 15:36 | |
ayoung | hrybacki, 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_bridge | 15:37 |
hrybacki | There is a lot of hardcoded paths throughout auth_token | 15:37 |
*** gabriel-bezerra has quit IRC | 15:37 | |
*** cjellick has joined #openstack-keystone | 15:37 | |
hrybacki | okay | 15:37 |
*** gabriel-bezerra has joined #openstack-keystone | 15:37 | |
ayoung | its probably not a full blown bridge design pattern, but the client kindof plays that role... | 15:38 |
ayoung | http://en.wikipedia.org/wiki/Bridge_pattern | 15:38 |
ayoung | hrybacki, in this diagram the V2 vs V3 stuff is the abstractions. http://en.wikipedia.org/wiki/Bridge_pattern#Structure | 15:39 |
ayoung | let me say that better | 15:39 |
ayoung | _verify_uuid_token is the abstraction | 15:40 |
*** henrynash has joined #openstack-keystone | 15:40 | |
ayoung | the refined abstraction will be the code that calls the v2 vs v3 version of the API | 15:40 |
* hrybacki nods | 15:41 | |
henrynash | ayoung: 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 |
ayoung | YES YES YES. Er Ahem. Ok henrynash | 15:42 |
henrynash | ayoung: do you want me to take one of them? if so, let me know your preference | 15:43 |
ayoung | henrynash, unscoped token is my priority | 15:43 |
*** erecio has quit IRC | 15:43 | |
ayoung | which is your? | 15:43 |
henrynash | ayoung: probably both….but if you want to push that one, I’ll grab the policy by endpint ID one | 15:44 |
ayoung | henrynash, 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 |
henrynash | ayound: deal! | 15:45 |
*** afazekas has quit IRC | 15:47 | |
*** Guest32427 is now known as mfisch | 15:54 | |
*** shakamunyi has joined #openstack-keystone | 15:54 | |
*** doddstack has quit IRC | 15:54 | |
*** mfisch is now known as Guest60831 | 15:54 | |
ayoung | henrynash, 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 reason | 15:56 |
henrynash | ayoung: 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 |
henrynash | ayoung: btw, related but seperate…whats the proposed change that makes endpoint filtering checked at API executipon tme…is that token binding? | 15:59 |
ayoung | henrynash, 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 jamiec | 16:00 |
ayoung | er jamielennox|away | 16:00 |
*** Guest60831 has quit IRC | 16:01 | |
henrynash | ayoung: is there a bp /spec for token endpoint binding? | 16:01 |
ayoung | henrynash, mmmmaybe? It looks like dolphm did a blueprint cleanout and I'll have to see if it was one of the ones he nacked | 16:01 |
ayoung | actually, maybe he didn't...might have been a transient view thing that made it look like they were gone...lookin | 16:02 |
ayoung | henrynash, https://blueprints.launchpad.net/keystone/+spec/endpoint-scoped-tokens | 16:03 |
*** gabriel-bezerra has quit IRC | 16:03 | |
ayoung | just that, I think | 16:03 |
henrynash | ayoung: ok, thanks | 16:03 |
*** gabriel-bezerra has joined #openstack-keystone | 16:03 | |
dstanek | this would go much faster it the tests didn't take forever! | 16:05 |
*** chandankumar has joined #openstack-keystone | 16:07 | |
*** thedodd has joined #openstack-keystone | 16:09 | |
dolphm | lbragstad: p.s. ping me when you have a patch up on https://review.openstack.org/#/c/86483/ - i want to get that moving ASAP | 16:09 |
dolphm | henrynash: ooh, this too =) https://review.openstack.org/#/c/106893/ | 16:10 |
dolphm | henrynash: replaced all the self.v3_request(method='GET', ...) with self.get(...) | 16:10 |
lbragstad | dolphm: will do.. about to push a new version | 16:10 |
henrynash | dolphm: ok, looking now | 16:10 |
dolphm | henrynash: which was an artifact of me debugging :( | 16:10 |
lbragstad | dolphm: looking into the one comment you had on more specific error messages with json schema... | 16:10 |
lbragstad | checking jsonschema Exception object | 16:11 |
dolphm | lbragstad: that's just a nice to have in the long run; don't need to pursue it right now | 16:11 |
*** gabriel-bezerra has quit IRC | 16:11 | |
lbragstad | dolphm: ok, new patch on the way | 16:12 |
*** gabriel-bezerra has joined #openstack-keystone | 16:12 | |
hrybacki | ayoung: 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 |
ayoung | hrybacki, 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 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Initial implementation of validator https://review.openstack.org/86483 | 16:13 |
*** jvrbanac has joined #openstack-keystone | 16:13 | |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Policy V3 API https://review.openstack.org/104065 | 16:13 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Catalog V3 resources https://review.openstack.org/96266 | 16:13 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Assignment V3 resources https://review.openstack.org/86484 | 16:13 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Trust V3 API https://review.openstack.org/104066 | 16:13 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Credential V3 https://review.openstack.org/98522 | 16:13 |
hrybacki | okay | 16:13 |
*** marcoemorais has joined #openstack-keystone | 16:14 | |
henrynash | dolphm: done | 16:15 |
morganfainberg | dolphm, 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 |
morganfainberg | it'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 tokens | 16:16 |
*** fish_ has joined #openstack-keystone | 16:16 | |
fish_ | hi | 16:16 |
morganfainberg | talked with ayoung about that last week and it seemed to be the most sane approach. | 16:16 |
ayoung | morganfainberg, ++ | 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 IRC | 16:19 | |
morganfainberg | fish_, in an ideal world db_sync is a no-op if the db schema is up to date | 16:19 |
*** gabriel-bezerra has quit IRC | 16:19 | |
morganfainberg | fish_, i always err on the side of don't do db_sync unless you *really* mean it and intend it | 16:19 |
*** chandankumar has quit IRC | 16:19 | |
morganfainberg | fish_, 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 |
ayoung | fish_, would there be multiple Keystones pointing at the same DB? | 16:20 |
morganfainberg | fish_, but there is nothing saying you *can't* | 16:20 |
ayoung | You wouldn't want to upgrade a db with Keystone running | 16:20 |
*** gabriel-bezerra has joined #openstack-keystone | 16:20 | |
morganfainberg | ayoung, ++ | 16:20 |
fish_ | ayoung: hrm good point | 16:21 |
ayoung | fish_, unfortunately, I don't think we provide an easy way to say "is this database out of sync" | 16:21 |
ayoung | ideally we would have db_version and something that says db_versions_required | 16:21 |
ayoung | I guess we should, too.... | 16:21 |
dstanek | morganfainberg: what would happen with the implementation already in the client? | 16:21 |
morganfainberg | dstanek, it does network calls to ask for information and tokens from keystone | 16:21 |
ayoung | morganfainberg, what happens if we run code against an out-of-sync db? No real warning, just random failures,right? | 16:22 |
openstackgerrit | A change was merged to openstack/keystone: project disabled/deleted notification recommendations https://review.openstack.org/106845 | 16:22 |
openstackgerrit | A change was merged to openstack/keystone: Consolidate `assert_XXX_enabled` type calls to managers https://review.openstack.org/107220 | 16: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 |
morganfainberg | ayoung, 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 schema | 16:23 |
dstanek | morganfainberg: sounds sane to me too | 16:23 |
lbragstad | dolphm: all comments addressed on https://review.openstack.org/#/c/86483/ waiting on Jenkins | 16:23 |
morganfainberg | fish_, 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 db | 16:23 |
morganfainberg | fish_, but i would make sure keystone is turned off before updating the db :) | 16:23 |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements https://review.openstack.org/106208 | 16:24 |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/106232 | 16:24 |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/106210 | 16:28 |
henrynash | dolphm: 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-keystone | 16:33 | |
fish_ | morganfainberg: / ayoung: thanks! got it now :) | 16:35 |
*** packet has joined #openstack-keystone | 16:37 | |
ayoung | dolphm, please remove the -2 https://review.openstack.org/#/c/107873/ | 16:38 |
*** gabriel-bezerra has quit IRC | 16:38 | |
*** hrybacki_ has joined #openstack-keystone | 16:39 | |
*** chandankumar has quit IRC | 16:39 | |
*** gabriel-bezerra has joined #openstack-keystone | 16:40 | |
*** hrybacki has quit IRC | 16:43 | |
*** gabriel-bezerra has quit IRC | 16:43 | |
*** BAKfr has quit IRC | 16:43 | |
*** hrybacki_ has quit IRC | 16:43 | |
*** gabriel-bezerra has joined #openstack-keystone | 16:45 | |
*** david-lyle has quit IRC | 16:46 | |
*** gabriel-bezerra has quit IRC | 16:46 | |
*** joesavak has joined #openstack-keystone | 16:48 | |
*** erecio has joined #openstack-keystone | 16:49 | |
*** david-lyle has joined #openstack-keystone | 16:52 | |
*** gabriel-bezerra has joined #openstack-keystone | 16:52 | |
*** chandankumar has joined #openstack-keystone | 16:53 | |
*** gabriel-bezerra has quit IRC | 16:54 | |
*** gabriel-bezerra has joined #openstack-keystone | 16:55 | |
ayoung | So...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-keystone | 16:57 | |
*** mfisch has quit IRC | 16:57 | |
*** mfisch has joined #openstack-keystone | 16:57 | |
*** hrybacki has joined #openstack-keystone | 17:00 | |
*** alex_xu has quit IRC | 17:01 | |
ayoung | bknudson, wouldn't it be much friendlier if we added Accept: application/openstack-identity-v3+json | 17:05 |
dstanek | morganfainberg: is there a reason that our manager are all singletons? | 17:05 |
ayoung | dstanek, because singletons are abused | 17:05 |
ayoung | dstanek, stricly speaking, you can't have a true singleton in Python. People want to be able to resolve instances of classes by python namespacing | 17:06 |
ayoung | dstanek, termie implemented that in his KSL rewrite | 17:06 |
dstanek | ayoung: you can have singletons, but it's not enforced the same way as Java - i'd rather not do that anyway | 17:07 |
ayoung | dstanek, ++ | 17:07 |
dstanek | i 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 DI | 17:08 |
ayoung | dstanek, I could argue, but it would be quibbling, and I agree with you on the "rather not" | 17:08 |
ayoung | dstanek, I have been looking forward to this for a long time | 17:08 |
ayoung | since at least http://adam.younglogic.com/2012/03/di-python/ march of 2012 | 17:09 |
*** harlowja_away is now known as harlowja | 17:12 | |
ayoung | dstanek, 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 |
ayoung | that is what I was going with https://github.com/admiyo/python-resolver/ | 17:12 |
ayoung | where | 17:12 |
dstanek | ayoung: 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 |
ayoung | dstanek, so what is your plan? | 17:14 |
dstanek | right now | 17:14 |
dstanek | i'm trying to make the deps more obvious | 17:14 |
ayoung | dstanek, 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 dependencies | 17:16 |
dstanek | ayoung: 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 |
dstanek | from there a DI framework could actually help by hiding the boilerplate | 17:18 |
ayoung | dstanek, that is a half way solution. THe caller should not know about the deps, either | 17:18 |
ayoung | the caller needs to ask the framework for the object | 17:18 |
ayoung | I *think* we are saying similar, but not identica; things | 17:19 |
dstanek | ayoung: yes, halfway. this is the first step of many | 17:19 |
ayoung | dstanek, 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 |
ayoung | we 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 python | 17:21 |
dstanek | ayoung: 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 |
ayoung | dstanek, it is. THe dictionary of stuff is for creating credential_api in the first place | 17:23 |
ayoung | each object has a hard interface in its constructor | 17:23 |
ayoung | you use the context to get the *right* instance | 17:23 |
ayoung | so if there is already a credential_api object in the proper scope, fetch it out of the context | 17:24 |
dstanek | that's similar to SG - it uses a construct called scopes to manage some of that | 17:24 |
ayoung | dstanek, I am sure. I didn't invent any of this, just used it time and again in multiple frameworks | 17:24 |
dstanek | ayoung: if you have time take a look at the SG API tests to get a feel for how it works. i'd love the feedback | 17:25 |
ayoung | although I am a little proud of my C++ impl, but mostly I've used and done this in Java | 17:25 |
ayoung | dstanek, I know I looked at one point, let me look again. | 17:25 |
ayoung | I hate the name, BTW | 17:25 |
dstanek | the snake or the guice? | 17:26 |
ayoung | the G comes from Google, and this it more baseline than that | 17:26 |
ayoung | I think DI should be a base python utility, and the naming should reflect that | 17:26 |
dstanek | it's a re-implementation of Guice | 17:26 |
ayoung | and it implies that we are going to be using the same desing decisions of Guice, which I want the free reign to override | 17:27 |
dstanek | ayoung: like what? | 17:27 |
ayoung | No idea. | 17:27 |
ayoung | I dpn | 17:28 |
ayoung | I don't know Guice well enough | 17:28 |
ayoung | but I've seen enough bad DI that I don't want to be tied to someone elses mistakes. | 17:28 |
ayoung | http://stackoverflow.com/questions/2026016/google-guice-vs-picocontainer-for-dependency-injection interesting...I liked pico back in the day | 17:29 |
ayoung | I'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 |
raildo | henrynash: ping | 17:31 |
dstanek | ayoung: the naming is not arbitrary - i uses the basic design elements or Guice - modules, scope, etc. | 17:32 |
*** hrybacki has quit IRC | 17:32 | |
ayoung | dstanek, Java had annotations come along, which as I recall, Guice used, and I thought it was a bad design | 17:32 |
ayoung | setter injection is also a work around for lack of info in Java | 17:33 |
*** erecio has quit IRC | 17:33 | |
ayoung | actaully, until recently, Java couldn't do proper DI. | 17:33 |
ayoung | http://adam.younglogic.com/2014/05/parameter-names-in-java-8/ | 17:33 |
ayoung | Not guices fault | 17:33 |
ayoung | dstanek, OK, let me lay out the requirements as I see them | 17:34 |
dstanek | i'm pretty sure pico is also based on annotations | 17:34 |
dstanek | actually there is a JSR for it | 17:34 |
ayoung | nope1: need to be able to pull in | 17:34 |
ayoung | dstanek, nope, pico predated that | 17:34 |
ayoung | you used Java code to link them together | 17:34 |
ayoung | then Nano was built on Pico using XML | 17:34 |
ayoung | there might be a Pico binding to the annotations since I last looked, though | 17:35 |
ayoung | would not be surprised | 17:35 |
dstanek | ayoung: any language can do DI it's just a pattern for building objects | 17:35 |
ayoung | annotations in Java are a grand mistake. | 17:35 |
*** afazekas has joined #openstack-keystone | 17:35 | |
ayoung | dstanek, 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 purist | 17:36 | |
dstanek | ayoung: how do you define DI then? | 17:36 |
ayoung | dstanek, 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 context | 17:37 |
ayoung | let me clarify | 17:37 |
ayoung | say I say " I need a Database connection" | 17:37 |
ayoung | and there are two Database connections available | 17:37 |
ayoung | I need to say either "give me the default one" or "give me the one that is for the reports Database" | 17:38 |
dstanek | ayoung: that is not how i understand DI - an object should not ask for dependencies (Factory pattern) it should be handed them during construction | 17:39 |
*** gabriel-bezerra has quit IRC | 17:39 | |
ayoung | Even if both Were instance of the class "DatabaseConnection" there is still "reports" versus "orders" or "idm" | 17:39 |
ayoung | dstanek, it should register for dependencies before construction | 17:39 |
ayoung | "objects" don't ask for anything | 17:39 |
ayoung | users as for objects from the DI framework | 17:39 |
*** gabriel-bezerra has joined #openstack-keystone | 17:39 | |
ayoung | dstanek, let me try a concrete example | 17:39 |
ayoung | lets take our authenticate call | 17:40 |
ayoung | it takes in a JSON object with the Auth data. | 17:40 |
ayoung | Now, this is obviously request scope | 17:40 |
ayoung | d | 17:40 |
*** thedodd has quit IRC | 17:40 | |
ayoung | in order to validate it, we need to pull in first the set of auth plugins, and validate the authentication | 17:40 |
ayoung | auth_plugins are application scoped | 17:41 |
ayoung | some would call them "stateless" | 17:41 |
ayoung | some auth plugins also need the Identity API | 17:41 |
dstanek | but the authenticate call should know of care about the scope of the objects it receives | 17:41 |
ayoung | the authenticate call starts the whole thing off | 17:41 |
dstanek | it takes a dict and will get passed on by the caller | 17:41 |
ayoung | so 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 API | 17:42 |
ayoung | so the Identity API is created on demand, too | 17:42 |
ayoung | the ID API needs a driver | 17:42 |
ayoung | and, with Henry's code, it now needs many drivers | 17:42 |
ayoung | these are instance of components, potentially identical in class name, but distinguished by IdPs | 17:43 |
ayoung | Now, Keystone does not have Sessions. It only has Tokens. | 17:43 |
ayoung | Well, really, Tokens are Auth Context | 17:43 |
*** tziOm has quit IRC | 17:43 | |
ayoung | So 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 Tokenlesscalls | 17:44 |
*** tziOm has joined #openstack-keystone | 17:45 | |
*** gabriel-bezerra has quit IRC | 17:45 | |
*** shakamunyi_ has joined #openstack-keystone | 17:45 | |
*** gabriel-bezerra has joined #openstack-keystone | 17:46 | |
ayoung | dstanek, 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 on | 17:46 |
ayoung | might need to do that to avoid some threading issues, too | 17:46 |
*** shakamunyi has quit IRC | 17:49 | |
ayoung | dstanek, so lets start here: https://code.google.com/p/snake-guice/wiki/UsingProviders | 17:50 |
ayoung | @provide(session=session_provider) | 17:50 |
ayoung | that is showing the lack of type safety in Python, and attempting to use annotations to work around it. It is not DI | 17:51 |
*** vhoward has left #openstack-keystone | 17:51 | |
ayoung | @inject(filename=Config('app.cfg:logger:filename'), | 17:51 |
ayoung | loglevel=Config('app.cfg:logger:loglevel')) | 17:51 |
morganfainberg | dstanek, our managers are sort-of-singletons | 17:51 |
ayoung | see, now you are linking a class to the implementation. Those two thing should be separated | 17:52 |
dstanek | ayoung: since Python doesn't have a standard way to label types - i used decorators to do that | 17:52 |
ayoung | dstanek, 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 it | 17:52 |
dstanek | ayoung: what class is being linked to the implementation? | 17:53 |
ayoung | dstanek, that is fine. Its just not DI | 17:53 |
ayoung | from snakeguice import inject, Injected, Config | 17:53 |
ayoung | class MyLogger(object): | 17:53 |
ayoung | My logger should know nothing about snakeguice | 17:53 |
ayoung | MyLogger is a class, and requires a filename and a loglevel | 17:54 |
ayoung | fine, make that one class | 17:54 |
dstanek | ayoung: that isn't really a big deal because the decorators can some from anywhere any be linked to SG | 17:54 |
ayoung | the registration of the component is external | 17:54 |
ayoung | so somewhere else: | 17:54 |
ayoung | it should be | 17:54 |
dstanek | ayoung: Modules are how something is registered | 17:54 |
dstanek | classes using SG don't know what implementation they'll get. only that it conforms to an interface. | 17:55 |
ayoung | dstanek, Then don't call it MyLogger, call it RegisterMyLogger. But I don't think that is what you are saying | 17:56 |
ayoung | And Snakeguice should not be part of the interface definition either | 17:56 |
henrynash | raildo: hi | 17:56 |
ayoung | dstanek, look here: | 17:56 |
ayoung | https://github.com/admiyo/python-resolver/blob/master/test/resolver_test.py#L23 | 17:56 |
ayoung | now, this is a single file for a test case, and I have not fully developed it, but | 17:57 |
dstanek | the SG decorators can be hidden from the class itself - it's just that there really isn't much point in doing that | 17:57 |
ayoung | this is the factory. This creates a new instance. | 17:57 |
ayoung | It is nt what the end user calls | 17:57 |
ayoung | they call | 17:57 |
dstanek | https://code.google.com/p/snake-guice/source/browse/tests/system/test_api.py#58 | 17:58 |
ayoung | op = res.resolve(SampleOp) | 17:58 |
raildo | henrynash: I wonder if you got any doubt in the spec about hierarchical multitenancy and domains | 17:58 |
ayoung | and then op.operation(), | 17:58 |
*** thedodd has joined #openstack-keystone | 17:58 | |
raildo | henrynash: I answered you there, and do not know if you saw. | 17:58 |
henrynash | raildo: let me look | 17:58 |
ayoung | @inject(hero=ch.Person, villian=ch.Person, victim=ch.Person) | 17:58 |
ayoung | @annotate(hero='good', villian='evil') | 17:58 |
dstanek | ayoung: what if SampleOp needs depencencies? | 17:59 |
ayoung | it gets them chained... | 17:59 |
raildo | https://review.openstack.org/#/c/101017/9/specs/juno/hierarchical_multitenancy.rst | 17:59 |
ayoung | it would look like this | 17:59 |
morganfainberg | ayoung, so, let me get this straight, you instantiate a new provider per object that needs it injected? | 17:59 |
ayoung | dstanek, actually it does already | 17:59 |
morganfainberg | ayoung, /me is catching up on the convo | 17:59 |
ayoung | https://github.com/admiyo/python-resolver/blob/master/test/resolver_test.py#L29 | 17:59 |
henrynash | raildo: so here was my last comment (that I don’t see answered): | 17:59 |
henrynash | OK, 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 propos | 18:00 |
henrynash | change actual solves the user cases identified. | 18:00 |
ayoung | in this case sample_op depends on base | 18:00 |
ayoung | do_something is a bad name | 18:00 |
ayoung | dstanek, lets start here https://github.com/admiyo/python-resolver/blob/master/test/resolver_test.py#L56 | 18:01 |
ayoung | outside of the classes to be managed, we register 3 components | 18:01 |
*** marcoemorais has quit IRC | 18:01 | |
*** erecio has joined #openstack-keystone | 18:01 | |
ayoung | they use the baseclass name to indicate what they provide | 18:01 |
*** marcoemorais has joined #openstack-keystone | 18:01 | |
ayoung | resolver.register(SampleOp, do_something) | 18:01 |
*** marcoemorais has quit IRC | 18:02 | |
ayoung | for the simple case, you could use a lambda | 18:02 |
openstackgerrit | A change was merged to openstack/keystone: Extracting get group roles for project logic to drivers. https://review.openstack.org/86025 | 18:02 |
*** marcoemorais has joined #openstack-keystone | 18:02 | |
ayoung | or possibly even just drop the second parameter and have a default that called the no-arg constructor | 18:02 |
*** joesavak has quit IRC | 18:02 | |
raildo | henrynash: Ok, I'll explain better the example, but the answer was clear, correct? | 18:02 |
ayoung | So A logger for logging to StandardOut, for example would not need to depend on anything else. | 18:03 |
ayoung | that could be | 18:03 |
*** nkinder has quit IRC | 18:03 | |
ayoung | resolver.register(StandardOutLogger) but it would not be right, as that should really be registered against the Base Class | 18:03 |
dstanek | ayoung: doesn't this lead of factory explosion? it looks like you would have to create lots of factories | 18:03 |
ayoung | so better to do | 18:04 |
ayoung | resolver.register(Logger, lambda (return StandardOutLogger()) ) | 18:04 |
morganfainberg | dstanek, ++ | 18:04 |
*** afazekas has quit IRC | 18:04 | |
ayoung | dstanek, elliding the simple cases is pretty straight forward | 18:04 |
*** joesavak has joined #openstack-keystone | 18:04 | |
henrynash | raildo: well, actually, I don;t think we describe how projects and domains interact with each other in releation to the use cases we are describing | 18:04 |
morganfainberg | ayoung, so you'd be creating a new instance of StandardOutLogger on each dependency injected? | 18:05 |
dstanek | ayoung: let me come up with a quick example and you can show me how it would be implemented | 18:05 |
morganfainberg | ayoung, that uses logger | 18:05 |
henrynash | raildo: as I have said before, most use cases you list seem to want hierachical domains not hierachical projects…so no, I’m not sold yet | 18:05 |
morganfainberg | henrynash, i would say domains and projects should be the same thing | 18:06 |
morganfainberg | henrynash, removing the distinction. | 18:06 |
henrynash | morganfainberg: I agree… and “domain-ness” should be an attribute of projects | 18:06 |
morganfainberg | henrynash, ++ and that resolves the hierarchical domain vs project argument | 18:07 |
henrynash | morganfainberg: which probably only means an achor point at which you can create users | 18:07 |
morganfainberg | henrynash, it wouldn't matter. | 18:07 |
henrynash | morganfainberg, raildo: …and my point is that this has to go into the spec…since otherwise, standalone, the spec does not deliver on the use cases | 18:08 |
morganfainberg | henrynash, 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' object | 18:08 |
morganfainberg | henrynash, not arguing that point. :) | 18:08 |
raildo | this 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 |
morganfainberg | the way i saw it is domain is just a way to maintain compatibility pre-hierarchy. | 18:09 |
henrynash | morganfainberg: (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 |
morganfainberg | and 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 |
henrynash | raildo: 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 |
morganfainberg | so .list_domains is simply a get me all prjects with no parent | 18:11 |
dstanek | ayoung: DI by hand https://gist.github.com/dstanek/bd4a642f694de01ef9a9 | 18:11 |
morganfainberg | henrynash, oh projects can't have hiearchy and be in different domains. that would be awful. | 18:11 |
morganfainberg | all relationships parent->child needs to be in the same domain, | 18:12 |
raildo | henrynash: should be created a hierarchical projects within each domain, this is the relationship between domains and h-m | 18:12 |
henrynash | morgainfainberg: 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 |
morganfainberg | it doens't make sense to have ProjecT(DOMAIN-X)->project(DOMAIN-Y) | 18:12 |
morganfainberg | henrynash, ++ | 18:12 |
morganfainberg | so we "fix" domains. | 18:13 |
raildo | morganfainberg: ++ | 18:13 |
henrynash | raildo: 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 hierachy | 18:13 |
morganfainberg | raildo, which is what you said was expensive for Juno | 18:13 |
*** amcrn has joined #openstack-keystone | 18:13 | |
morganfainberg | dstanek, ok so any dependency just becomes part of the constructor? | 18:14 |
morganfainberg | dstanek, based on your by-hand example? | 18:14 |
*** nkinder has joined #openstack-keystone | 18:15 | |
*** tellesnobrega has joined #openstack-keystone | 18:16 | |
dstanek | morganfainberg: that's the simple way the view DI yes | 18:16 |
raildo | henrynash: 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 |
morganfainberg | dstanek, ok, yeah was looking over your SG implementation as well | 18:17 |
morganfainberg | dstanek, makes sense to me. | 18:17 |
dstanek | morganfainberg: i've got a simple example with credentails that i'm working through now | 18:17 |
morganfainberg | dstanek, cool. | 18:18 |
henrynash | raildo: 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 |
raildo | morganfainberg: I think it's expensive make project and domain the same thing. They have many tests and methods that must be changed. | 18:20 |
openstackgerrit | Sam Leong proposed a change to openstack/keystone: Disable a domain will revoke domain scoped tokens https://review.openstack.org/107194 | 18:20 |
henrynash | raildo: 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 |
henrynash | raildo: this is my big disconnect…unless we change the domain construct, I don’t see how hierachial projects help | 18:21 |
raildo | henrynash: 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 |
henrynash | but she can do that today without a hieracy | 18:22 |
henrynash | raildo: but she can do that today without a hierachy | 18:23 |
openstackgerrit | Sam Leong proposed a change to openstack/keystone: Disable a domain will revoke domain scoped tokens https://review.openstack.org/107194 | 18:24 |
*** gabriel-bezerra has quit IRC | 18:25 | |
openstackgerrit | Sam Leong proposed a change to openstack/keystone: Disable a domain will revoke domain scoped tokens https://review.openstack.org/107194 | 18:25 |
openstackgerrit | Sam Leong proposed a change to openstack/keystone: Disable a domain will revoke domain scoped tokens https://review.openstack.org/107194 | 18:26 |
*** gabriel-bezerra has joined #openstack-keystone | 18:26 | |
raildo | henrynash: 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 IRC | 18:27 | |
*** thedodd has quit IRC | 18:28 | |
henrynash | raildo: 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 IRC | 18:33 | |
*** marcoemorais has joined #openstack-keystone | 18:33 | |
openstackgerrit | A change was merged to openstack/keystone: Fixes a Python3 syntax error https://review.openstack.org/102734 | 18:34 |
*** hrybacki has joined #openstack-keystone | 18:35 | |
*** harlowja has joined #openstack-keystone | 18:35 | |
*** hrybacki_ has joined #openstack-keystone | 18:37 | |
*** mgarza has joined #openstack-keystone | 18:38 | |
*** diegows has quit IRC | 18:38 | |
dstanek | ayoung: sg version starts on line 48 - https://gist.github.com/dstanek/94a4142a097c92cf9002 | 18:39 |
*** hrybacki has quit IRC | 18:40 | |
ayoung | dstanek, will look in a moment. Elbows deep in the client right now | 18:40 |
raildo | henrynash: OK, i will try explain better the use case | 18:42 |
henrynash | raildo: great | 18:42 |
*** marcoemorais has quit IRC | 18:48 | |
*** marcoemorais has joined #openstack-keystone | 18:48 | |
*** diegows has joined #openstack-keystone | 18:50 | |
*** erecio has quit IRC | 18:52 | |
*** chandankumar has quit IRC | 18:52 | |
*** gabriel-bezerra has quit IRC | 18:52 | |
*** chandankumar has joined #openstack-keystone | 18:53 | |
*** gabriel-bezerra has joined #openstack-keystone | 18:54 | |
ayoung | dstanek, ah...client stuff is going to take way too long, OK let me take a look | 18:56 |
*** bklei has joined #openstack-keystone | 18:56 | |
ayoung | dstanek, so the *Module classes is where you are registering the factories? | 18:57 |
dstanek | ayoung: where is where you wire up the objects and say which concrete implementation should be used with an interface | 18:59 |
ayoung | So to get an instance of a FileLogger, I need to know that I have to call Injector(FileModule()).get_instance(DomainObject) | 19:00 |
dstanek | so when the framework goes to create an object is looks at the types it expects and finds the concrete mapping | 19:00 |
ayoung | How would I say, without knowing that, give me a Logger? | 19:00 |
dstanek | if you want a FileLogger you can say 'injector.get_instance(FileLogger)' | 19:01 |
dstanek | in the given example DomainObject needs a logger - and the FileModule wires it up to use the FileLogger | 19:01 |
*** gabriel-bezerra has quit IRC | 19:01 | |
dstanek | the idea of the injector is that it gives you the entire fulfilled dependency graph | 19:02 |
*** thedodd has joined #openstack-keystone | 19:02 | |
*** gabriel-bezerra has joined #openstack-keystone | 19:02 | |
*** henrynash has quit IRC | 19:04 | |
openstackgerrit | guang-yee proposed a change to openstack/keystone-specs: X.509 SSL certificate authentication https://review.openstack.org/105913 | 19:08 |
*** afazekas has joined #openstack-keystone | 19:12 | |
ayoung | dstanek, looks right.... | 19:18 |
*** afazekas has quit IRC | 19:21 | |
*** nkinder has quit IRC | 19:37 | |
*** jsavak has joined #openstack-keystone | 19:38 | |
*** joesavak has quit IRC | 19:39 | |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Initial implementation of validator https://review.openstack.org/86483 | 19:46 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Policy V3 API https://review.openstack.org/104065 | 19:46 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Catalog V3 resources https://review.openstack.org/96266 | 19:46 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Assignment V3 resources https://review.openstack.org/86484 | 19:46 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Trust V3 API https://review.openstack.org/104066 | 19:46 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Credential V3 https://review.openstack.org/98522 | 19:46 |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Only conditionally import working keyring https://review.openstack.org/107719 | 19:49 |
openstackgerrit | A change was merged to openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/106232 | 19:51 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Initial implementation of validator https://review.openstack.org/86483 | 19:56 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Policy V3 API https://review.openstack.org/104065 | 19:56 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Catalog V3 resources https://review.openstack.org/96266 | 19:56 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Assignment V3 resources https://review.openstack.org/86484 | 19:56 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Trust V3 API https://review.openstack.org/104066 | 19:56 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Credential V3 https://review.openstack.org/98522 | 19:56 |
morganfainberg | lbragstad, spam! :) | 19:56 |
lbragstad | morganfainberg: WHOOP! | 19:56 |
*** chandankumar has quit IRC | 19:56 | |
* lbragstad watches for flying nerf darts from dolphm | 19:56 | |
morganfainberg | yeah you gotta watchf ro that now, dontcha | 19:57 |
dolphm | lbragstad: apparently gerrit sucks at unicode | 19:57 |
dstanek | dolphm: everybody sucks at unicode! | 19:57 |
dolphm | lbragstad: i actually had alphba-betta-gamma-delta in the unicode string here https://review.openstack.org/#/c/86483/27/keystone/tests/test_validation.py | 19:57 |
*** jsavak has quit IRC | 19:57 | |
dolphm | lbragstad: not just question marks, which is what it's showing up as now for me | 19:57 |
morganfainberg | dolphm, that doesn't surprise me (re: gerrit and unicode) | 19:58 |
dolphm | lbragstad: u'αβγδ' | 19:58 |
lbragstad | ah.. really? | 19:58 |
dolphm | lbragstad: yeah - i wanted a test that would have failed against one of the earlier patchsets with the regex | 20:00 |
morganfainberg | hrybacki_, i think the scripts that generate those sample.jsons are in the same directory | 20:00 |
morganfainberg | hrybacki_, if you just pipe the output through | python -mjson.tool' | 20:00 |
hrybacki_ | morganfainberg: ++ | 20:00 |
morganfainberg | hrybacki_, it should be good | 20:00 |
morganfainberg | *should* | 20:00 |
dolphm | lbragstad: 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 list | 20:01 |
morganfainberg | hrybacki_, 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 |
morganfainberg | hrybacki_, :) | 20:01 |
hrybacki_ | sure -- when/where is the generating script called? During setup of keystone/client/middleware? | 20:02 |
morganfainberg | hrybacki_, i think it's called out-of-band just whenever we want to do an update? | 20:02 |
morganfainberg | hrybacki_, as in.. we've run it a handful of times at best | 20:03 |
hrybacki_ | morganfainberg: ohhh. okay | 20:03 |
morganfainberg | hrybacki_, 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" list | 20:04 |
dolphm | morganfainberg: 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 :P | 20:04 |
morganfainberg | dolphm, does it involve chezburgerz? | 20:04 |
hrybacki_ | morganfainberg: how to test that... hrm | 20:04 |
morganfainberg | hrybacki_, yeah no worries if you don't get to it | 20:04 |
dolphm | morganfainberg: no but i know what's for dinner all the sudden | 20:04 |
morganfainberg | hrybacki_, we can circle back in J3 for that | 20:04 |
ayoung | I gave up on the scripts getting in | 20:05 |
morganfainberg | dolphm, 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 |
morganfainberg | ayoung, ah i thought we merged the scripts too | 20:05 |
dolphm | morganfainberg: there's a subsequent patch to change it to that if that's approved/etc | 20:05 |
hrybacki_ | morganfainberg: should I put something in launchpad for the tests? Is that worthy of that sort of thing | 20:05 |
morganfainberg | dolphm, ah ok cool | 20:06 |
ayoung | morganfainberg, the client scripts? | 20:06 |
ayoung | Nope | 20:06 |
morganfainberg | hrybacki_, ah, nvm if we didn't merge the scripts strike it as something to worry about | 20:06 |
dolphm | morganfainberg: 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 anyway | 20:07 |
morganfainberg | hrybacki_, the script part | 20:07 |
*** gabriel-bezerra has quit IRC | 20:07 | |
morganfainberg | hrybacki_, not just validating the data | 20:07 |
hrybacki_ | AH | 20:07 |
hrybacki_ | got it | 20:07 |
*** gabriel-bezerra has joined #openstack-keystone | 20:07 | |
hrybacki_ | morganfainberg: will those ever be merged? | 20:07 |
morganfainberg | hrybacki_, the scripts aren't merged so don't worry about them. validating those .json files is cake in comparison | 20:07 |
morganfainberg | hrybacki_, uh. hopefully :P but not right now | 20:08 |
morganfainberg | ayoung, 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 |
ayoung | morganfainberg, no, you've broken my spirit | 20:09 |
ayoung | :) | 20:09 |
morganfainberg | ayoung, HAH | 20:09 |
lbragstad | dolphm: I can do that | 20:09 |
ayoung | my focus is on Client right now. Its a mess. | 20:09 |
ayoung | The scripts are handy in exercising it | 20:09 |
morganfainberg | ayoung, right | 20:09 |
hrybacki_ | ayoung: you break my spirit too :) it's okay -- adapt, overcome, excel. Right? :P | 20:09 |
ayoung | Instigate and Escalate is the way I remember it. | 20:10 |
hrybacki_ | Hah, OLC and PLDC must have their differences | 20:10 |
morganfainberg | dolphm, https://review.openstack.org/#/c/106893/6/keystone/tests/test_v3_catalog.py assertValidError isn't needed there? | 20:10 |
morganfainberg | assertValidErrorResponse | 20:10 |
hrybacki_ | morganfainberg: do you still want a test suite for the validity of the json examples? | 20:11 |
morganfainberg | hrybacki_, if you get a chance, it would be good :) | 20:11 |
morganfainberg | hrybacki_, but it can happen in J3 or whenever, it would be a nice-to-have | 20:11 |
ayoung | USMA and IOBC actually | 20: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 difficult | 20:12 |
*** bvandenh has quit IRC | 20:12 | |
hrybacki_ | ayoung: mad respect -- I couldn't have done USMA | 20:13 |
ayoung | hrybacki_, and nowadays I don't know if I would get in | 20:13 |
ayoung | You know a school is good when you still have nightmares induced by it 20+ years later | 20:14 |
hrybacki_ | ayoung: I only know one person who went -- she was a beast, physically and mentally | 20:14 |
morganfainberg | dolphm, +2 on the catalog bit | 20:17 |
ayoung | What 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 |
morganfainberg | dolphm, 2 in-line questions/comments but i'm fine with it as is. | 20:17 |
david-lyle | ayoung? | 20:17 |
ayoung | https://ayoungf20packstack.cloudlab.freeipa.org/keystone/main/v2.0/auth/tokens | 20:17 |
ayoung | david-lyle, heh...I'm a hacking | 20:18 |
morganfainberg | david-lyle, i see you use the same trick I do, get notifications on someone saying your project's name | 20:18 |
ayoung | david-lyle, you don't really want to know....its along the lines of Laws and Sausages.... | 20:18 |
morganfainberg | david-lyle, ;) | 20:18 |
david-lyle | ayoung :) | 20:18 |
ayoung | david-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 reason | 20:19 |
ayoung | very likely something I did | 20:19 |
david-lyle | morganfainberg: I'm not that sophisticated sadly, I was trolling trying to figure out a way to domain admin role with current keystone policy engine | 20:19 |
morganfainberg | david-lyle, ah | 20:19 |
ayoung | see 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-A | 20:20 |
ayoung | david-lyle, policy.json with the cloudsampleversion | 20:20 |
ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n7 | 20:21 |
david-lyle | ayoung: are you setting the OPENSTACK_API_VERSION for identity in local_settings.py? | 20:21 |
ayoung | AHHHH PANDORA, STOP PLAYING URLS for REPORTING UNLICENSED OFFICE SOFTWARE! | 20:21 |
ayoung | david-lyle, I don't think so | 20:21 |
david-lyle | ayoung, I don't think that actually works there's no domain info that get's added to the creds | 20:22 |
ayoung | david-lyle, Default domain for V2 tokens | 20:22 |
david-lyle | ayoung: https://github.com/openstack/horizon/blob/master/openstack_dashboard/local/local_settings.py.example#L36 | 20:23 |
*** henrynash has joined #openstack-keystone | 20:23 | |
ayoung | david-lyle, actually, I do have: OPENSTACK_API_VERSIONS = { | 20:23 |
ayoung | "identity": 3 | 20:23 |
ayoung | } | 20:23 |
ayoung | david-lyle, my code is pretty different from the original D-O-A code...let me see what is actually triggereing it | 20:24 |
ayoung | david-lyle, I've evn hacked def get_keystone_version(): | 20:25 |
ayoung | return getattr(settings, 'OPENSTACK_API_VERSIONS', {}).get('identity', 3.0) | 20:25 |
ayoung | OK...I have a < where I should hava > | 20:25 |
* ayoung duncecap | 20:25 | |
dstanek | ok, i've spent almost an hour looking at a weird dependency issue - http://dpaste.com/3Y8T7G8 | 20:26 |
dstanek | it seems that 'super(class, self).__init__' is actually the wrapper function - no idea why | 20:26 |
*** bvandenh has joined #openstack-keystone | 20:27 | |
dstanek | in my simple test cases this doesn't happen | 20:27 |
openstackgerrit | Dolph Mathews proposed a change to openstack/python-keystoneclient: use embedded URLs for hyperlinks in the README https://review.openstack.org/103636 | 20:28 |
ayoung | dstanek, loking | 20:28 |
ayoung | looking | 20:28 |
*** nkinder has joined #openstack-keystone | 20:30 | |
ayoung | dstanek, is it possible that super(class, self).__init__ is not the wrapper, but rather the wrapper is triggered by a calling it? | 20:31 |
dstanek | ayoung: no, i printed the value to see what it was | 20:31 |
ayoung | yuck | 20:31 |
ayoung | dstanek, this is because the ec2 controller @depends on the controller? | 20:32 |
*** jvrbanac has left #openstack-keystone | 20:35 | |
dolphm | henrynash: followed up on https://review.openstack.org/#/c/106893/ | 20:37 |
*** arunkant has quit IRC | 20:39 | |
henrynash | dolphm: ok, yep - fine, just +2/A | 20:39 |
dolphm | henrynash: thanks! | 20:39 |
*** lbragstad has quit IRC | 20:39 | |
*** hrybacki_ is now known as hrybacki | 20:39 | |
dstanek | ayoung: i don't think so, but who knows | 20:39 |
dstanek | ayoung: i need a break from this...bbiab | 20:43 |
*** arunkant has joined #openstack-keystone | 20:49 | |
openstackgerrit | Sam Leong proposed a change to openstack/keystone: Disable a domain will revoke domain scoped tokens https://review.openstack.org/107194 | 20:54 |
*** arunkant has quit IRC | 20:54 | |
*** arunkant has joined #openstack-keystone | 20:55 | |
*** bvandenh has quit IRC | 20:58 | |
henrynash | ayoung: btw, did you intend for there to be two separate specs for policy by endpoint? | 21:06 |
henrynash | ayoung: 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 |
ayoung | henrynash, I thik I had some vague notion that they were slightly different | 21:08 |
ayoung | henrynash, we need at least 2 specs | 21:09 |
ayoung | one for fetching policy, on for assigning | 21:09 |
henrynash | ayoung: ok, agrred | 21:09 |
ayoung | the assigning part is what we need to nail down, as fetching will accept endpoint Id as a way to disabuiatify | 21:09 |
ayoung | sorry, typo | 21:09 |
*** gabriel-bezerra has quit IRC | 21:09 | |
*** lbragstad has joined #openstack-keystone | 21:10 | |
ayoung | should have read disambiguiatify | 21:10 |
*** gabriel-bezerra has joined #openstack-keystone | 21:10 | |
henrynash | ayoung: ok | 21:11 |
*** lbragstad has quit IRC | 21:14 | |
*** lbragstad has joined #openstack-keystone | 21:18 | |
* morganfainberg glares at requirements gate job that is > 1 hr and only 50% done. | 21:22 | |
morganfainberg | because i need the keystone change behind it to merge before i can fix the next in the chain | 21:22 |
*** shakamunyi_ has quit IRC | 21:24 | |
lbragstad | dolphm: yeah, the validation stuff breaks on unicode.... hard | 21:29 |
dolphm | lbragstad: is it jsonschema's fault? | 21:29 |
*** rodrigods has quit IRC | 21:29 | |
lbragstad | dolphm: I *think* so... doing some checking | 21:30 |
lbragstad | dolphm: this says differently though: http://spacetelescope.github.io/understanding-json-schema/reference/string.html | 21:31 |
dolphm | lbragstad: what's the failure you're seeing? | 21:31 |
lbragstad | dolphm: http://paste.openstack.org/show/87486/ | 21:32 |
lbragstad | dolphm: test case: http://paste.openstack.org/show/87487/ | 21:33 |
dolphm | lbragstad: i can barely read the first paste http://paste.openstack.org/raw/87486/ | 21:34 |
lbragstad | yeah.. it's messed up | 21:36 |
lbragstad | encoding issues or something... | 21:36 |
*** henrynash has quit IRC | 21:37 | |
*** topol has quit IRC | 21:39 | |
openstackgerrit | A change was merged to openstack/keystone: Example JSON files should be human-readable https://review.openstack.org/108212 | 21:43 |
openstackgerrit | A change was merged to openstack/keystone: implement GET /v3/catalog https://review.openstack.org/106893 | 21:44 |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements https://review.openstack.org/106208 | 21:46 |
morganfainberg | dolphm, do you see https://review.openstack.org/#/c/107560 in zuul? i'm not seeing it, like the gate job ... disappeared? | 21:50 |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/106210 | 21:50 |
morganfainberg | dolphm, nvm just issued a reverify | 21:51 |
dolphm | morganfainberg: i've seen that happen before... lost messages? | 21:51 |
morganfainberg | dolphm, no, 100% success on check, just... no gate score and not in queue | 21:51 |
morganfainberg | it i'll rebase it while i'm at it. need it rebased anyway | 21:52 |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Mark the 'check_vX_token' methods deprecated https://review.openstack.org/107560 | 21:52 |
dolphm | morganfainberg: +A | 21:55 |
morganfainberg | dolphm, cool | 21:55 |
* morganfainberg now goes and rebases the persistence change. | 21:55 | |
*** gabriel-bezerra has quit IRC | 21:58 | |
*** gabriel-bezerra has joined #openstack-keystone | 21:59 | |
*** dims has quit IRC | 22:01 | |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Move token persistence classes to token.persistence module https://review.openstack.org/107561 | 22:01 |
*** rwsu has quit IRC | 22:02 | |
stevemar | morganfainberg, dolphm did we somehow lose endpoint id's in the service catalog w.r.t. keystonemiddleware | 22:04 |
dolphm | lbragstad: got a fix for you | 22:04 |
lbragstad | dolphm: ? | 22:05 |
lbragstad | dolphm: I'm still screwing with it, what did you do? | 22:05 |
morganfainberg | stevemar, ? | 22:05 |
dolphm | lbragstad: http://pastebin.com/raw.php?i=hESMWC5y | 22:05 |
morganfainberg | stevemar, are you seeing endpoint IDs in the middleware from keystoneclient and not from keystonemiddleware? | 22:06 |
dolphm | lbragstad: you have to tell python that the source contains unicode pep 263 http://legacy.python.org/dev/peps/pep-0263/ | 22:06 |
stevemar | morganfainberg, if it's not ringing any bells, dont worry, i'll have to actually dig into the problem | 22:07 |
stevemar | morganfainberg, that is what a colleague is saying | 22:07 |
morganfainberg | yeah not ringing a bell | 22:07 |
*** hrybacki has quit IRC | 22:07 | |
morganfainberg | that seems unlikely | 22:07 |
morganfainberg | but stranger things have occured | 22:07 |
*** marekd has quit IRC | 22:08 | |
stevemar | morganfainberg, 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's | 22:09 |
morganfainberg | stevemar, i wouldn't be surprised it that was the case. | 22:09 |
stevemar | which makes me think auth token middleware | 22:09 |
lbragstad | dolphm: so you added the encoding to the file? | 22:09 |
morganfainberg | middleware might squash that out | 22:09 |
*** marekd has joined #openstack-keystone | 22:09 | |
stevemar | morganfainberg, why would it? | 22:09 |
morganfainberg | stevemar, but i don't think it's something that has changed from keystonecleint -> keystonemiddleware | 22:09 |
dolphm | lbragstad: yep, just put # -*- coding: utf-8 -*- on L1 | 22:09 |
*** gmurphy has quit IRC | 22:09 | |
stevemar | morganfainberg, i'm not sure which one he's using | 22:10 |
morganfainberg | stevemar, we have code to do some explicit v3->v2 catalog stuff and not all catalogs have endpoint ids? | 22:10 |
morganfainberg | stevemar, shouldn't matter which he uses. results should be the same | 22:10 |
lbragstad | dolphm: gotcha, didn't see that top line there | 22:10 |
morganfainberg | stevemar, fairly certain templated catalog wont have IDs | 22:10 |
stevemar | https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L385 | 22:11 |
lbragstad | dolphm: sweet, good catch, works now. Pushing the initial implementation | 22:14 |
dolphm | lbragstad: woot | 22:14 |
lbragstad | dolphm: thoughts on https://review.openstack.org/#/c/86483/28/keystone/tests/test_validation.py ? | 22:15 |
lbragstad | looks like henry left | 22:16 |
*** gabriel-bezerra has quit IRC | 22:16 | |
dolphm | lbragstad: he's correct | 22:16 |
dolphm | lbragstad: it's in pep257 | 22:16 |
dolphm | lbragstad: which i just realized he linked to :P | 22:16 |
*** gabriel-bezerra has joined #openstack-keystone | 22:16 | |
lbragstad | http://legacy.python.org/dev/peps/pep-0257/#multi-line-docstrings | 22:16 |
stevemar | morganfainberg, would keystone still return endpoint id's if using the templated catalog? | 22:16 |
morganfainberg | stevemar, don't think so, but middleware might collapse to lowest common featureset? honestly haven't looked | 22:17 |
morganfainberg | stevemar, let me know if you need help digging into that - i need food. | 22:17 |
* morganfainberg goes for a late lunch | 22:17 | |
morganfainberg | very late | 22:18 |
stevemar | morganfainberg, yeah, i think middleware narrows down to common elements | 22:18 |
dolphm | lbragstad: """Exception raised when passing a string of 255+ chars. | 22:19 |
dolphm | lbragstad: summarize in the first line then elaborate in a paragraph if you want | 22:19 |
*** bknudson has quit IRC | 22:20 | |
*** gabriel-bezerra has quit IRC | 22:21 | |
lbragstad | dolphm: sounds good, breaking them apart now | 22:21 |
*** gabriel-bezerra has joined #openstack-keystone | 22:21 | |
*** packet has quit IRC | 22:25 | |
*** cjellick has quit IRC | 22:25 | |
*** dims has joined #openstack-keystone | 22:28 | |
*** cjellick has joined #openstack-keystone | 22:31 | |
*** cjellick has quit IRC | 22:31 | |
*** cjellick has joined #openstack-keystone | 22:31 | |
*** cjellick has quit IRC | 22:32 | |
*** cjellick has joined #openstack-keystone | 22:32 | |
*** dims has quit IRC | 22:32 | |
*** henrynash has joined #openstack-keystone | 22:33 | |
openstackgerrit | guang-yee proposed a change to openstack/keystone: X.509 SSL certificate authentication plugin https://review.openstack.org/103736 | 22:33 |
*** thedodd has quit IRC | 22:41 | |
*** stevemar has quit IRC | 22:44 | |
*** browne has joined #openstack-keystone | 22:44 | |
*** browne has left #openstack-keystone | 22:45 | |
*** henrynash has quit IRC | 22:52 | |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Initial implementation of validator https://review.openstack.org/86483 | 22:52 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Policy V3 API https://review.openstack.org/104065 | 22:52 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Catalog V3 resources https://review.openstack.org/96266 | 22:52 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Assignment V3 resources https://review.openstack.org/86484 | 22:52 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Trust V3 API https://review.openstack.org/104066 | 22:52 |
openstackgerrit | Lance Bragstad proposed a change to openstack/keystone: Implement validation on Credential V3 https://review.openstack.org/98522 | 22:52 |
*** shakamunyi_ has joined #openstack-keystone | 22:53 | |
*** lbragsta_ has joined #openstack-keystone | 22:54 | |
*** lbragstad has quit IRC | 22:58 | |
*** lbragsta_ has quit IRC | 22:59 | |
*** nkinder has quit IRC | 23:01 | |
*** gmurphy has joined #openstack-keystone | 23:17 | |
*** marcoemorais has quit IRC | 23:20 | |
*** marcoemorais has joined #openstack-keystone | 23:21 | |
*** marcoemorais has quit IRC | 23:21 | |
*** marcoemorais has joined #openstack-keystone | 23:21 | |
*** david-lyle has quit IRC | 23:24 | |
*** bknudson has joined #openstack-keystone | 23:28 | |
*** dims has joined #openstack-keystone | 23:28 | |
*** KimJ has quit IRC | 23:29 | |
*** shakamunyi_ has quit IRC | 23:33 | |
*** dims has quit IRC | 23:33 | |
*** jamielennox|away is now known as jamielennox | 23:36 | |
*** ncoghlan has joined #openstack-keystone | 23:36 | |
*** browne has joined #openstack-keystone | 23:41 | |
openstackgerrit | Jamie Lennox proposed a change to openstack/keystone-specs: Add a catalog to an unscoped token https://review.openstack.org/107333 | 23:43 |
*** mgarza has quit IRC | 23:45 | |
*** gabriel-bezerra has quit IRC | 23:45 | |
*** gabriel-bezerra has joined #openstack-keystone | 23:46 | |
*** nkinder has joined #openstack-keystone | 23:54 | |
jamielennox | dolphm: 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!