| *** spandhe has quit IRC | 00:06 | |
| *** zzzeek has quit IRC | 00:09 | |
| *** lhcheng has quit IRC | 00:11 | |
| *** gyee has quit IRC | 00:23 | |
| *** vilobhmm has quit IRC | 00:24 | |
| *** ncoghlan has joined #openstack-keystone | 00:24 | |
| *** jamielennox|away is now known as jamielennox | 00:35 | |
| *** jasondotstar has quit IRC | 00:39 | |
| *** kfox1111 has quit IRC | 00:43 | |
| *** dims has joined #openstack-keystone | 00:43 | |
| *** tqtran has quit IRC | 00:51 | |
| *** rdo has quit IRC | 00:52 | |
| *** rdo has joined #openstack-keystone | 00:54 | |
| *** jamielennox is now known as jamielennox|away | 01:00 | |
| *** lastops has joined #openstack-keystone | 01:05 | |
| *** jamielennox|away is now known as jamielennox | 01:08 | |
| *** lastops has quit IRC | 01:10 | |
| *** timsim has joined #openstack-keystone | 01:12 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Refactor _confirm_token_bind takes AccessInfo https://review.openstack.org/179676 | 01:15 |
|---|---|---|
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Extract basic validation processing to base class https://review.openstack.org/180818 | 01:15 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Separate the fetch and validate token processes https://review.openstack.org/190940 | 01:15 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Make token bind work with a request https://review.openstack.org/180817 | 01:15 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Don't cache signed tokens https://review.openstack.org/190941 | 01:15 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Create a simple base class from AuthProtocol https://review.openstack.org/180816 | 01:15 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Rename _LOG to log in auth_token middleware https://review.openstack.org/192948 | 01:15 |
| jamielennox | dstanek: I reorganized the above a little bit, hopefully they are grouped in a way that is more logical and we can get some movement | 01:16 |
| openstackgerrit | Merged openstack/python-keystoneclient: Removes unused debug logging code https://review.openstack.org/186994 | 01:18 |
| openstackgerrit | Merged openstack/keystonemiddleware: Remove install_venv_common and fix typo in memorycache https://review.openstack.org/189113 | 01:19 |
| *** roxanaghe has quit IRC | 01:19 | |
| *** Kennan has quit IRC | 01:22 | |
| *** Kennan has joined #openstack-keystone | 01:23 | |
| *** browne has quit IRC | 01:26 | |
| *** vilobhmm has joined #openstack-keystone | 01:29 | |
| *** fangzhou has quit IRC | 01:38 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Support discovery on the AUTH_INTERFACE https://review.openstack.org/191641 | 01:47 |
| *** _cjones_ has quit IRC | 01:53 | |
| *** woodster_ has quit IRC | 02:01 | |
| openstackgerrit | Merged openstack/python-keystoneclient: Use python-six shim for assertRaisesRegex/p https://review.openstack.org/188774 | 02:12 |
| *** browne has joined #openstack-keystone | 02:12 | |
| *** jamielennox is now known as jamielennox|away | 02:20 | |
| *** rushiagr_away is now known as rushiagr | 02:29 | |
| *** dims has quit IRC | 02:32 | |
| *** dims has joined #openstack-keystone | 02:33 | |
| *** dims has quit IRC | 02:41 | |
| *** fangzhou has joined #openstack-keystone | 02:46 | |
| *** spandhe has joined #openstack-keystone | 02:53 | |
| *** kiran-r has joined #openstack-keystone | 03:01 | |
| *** stevemar has joined #openstack-keystone | 03:01 | |
| *** ChanServ sets mode: +v stevemar | 03:01 | |
| *** kiran-r has quit IRC | 03:01 | |
| *** davechen has joined #openstack-keystone | 03:03 | |
| *** jamielennox|away is now known as jamielennox | 03:03 | |
| *** davechen1 has joined #openstack-keystone | 03:09 | |
| *** davechen has quit IRC | 03:12 | |
| *** arunkant__ has joined #openstack-keystone | 03:13 | |
| *** jamielennox is now known as jamielennox|away | 03:15 | |
| *** kiran-r has joined #openstack-keystone | 03:15 | |
| *** kiran-r has quit IRC | 03:15 | |
| *** kiran-r has joined #openstack-keystone | 03:15 | |
| *** fangzhou has quit IRC | 03:16 | |
| *** arunkant__ has quit IRC | 03:17 | |
| *** woodster_ has joined #openstack-keystone | 03:18 | |
| *** jamielennox|away is now known as jamielennox | 03:25 | |
| *** rushiagr is now known as rushiagr_away | 03:26 | |
| *** spandhe has quit IRC | 03:43 | |
| *** rushiagr_away is now known as rushiagr | 03:44 | |
| *** richm has quit IRC | 03:45 | |
| *** diazjf has joined #openstack-keystone | 03:46 | |
| *** rushiagr is now known as rushiagr_away | 03:47 | |
| *** tobe has joined #openstack-keystone | 03:49 | |
| *** jaosorior has joined #openstack-keystone | 03:57 | |
| *** kiran-r has quit IRC | 04:39 | |
| *** kiran-r has joined #openstack-keystone | 04:39 | |
| *** boris-42 has joined #openstack-keystone | 04:44 | |
| *** clayton has quit IRC | 04:50 | |
| *** vilobhmm has quit IRC | 04:56 | |
| *** dvorak has joined #openstack-keystone | 05:00 | |
| openstackgerrit | Fernando Diaz proposed openstack/keystone: Adding Documentation for Mapping Combinations https://review.openstack.org/192850 | 05:01 |
| *** vilobhmm has joined #openstack-keystone | 05:02 | |
| stevemar | diazjf, yay! | 05:03 |
| diazjf | whoop thanks! | 05:05 |
| morganfainberg | jamielennox: not sure how we can break Oslo.config out of keystoneauth | 05:06 |
| morganfainberg | But I think that is one of the last real hang ups. | 05:06 |
| jamielennox | morganfainberg: Oslo.config actually has very few deps | 05:06 |
| jamielennox | i was thinking i can do it, it would essentially be a copy of the oslo.types or whatever package | 05:07 |
| morganfainberg | Yeah, but do we really need it? | 05:07 |
| jamielennox | morganfainberg: i think i can get around it | 05:07 |
| morganfainberg | If like to remove the last of the Oslo packages from ksa | 05:07 |
| jamielennox | especially with the split | 05:07 |
| morganfainberg | i'd* | 05:07 |
| jamielennox | with the split all the options are going to come from a different class and there will be one helper method that redirects the old function of get_options to the one on the class | 05:08 |
| jamielennox | so if it's going to be one method we would just need a function there that converts from whatever new option definition we come up with to the old oslo.config one | 05:08 |
| jamielennox | which i guess we would need anyway for loading from config | 05:08 |
| morganfainberg | Right | 05:09 |
| *** Kennan has quit IRC | 05:09 | |
| *** Kennan has joined #openstack-keystone | 05:10 | |
| jamielennox | i haven't gotten to what that option interface would look like yet | 05:10 |
| morganfainberg | And the accessinfo dict interface. | 05:11 |
| morganfainberg | That one looks wrong somehow. Not sure why | 05:11 |
| jamielennox | yea, i wasn't sure what to do there | 05:13 |
| jamielennox | so to make it compatible with ksc (and probably just anyway) we would need to expose the whole token dict somehow | 05:13 |
| morganfainberg | Is there any way around that? | 05:16 |
| morganfainberg | Assuming we're going to have a ksc 2.0 for using keystoneauth. | 05:16 |
| *** kiran-r has quit IRC | 05:17 | |
| morganfainberg | At this point I think... We are going to be safe-ish breaking compat with the stable branches. | 05:17 |
| morganfainberg | Seriously looking at dropping cli in ksc 2.0 as well. | 05:17 |
| *** diazjf has quit IRC | 05:19 | |
| openstackgerrit | Merged openstack/keystone: Fix tests failing on slower system https://review.openstack.org/190790 | 05:21 |
| *** jamielennox is now known as jamielennox|away | 05:23 | |
| *** jamielennox|away is now known as jamielennox | 05:26 | |
| jamielennox | morganfainberg: what was the last thing I said? i'm having some connection issues today | 05:29 |
| stevemar | jamielennox, "so to make it compatible with ksc (and probably just anyway) we would need to expose the whole token dict somehow" | 05:31 |
| jamielennox | and allow people to write to it from ksc | 05:31 |
| jamielennox | so i was coming up with some way of having like an overrides dict in the ksc object such that if it were set pull from there instead of going to super... | 05:31 |
| jamielennox | i'm not sure it saves us much because there are still times when you may legitimately want to get access to the raw token dictionary | 05:32 |
| stevemar | morganfainberg, drop it drop it drop it | 05:32 |
| jamielennox | stevemar: which bit | 05:33 |
| stevemar | CLI from ksc | 05:34 |
| stevemar | jamielennox, you may have missed morganfainberg mention that | 05:34 |
| jamielennox | oh - yea, i didn't see any convo after the last i said | 05:34 |
| stevemar | jamielennox, he wrote "Seriously looking at dropping cli in ksc 2.0 as well." | 05:35 |
| jamielennox | oh, sure - do it | 05:35 |
| jamielennox | morganfainberg: why did we call the middleware release 2.0? | 05:35 |
| morganfainberg | Requirements update. | 05:35 |
| morganfainberg | Middleware, ksc, | 05:35 |
| morganfainberg | Etc is all now released by the rel management team. Not the PtL | 05:36 |
| jamielennox | but 2.0? | 05:36 |
| morganfainberg | Yep. | 05:36 |
| morganfainberg | And when we move to keystoneauth, we will have 3.0 | 05:36 |
| jamielennox | lol, if they bump major version for every requirements update this is going to get crazy | 05:36 |
| morganfainberg | Keystone is moving to version 8.0.0 this cycle. | 05:36 |
| jamielennox | yuk | 05:37 |
| stevemar | yeah, we'll be at 18 in no time | 05:37 |
| jamielennox | instead of 2015.2 | 05:37 |
| jamielennox | ? | 05:37 |
| morganfainberg | We're drastically changing the versioning. Ksa will be more sane. | 05:37 |
| morganfainberg | jamielennox: yep. | 05:37 |
| stevemar | i dont mind keystone at 8.0.0, it only goes up 2 per year | 05:37 |
| morganfainberg | Ksm should be 2x bumps a year as well. | 05:37 |
| jamielennox | i like the year numbering schemes for things with fixed release schedules | 05:37 |
| morganfainberg | Since we are releasing in sync with the servers. | 05:38 |
| jamielennox | not sure how that plays with pypi though | 05:38 |
| morganfainberg | I'm letting rel | 05:38 |
| morganfainberg | Management team handle that. | 05:38 |
| *** chlong has quit IRC | 05:38 | |
| *** belmoreira has joined #openstack-keystone | 05:52 | |
| *** chlong has joined #openstack-keystone | 05:53 | |
| *** Kennan has quit IRC | 05:58 | |
| *** Kennan has joined #openstack-keystone | 06:01 | |
| *** vilobhmm1 has joined #openstack-keystone | 06:04 | |
| *** Kennan has quit IRC | 06:06 | |
| *** Kennan has joined #openstack-keystone | 06:06 | |
| *** vilobhmm has quit IRC | 06:07 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex https://review.openstack.org/192983 | 06:09 |
| *** spandhe has joined #openstack-keystone | 06:19 | |
| morganfainberg | jamielennox: I almost want to say glance should stop using swift client. | 06:19 |
| morganfainberg | jamielennox: as a response to your email. Just stop using it if the team isn't putting effort into it. | 06:20 |
| morganfainberg | Ostensibly the amount of actions glance needs to perform on swift is minimal. | 06:20 |
| jamielennox | morganfainberg: right, i essentially got started on doing exactly that because it's not a whole lot of effort on top of a session | 06:21 |
| jamielennox | and the swiftclient interace is horrible | 06:21 |
| morganfainberg | Yeah. | 06:21 |
| jamielennox | most of the functions have like headers= or querystring= | 06:21 |
| morganfainberg | So I'm going to respond with that. Because e it just looks like the only option. | 06:21 |
| jamielennox | expecting users to construct what they want to pass through rather than deal with all there options | 06:21 |
| jamielennox | however even doing that requires glance to figure out how they want to save their authentication options and deprecate the stupid http://user:tenant:password@auth_uri syntax | 06:22 |
| jamielennox | so i figured i may as well send the email now | 06:22 |
| jamielennox | morganfainberg: i think it was paris where swift decided they were going to wait for SDK rather than do a v2 of their client, but in vancouver it was decided that SDK may not be suitable for service->service communication so we've got to figure something out | 06:23 |
| morganfainberg | Well I'll go out on the limb and say as much that we need to remove the dependence on swift client or swift client needs to grow session support. | 06:24 |
| *** spandhe has quit IRC | 06:24 | |
| *** spandhe_ has joined #openstack-keystone | 06:24 | |
| morganfainberg | I'll send that tonight / tomorrow. | 06:24 |
| jamielennox | sounds good, it's the only one now, i got glanceclient merged the other day | 06:26 |
| jamielennox | but my god, you should read swiftclient - it's horrible | 06:28 |
| jamielennox | morganfainberg: oh - from earlier, are you meaning that we'll have to do a ksc 2 as soon as we merge ksa support so we should consider that feature branch to be 2.0? | 06:30 |
| *** belmoreira has quit IRC | 06:31 | |
| jamielennox | because at the moment it's staying strictly compatible with the existing ksc | 06:31 |
| *** kiran-r has joined #openstack-keystone | 06:34 | |
| *** jaosorior has quit IRC | 06:35 | |
| *** vilobhmm1 has quit IRC | 06:39 | |
| *** bjornar has quit IRC | 06:40 | |
| *** bjornar has joined #openstack-keystone | 06:43 | |
| morganfainberg | Yes | 06:46 |
| morganfainberg | We should make it 2.0 | 06:46 |
| jamielennox | including all the deprecations we want to do as part of that? | 06:48 |
| jamielennox | because really there is no point in half of the compatibility stuff i'm doing then | 06:48 |
| jamielennox | like accessinfo in ksc can just disappear | 06:48 |
| *** woodster_ has quit IRC | 06:51 | |
| *** krykowski has joined #openstack-keystone | 06:59 | |
| *** afazekas has joined #openstack-keystone | 07:00 | |
| *** stevemar has quit IRC | 07:02 | |
| *** spandhe_ has quit IRC | 07:03 | |
| *** e0ne has joined #openstack-keystone | 07:04 | |
| *** rlt_ has joined #openstack-keystone | 07:10 | |
| morganfainberg | jamielennox: hm. | 07:13 |
| morganfainberg | *shrig* it's too late for me to think about that. | 07:13 |
| morganfainberg | Sorry. | 07:13 |
| * morganfainberg looks at the clock. | 07:13 | |
| jamielennox | morganfainberg: no worries, but think about it because there's a lot of effort i'm putting into compatibility | 07:13 |
| morganfainberg | We might need to two step it. Deprecation then gone. | 07:14 |
| * morganfainberg does some terrible two step dance imitation. | 07:14 | |
| jamielennox | morganfainberg: that's what i was expecting, just not major versions in between | 07:16 |
| *** btully has quit IRC | 07:18 | |
| *** browne has quit IRC | 07:18 | |
| *** chlong has quit IRC | 07:18 | |
| *** btully has joined #openstack-keystone | 07:19 | |
| *** e0ne has quit IRC | 07:23 | |
| *** henrynash has joined #openstack-keystone | 07:34 | |
| *** ChanServ sets mode: +v henrynash | 07:34 | |
| evrardjp | good morning everyone | 07:46 |
| openstackgerrit | henry-nash proposed openstack/keystone-specs: Enable listing of role assignments in a project hierarchy https://review.openstack.org/187045 | 07:47 |
| *** boris-42 has quit IRC | 07:52 | |
| *** dguerri` is now known as dguerri | 08:15 | |
| *** viktors|afk is now known as viktors | 08:28 | |
| *** ncoghlan has quit IRC | 08:32 | |
| *** henrynash has quit IRC | 08:32 | |
| *** henrynash has joined #openstack-keystone | 08:33 | |
| *** ChanServ sets mode: +v henrynash | 08:33 | |
| *** tsufiev has quit IRC | 08:40 | |
| *** tsufiev has joined #openstack-keystone | 08:41 | |
| *** dims has joined #openstack-keystone | 08:44 | |
| *** e0ne has joined #openstack-keystone | 08:48 | |
| *** dims has quit IRC | 08:48 | |
| *** davechen1 has left #openstack-keystone | 08:56 | |
| *** e0ne is now known as e0ne_ | 08:58 | |
| *** Nikkau has joined #openstack-keystone | 08:59 | |
| *** e0ne_ is now known as e0ne | 09:00 | |
| *** belmoreira has joined #openstack-keystone | 09:02 | |
| *** kiall has quit IRC | 09:35 | |
| *** Kiall has joined #openstack-keystone | 09:36 | |
| *** aix has joined #openstack-keystone | 09:37 | |
| *** henrynash has quit IRC | 09:48 | |
| *** jasondotstar has joined #openstack-keystone | 09:52 | |
| *** lucasagomes has joined #openstack-keystone | 09:55 | |
| lucasagomes | hi, the last release of keystonemiddleware broke ironic's gate https://bugs.launchpad.net/ironic/+bug/1466405 | 09:55 |
| openstack | Launchpad bug 1466405 in Ironic "broken ACL tests " [Undecided,New] - Assigned to Lucas Alvares Gomes (lucasagomes) | 09:55 |
| lucasagomes | any idea what specifically changed that broke us like that? | 09:56 |
| lucasagomes | it seems 403 ret code have changed to 401 in some cases | 09:56 |
| *** e0ne is now known as e0ne_ | 09:57 | |
| *** e0ne_ is now known as e0ne | 09:59 | |
| *** dims has joined #openstack-keystone | 10:00 | |
| lucasagomes | apparently it has to do with https://review.openstack.org/#/c/174196 | 10:08 |
| *** eandersson has joined #openstack-keystone | 10:09 | |
| *** pnavarro has joined #openstack-keystone | 10:16 | |
| *** aix has quit IRC | 10:21 | |
| samueldmq | morning ! | 10:31 |
| lucasagomes | ok the problem is because token cache keys are sha256 hashes | 10:33 |
| samueldmq | lucasagomes, hi morning | 10:34 |
| samueldmq | lucasagomes, I can find the change for you, just a cache | 10:34 |
| *** tobe has quit IRC | 10:34 | |
| samueldmq | just a second I meant* oO | 10:34 |
| lucasagomes | samueldmq, yeah fixing it now in Ironic | 10:35 |
| lucasagomes | we weren't using sha256 hashes for the token keys in Ironic | 10:35 |
| lucasagomes | (for our ACL tests) | 10:35 |
| lucasagomes | I'm updating the tests to check for hashs and non shash (to be compatible with ksmiddleware < 2.0.0 | 10:35 |
| lucasagomes | )* | 10:36 |
| samueldmq | lucasagomes, https://review.openstack.org/#/c/186971/ | 10:36 |
| samueldmq | lucasagomes, why do you handle token keys at service level (ironic) ? you caching there as well (besides middleware) ? | 10:37 |
| lucasagomes | samueldmq, https://review.openstack.org/193057 | 10:38 |
| lucasagomes | samueldmq, it's just ACL tests | 10:38 |
| lucasagomes | it was there before and the that change with the hash broke our gate. Maybe we shouldn't have those tests | 10:39 |
| lucasagomes | but I don't know much about that bit... I'm just trying to unbroken the gate | 10:39 |
| *** tobe has joined #openstack-keystone | 10:40 | |
| samueldmq | lucasagomes, ACL tests are like functional tests ? where you run against a running ironic, with a middleware on it, et c? | 10:41 |
| samueldmq | lucasagomes, I've never heard this terminology :) | 10:42 |
| samueldmq | lucasagomes, and yes, fixing that is fair enough for now | 10:42 |
| lucasagomes | samueldmq, yup | 10:42 |
| samueldmq | lucasagomes, nice | 10:42 |
| lucasagomes | yeah I will fix it and then bring it up to the community whether we should drop it or not | 10:42 |
| lucasagomes | I don't wanna fix the gate by deleting the tests, I think it's unfair | 10:42 |
| samueldmq | lucasagomes, yes it is, fix that to have the gate working asap, then revisit if they're really needed | 10:43 |
| lucasagomes | samueldmq, yes, I think it sounds like a good approach | 10:44 |
| lucasagomes | samueldmq, thanks much! | 10:44 |
| samueldmq | lucasagomes, you're welcome, feel free to come again and ask any questions you have :) | 10:44 |
| lucasagomes | samueldmq, will do :-) | 10:45 |
| samueldmq | dstanek, morning | 10:48 |
| samueldmq | dstanek, I saw your message from yesterday | 10:49 |
| samueldmq | dstanek, 'Listing policies filtered by service endpoint URL' (https://review.openstack.org/#/c/186765/) should be abandoned in favor of 'Policy by URL' (https://review.openstack.org/#/c/192422/) | 10:50 |
| *** e0ne is now known as e0ne_ | 10:50 | |
| samueldmq | dstanek, basically, an URL does not uniquely identify an endpoint, and then a policy | 10:50 |
| samueldmq | dstanek, we need a way to directly associate and retrieve policies on URLs, that's what that second spec proposes | 10:51 |
| dstanek | samueldmq: did you see why comment on url there? why use url? | 10:51 |
| samueldmq | dstanek, on the second patch ? | 10:52 |
| dstanek | yes | 10:52 |
| dstanek | url seems arbitrary | 10:53 |
| samueldmq | dstanek, looking .. | 10:54 |
| dstanek | i was jumping on the point made by Matthew Edmonds | 10:55 |
| samueldmq | dstanek, yes .. so, we need a way to, from the middleware placed on a service endpoint, fetch the policy for it | 10:56 |
| samueldmq | dstanek, so we're tied to service endpoints, right ? (at least this is the more granular we can go) | 10:57 |
| samueldmq | dstanek, yes can assign policies to endpoints, regions or services | 10:57 |
| dstanek | using url is arbitrary though right? it could easily just be policy_id in the middleware config | 10:57 |
| samueldmq | dstanek, yes it could, but the endpoint policy extension assign policies to endpoints/regions/services, so we will be using that extension | 10:58 |
| samueldmq | dstanek, so we should be asking for something that comes from the endpoint ... the first option is the endpoint_id | 10:59 |
| samueldmq | dstanek, so far so good ? | 10:59 |
| dstanek | looking at that extension now | 10:59 |
| dstanek | does that spec mention the extension or its relationship to the new functionality? | 11:00 |
| *** e0ne_ has quit IRC | 11:00 | |
| *** btully has quit IRC | 11:00 | |
| samueldmq | dstanek, I didn't fully read it .. will do today | 11:00 |
| samueldmq | dstanek, but that should mention ... show in what we are being based to implement that, so people can understand why we're going that way | 11:01 |
| dstanek | yes, that spec has no why | 11:02 |
| *** btully has joined #openstack-keystone | 11:02 | |
| samueldmq | dstanek, url is a property of endpoints, and morganfainberg argued that identifying by URL is better UX | 11:02 |
| dstanek | so why url and not endpoint id? | 11:02 |
| samueldmq | dstanek, yes that's where I am going now .. | 11:02 |
| dstanek | ah, i see | 11:03 |
| samueldmq | :) | 11:03 |
| samueldmq | dstanek, CMS have URL a priori | 11:03 |
| samueldmq | dstanek, see this for example https://wiki.openstack.org/wiki/DynamicPolicies#Overview_Solution_-_Liberty_Scope | 11:03 |
| samueldmq | dstanek, me and ayoung almost fully agreed on that scope diagram :) | 11:03 |
| *** lucasagomes has left #openstack-keystone | 11:04 | |
| dstanek | so which URL/endpoint do you use when the service is access from different ones? | 11:05 |
| samueldmq | sorry not sure I understood your question | 11:06 |
| dstanek | a service can theoretically be accessed from a number of endpoints all having different URLs - which one do you use in the config? | 11:07 |
| dstanek | think Keystone's public vs. internal | 11:08 |
| samueldmq | dstanek, in devstack, glance has 3 enpoints all pointing to localhost:9292 | 11:08 |
| dstanek | exactly. so which url should be put into the config? | 11:08 |
| samueldmq | dstanek, in devstack they're all the same ... the config goes into the middleware section | 11:09 |
| samueldmq | dstanek, which is defined per endpoint | 11:09 |
| *** tobe has quit IRC | 11:09 | |
| dstanek | the endpoint urls are all the same? | 11:09 |
| samueldmq | dstanek, in the case of devstack yes | 11:10 |
| dstanek | well, what if they were not? which one do you use? | 11:10 |
| samueldmq | dstanek, you should not be using a policy per URL/ednpoint, but per region/service instead | 11:10 |
| *** tobe has joined #openstack-keystone | 11:11 | |
| samueldmq | dstanek, when you look for a policy for an endpoint, if there is no policy associated directly, it tries to find in its region -> service | 11:11 |
| samueldmq | dstanek, kindof inherited .. | 11:11 |
| dstanek | the spec doesn't say anything about that | 11:12 |
| dstanek | so basically for services that have multiple endpoints like glance you should not be using this feature? | 11:12 |
| samueldmq | dstanek, that inherits from the endpoint policy extension as well, that should be mentioned | 11:12 |
| samueldmq | dstanek, should they be using different policies ? just because they have different interface types ? | 11:13 |
| samueldmq | dstanek, if this is a real-use case, we should still consider it | 11:13 |
| dstanek | it is if glance or any other service can have multiple URLs | 11:14 |
| dstanek | i think there needs to be guidance here | 11:14 |
| samueldmq | dstanek, if they have multiples URLs (1 for admin, 1 for public and 1 for internal), they can associate a policy per URL | 11:15 |
| samueldmq | dstanek, and set the right URL in each middleware | 11:15 |
| dstanek | and have multiple instances of that middleware in the same process? | 11:16 |
| samueldmq | dstanek, if you have the same process (different endpoint types) for all interfaces, shouldn't they be running in the same URL | 11:17 |
| samueldmq | dstanek, or should a process be expected to listen to different ports for those different interfaces ? | 11:18 |
| openstackgerrit | Cyril Roelandt proposed openstack/keystonemiddleware: Prevent a UnicodeDecodeError in the s3token middleware https://review.openstack.org/179777 | 11:18 |
| dstanek | i can easily run a service on 0.0.0.0:8080 and have a public name that points to haproxy (maybe that goes through a rate limiting service) and a private name that goes to a different haproxy. they both could point to that machine's IP:port | 11:20 |
| dstanek | i'm not saying the spec is wrong - i'm saying that it is incomplete if there are possible corner cases - it should talk about them | 11:22 |
| dstanek | i think the existing extension and using endpoint_id has the same issue | 11:22 |
| samueldmq | dstanek, got it | 11:23 |
| samueldmq | dstanek, so for your public URL you have a policy, and for your admin you have another | 11:23 |
| samueldmq | dstanek, which one should middleware fetch ? | 11:23 |
| dstanek | right, or if you only have one policy that both should use do you put it in there twice? | 11:24 |
| samueldmq | dstanek, we don't allow that today, if it is the same process, there is only one policy | 11:24 |
| dstanek | or it's possible that we say that we expect a deployer (and openstack services) to deploy a process per endpoint (except for Keystone?) | 11:25 |
| *** tobe has quit IRC | 11:25 | |
| dstanek | samueldmq: right, and i don't think there is advice on which one to use. or explicit guidance to say it's an arbitrary decidion | 11:26 |
| samueldmq | dstanek, basically we have a policy per middleware, which is uniquely identified per URL | 11:26 |
| samueldmq | by* | 11:26 |
| dstanek | i almost feels like we should just be specifying a policy id in the config | 11:26 |
| samueldmq | dstanek, and what if I want to completely change a policy for an endpoint ? | 11:27 |
| samueldmq | dstanek, I change the config and restart ? that's not dinamyc at all | 11:27 |
| samueldmq | dstanek, as we have today, you'd need to simply change the policy-endpoint association | 11:28 |
| dstanek | you could very easily use an intermediate id, but i'm assuming policy won't be changing that much | 11:29 |
| samueldmq | dstanek, yes but the solution is already in place for policy association | 11:30 |
| samueldmq | dstanek, you suggesting we should not use that extension at all ? | 11:30 |
| samueldmq | dstanek, anyway the extension add one level of indirection, you associate at the server and ask for the association with a key (endpoint id, url, whatever) | 11:30 |
| *** aix has joined #openstack-keystone | 11:32 | |
| dstanek | samueldmq: i'm just saying the spec is incomplete | 11:33 |
| samueldmq | dstanek, I completely agree there are corner cases that need to be clarified | 11:33 |
| samueldmq | dstanek, ++ | 11:33 |
| dstanek | so the middleware will be configured to know the region id, service id and endpoint url? | 11:33 |
| samueldmq | dstanek, just endpoint_url, if there is no policy to that url, it seeks on its corresponding service, then service | 11:34 |
| samueldmq | if that makes sense | 11:34 |
| dstanek | how does the middleware know what service to lookup? | 11:34 |
| samueldmq | dstanek, endpoints with same URL should be in the same region, from the same service | 11:35 |
| samueldmq | dstanek, if this is not true, we may have another issue ^ | 11:36 |
| *** e0ne has joined #openstack-keystone | 11:36 | |
| dstanek | we definitely don't enforce that anywhere | 11:36 |
| samueldmq | dstanek, k, need to bring that in the discussion as well | 11:37 |
| dstanek | i don't know that the spec talks about that either region based or service based lookups by the URL | 11:37 |
| samueldmq | dstanek, too much work :( | 11:37 |
| samueldmq | dstanek, always thinking I could do better/quicker | 11:38 |
| samueldmq | dstanek, it doesn't, but I agree that logic is expected, since that's what happens when we use endpoint_id | 11:39 |
| samueldmq | dstanek, need to confirm that with adam/morgan | 11:39 |
| dstanek | is that true? i don't see that logic in the extension | 11:40 |
| dstanek | if you check by endpoint_id it will explicitly look for that. no fallback to service or region from what i can tell | 11:41 |
| samueldmq | dstanek, that's what someone told me .. I think it was gyee_ , I didnt't test it myself | 11:41 |
| samueldmq | dstanek, so I am probably making bad assumptions | 11:41 |
| samueldmq | dstanek, did you see those messages in the ML, where sdague pointed out an issue with unified policy approach ? | 11:42 |
| dstanek | is that from a while ago where he said nova had some stuff in code? or something more recent? | 11:43 |
| dstanek | actually right now if looks like you need the policy id and endpoint id to check the policy - feels dumb :-( | 11:45 |
| *** jasondotstar has quit IRC | 11:46 | |
| samueldmq | dstanek, that's from a while | 11:47 |
| samueldmq | dstanek, you can have the policy, it is an entity, you can check it using policy_id | 11:48 |
| samueldmq | dstanek, however the association is policy/endpoint ids | 11:48 |
| samueldmq | dstanek, basically, the issue wiht unifying is: when any service change any API signature, that should be reflected in that separate repo/project (which owns the unified policy) | 11:50 |
| samueldmq | dstanek, that's just bad, and what about deployments running on master ? any commit changing api signature should have a depends-on commit on the unified poliyc ? | 11:50 |
| dstanek | yes, i did see that and he's got a great point | 11:53 |
| samueldmq | dstanek, yes .. what I want is to not do unified, at least for now | 11:53 |
| samueldmq | dstanek, that diagram I sent you earlier describes exactly how I see the workflow (https://wiki.openstack.org/wiki/DynamicPolicies#Overview_Solution_-_Liberty_Scope) | 11:54 |
| dstanek | on the other hand that is only about the included policy file right? | 11:54 |
| *** btully has quit IRC | 11:54 | |
| dstanek | so deployments running on master shouldn't be impacted | 11:55 |
| dstanek | it's really a developer thing - having to go to two different repos for a single API change | 11:55 |
| samueldmq | dstanek, yes, the unified should be always in sync with individual policies | 11:55 |
| *** btully has joined #openstack-keystone | 11:55 | |
| samueldmq | dstanek, if you're using dynamic policies, and the unified policy is not updated, the unified will replace your local updated policy (with let's say new api's) | 11:56 |
| samueldmq | dstanek, local policy files are replaced by what comes from the server (based on the unified policy) | 11:57 |
| samueldmq | dstanek, so the unified should necessarily be updated | 11:57 |
| *** rushiagr_away is now known as rushiagr | 11:58 | |
| dstanek | no, what i'm saying is that when a deployer follows master they likely have their own policy files and are not directly using the ones that come bundled anyway. so no matter what, when an API changes they have to change their version of a policy file. | 11:59 |
| samueldmq | dstanek, so they would be uploading their new policy to keystone, and just no using the unified | 11:59 |
| samueldmq | not* | 11:59 |
| samueldmq | dstanek, however I saw morganfainberg and someone else talking about default policies (I think it was on nova yesterday) that lots of people use default policies | 12:01 |
| dstanek | if they are using unified policy they would have to update their version - if they are not they would have to update their policy | 12:01 |
| dstanek | no depends-on needed for deployer purposes | 12:01 |
| dstanek | you're talking about defaults in code right? | 12:01 |
| samueldmq | dstanek, but unified policy is updated fro mthe repo | 12:02 |
| samueldmq | dstanek, and what if the policy coming from nova has 2 new api's , and the unified policy repo still doesn't reflect those api's | 12:02 |
| *** henrynash has joined #openstack-keystone | 12:03 | |
| *** ChanServ sets mode: +v henrynash | 12:03 | |
| samueldmq | dstanek, yes I am talking about the default policy.json shipped with the code | 12:03 |
| dstanek | will that matter to a deployer? i doubt they are running directly from master for the policy so they'd have to add it by hand manually anyway | 12:03 |
| samueldmq | dstanek, the unified policy is not a c&p from individual policies | 12:04 |
| samueldmq | dstanek, we'd be working on consistency between common rules, etc | 12:04 |
| dstanek | but it's a policy file and that means that a deployer can and probably should change it to make their environment | 12:04 |
| samueldmq | dstanek, or even rename 'default' rule from nova to 'compute:default', because each policy has its 'default' rule | 12:04 |
| samueldmq | dstanek, lots of people run on default policy | 12:05 |
| samueldmq | I don't think the unified effort is worth it, we can work on consistency between different polciies by educating people, and helping them to have a better policy | 12:06 |
| samueldmq | instead adding another level of policy, unified, that can simply be not used at aall | 12:06 |
| dstanek | what is the driven behind unified policy? it seems that nobody else is asking for it | 12:07 |
| samueldmq | dstanek, exactly, I asked ayoung yesterday about what he is trying to solve with that | 12:07 |
| samueldmq | dstanek, so I could see if there is another way to solve that problem | 12:08 |
| samueldmq | dstanek, one of the motivation is 'role hierarchies' | 12:08 |
| dstanek | how does it help with that? | 12:08 |
| samueldmq | dstanek, role:admin inherits from role:member | 12:08 |
| samueldmq | dstanek, you would be able to define the role hierarchy using the policy rules, and just once, since all policies are unified | 12:09 |
| samueldmq | dstanek, I have a different solution for that | 12:09 |
| samueldmq | dstanek, when asking for a policy for a given endpoint, you should be able to ask GET /policy/<endpoint_url> ? effective | 12:10 |
| samueldmq | using effective, role hierarchies would be expanded | 12:10 |
| samueldmq | 'compute:create_server':'role:member' would become 'compute:create_server':'role:member or role:admin' | 12:10 |
| *** jasondotstar has joined #openstack-keystone | 12:10 | |
| samueldmq | and you can use any role in the hierarchy directly in the assignments, without changing anything in the enforcement code | 12:11 |
| dstanek | sounds like you should write an alternative spec :-) | 12:11 |
| samueldmq | dstanek, oh looks like you liked that | 12:13 |
| samueldmq | dstanek, and then we don't touch inidividual policies for now, and can implement what is in that scope for L (in that wiki) | 12:13 |
| samueldmq | :-) | 12:13 |
| samueldmq | dstanek, I want to get dolphm's view on this, ayoung said me to talk to him, since he had the original idea about unified policy :) | 12:14 |
| *** ihrachyshka has joined #openstack-keystone | 12:15 | |
| dstanek | i like alternatives | 12:15 |
| ihrachyshka | anyone looking into fixing grenade job that fails due to keystone with "ArgsAlreadyParsedError: arguments already parsed: cannot register CLI option"? | 12:15 |
| dstanek | the thing i really dislike about specs is that we don't ever get a clear description of the problem | 12:16 |
| samueldmq | dstanek, nice, ideally we should have an agreement internally (keystone) this week | 12:16 |
| dstanek | we get lots of: 'problem description: we are missing my solution' | 12:16 |
| dstanek | ihrachyshka: link? | 12:16 |
| ihrachyshka | http://logs.openstack.org/66/185066/3/check/check-grenade-dsvm-neutron/45d8663/logs/apache/keystone.txt.gz#_2015-06-18_09_08_46_675874 | 12:16 |
| samueldmq | dstanek, next week I'd like to get this in a cross-project again, since we are solving what we want + implementing nova requirements | 12:16 |
| samueldmq | dstanek, so they should be happy | 12:16 |
| ihrachyshka | dstanek, as per sdague, it's because keystone script is not upgraded by grenade | 12:17 |
| samueldmq | dstanek, next week I'd like to start a meeting for policies .. so we could iterate faster .. I'm really worried about timing | 12:17 |
| ihrachyshka | dstanek, see related thread: http://lists.openstack.org/pipermail/openstack-dev/2015-June/067147.html | 12:17 |
| samueldmq | ++ <dstanek> we get lots of: 'problem description: we are missing my solution' | 12:17 |
| dstanek | ihrachyshka: is there anything we can do about it? | 12:17 |
| *** Nikkau has quit IRC | 12:18 | |
| ihrachyshka | dstanek, not sure. I guess fixing it? :) | 12:18 |
| ihrachyshka | dstanek, it breaks other projects, like neutron | 12:18 |
| dstanek | fix grenade? | 12:18 |
| dstanek | samueldmq: i should start being strict in the problem description section | 12:19 |
| *** bknudson has joined #openstack-keystone | 12:20 | |
| *** ChanServ sets mode: +v bknudson | 12:20 | |
| ihrachyshka | dstanek, hm, yes, fix grenade pieces relevant to keystone. I think it's expected from every project to take care of their pieces in devstack or grenade since project teams know better how their upgrade is expected to work. am I wrong on that? | 12:21 |
| dstanek | ihrachyshka: no idea. i know nothing about grenade :-) i can take a look and let others know later | 12:21 |
| samueldmq | dstanek, we definitively need to improve how we write specs , put comments on hte problem descriptions, we need to educate ppl on that :) | 12:21 |
| ihrachyshka | dstanek, ok, thanks, please do. | 12:22 |
| ihrachyshka | I'll report a bug too | 12:22 |
| *** btully has quit IRC | 12:22 | |
| dstanek | ihrachyshka: is there docs on running grenade anywhere? | 12:23 |
| *** btully has joined #openstack-keystone | 12:25 | |
| ihrachyshka | dstanek, not sure, I'm not a qa guy. you may check .rst files for the project. it may be the case that it's easier to just upload and see whether it works. | 12:25 |
| *** bknudson has quit IRC | 12:26 | |
| *** cdent has joined #openstack-keystone | 12:28 | |
| ihrachyshka | dstanek, I don't have permissions. can you raise priority for https://bugs.launchpad.net/keystone/+bug/1466485 to Critical in keystone? | 12:30 |
| openstack | Launchpad bug 1466485 in Keystone "keystone fails with: ArgsAlreadyParsedError: arguments already parsed: cannot register CLI option" [Undecided,New] | 12:30 |
| ihrachyshka | in case you ask, since it's a gate failure, it is critical | 12:30 |
| *** e0ne is now known as e0ne_ | 12:32 | |
| ihrachyshka | dstanek, I suspect that first, in devstack:lib/keystone, code that copies keystone.py should be moved into a separate function, and then reused from grenade. or better, the file should be just referenced from apache config without any copying involved | 12:36 |
| ihrachyshka | code that copies files in devstack: http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/keystone#n163 | 12:37 |
| ihrachyshka | hm, that said, the file was not changed in a while, so it may be something different... | 12:39 |
| *** e0ne_ is now known as e0ne | 12:39 | |
| *** dims has quit IRC | 12:40 | |
| *** dims has joined #openstack-keystone | 12:41 | |
| *** jasondotstar has quit IRC | 12:42 | |
| *** bknudson has joined #openstack-keystone | 12:43 | |
| *** ChanServ sets mode: +v bknudson | 12:43 | |
| *** rushiagr is now known as rushiagr_away | 12:44 | |
| *** woodster_ has joined #openstack-keystone | 12:45 | |
| *** henrynash has quit IRC | 12:50 | |
| samueldmq | ayoung, hi | 12:52 |
| dstanek | ihrachyshka: sure | 12:52 |
| samueldmq | ayoung, I will try to get an agreement in unified vs not unified in keystone first (you, dolphm, morganfainberg, dstanek, and others) | 12:54 |
| *** henrynash has joined #openstack-keystone | 12:54 | |
| *** ChanServ sets mode: +v henrynash | 12:54 | |
| samueldmq | ayoung, if we can't do that until next week, I will put both solutions in the roadmap as alternatives, and discuss in a cross-project view | 12:54 |
| samueldmq | ayoung, I'll start the missing specs according to that wiki | 12:55 |
| *** jasondotstar has joined #openstack-keystone | 12:55 | |
| samueldmq | ayoung, also, adding the spec for GET /policy/endpoint_url ? effective, as I described later (which solves role inheritance wihtout needing unified policy) | 12:55 |
| samueldmq | henrynash, hi ! good morning | 12:56 |
| samueldmq | henrynash, do you have a minute to about an idea on inherited roles (regarding where they are expanded, etc) | 12:57 |
| samueldmq | ? | 12:57 |
| *** henrynash has quit IRC | 13:00 | |
| samueldmq | * henrynash has quit (Quit: henrynash) :( | 13:02 |
| ayoung | samueldmq, tough start to the day, eh? | 13:03 |
| ayoung | samueldmq, so, no one responded about why to unify? | 13:03 |
| samueldmq | ayoung, I'd say challenging | 13:03 |
| samueldmq | ayoung, not yet, I am still not convinced that's worth it | 13:03 |
| samueldmq | ayoung, :) | 13:04 |
| ayoung | samueldmq, ok, let's (for arguments sake only) assume not...what does the process look like then? | 13:04 |
| *** henrynash has joined #openstack-keystone | 13:04 | |
| *** ChanServ sets mode: +v henrynash | 13:04 | |
| ayoung | samueldmq, and henrynash is back, too | 13:04 |
| samueldmq | ayoung, ok, without unified | 13:05 |
| samueldmq | ayoung, it should be something like this https://wiki.openstack.org/wiki/DynamicPolicies#Overview_Solution_-_Liberty_Scope | 13:05 |
| samueldmq | ayoung, (I still didn't update that diagram, sorry) | 13:05 |
| ayoung | No problem oin the diagram | 13:05 |
| samueldmq | ayoung, I am assuming step 3 is the default policy shipped with the nvoa code | 13:06 |
| ayoung | samueldmq, so lets take 2 use cases and map them out | 13:06 |
| samueldmq | ayoung, ask me questions for things you think we don't solve that way | 13:06 |
| ayoung | 1. Initial install | 13:06 |
| samueldmq | ayoung, sure | 13:06 |
| *** henrynash has quit IRC | 13:06 | |
| ayoung | 2. updating an existing install | 13:07 |
| ayoung | ok...lets make 1.5 customizing policy | 13:07 |
| samueldmq | ayoung, sure ... | 13:07 |
| samueldmq | ayoung, can I give you the solution ? | 13:07 |
| ayoung | heh, you never programmed in Basic, did you...time to renumber our lines | 13:07 |
| ayoung | 1. initial install | 13:07 |
| samueldmq | ayoung, I got what you said | 13:07 |
| ayoung | 2. Customize policy | 13:07 |
| ayoung | 3. Update remote service with new policy | 13:08 |
| *** henrynash has joined #openstack-keystone | 13:08 | |
| *** ChanServ sets mode: +v henrynash | 13:08 | |
| samueldmq | ayoung, sure, here I go | 13:08 |
| ayoung | samueldmq, can you seq diag those? | 13:08 |
| samueldmq | ayoung, sure | 13:08 |
| ayoung | ok, use the tool, and keep the diags themselves in git somewhere | 13:08 |
| samueldmq | ayoung, that is in that diagram | 13:08 |
| ayoung | the source for them | 13:08 |
| ayoung | actually, does not need to be git, but.... | 13:09 |
| ayoung | hmmm, just make the source handy | 13:09 |
| ayoung | samueldmq, but...that can wait....go on with what you were saying | 13:10 |
| samueldmq | ayoung, ok, sure | 13:10 |
| samueldmq | ayoung, can I say what I think now or you prefer to see the diagram directly? | 13:10 |
| ayoung | samueldmq, so...I wonder if we need to expand this to cover more work flow. | 13:11 |
| samueldmq | ayoung, to be more detailed , right ? | 13:11 |
| ayoung | I've been thinking in terms of step-by-step improvments to what we have in the repo, but that does not explain the benefit of the end product. | 13:11 |
| ayoung | REally need to explain both | 13:11 |
| *** richm has joined #openstack-keystone | 13:12 | |
| ayoung | OK so, in the overview I wrote last year, I tried to order things based on the dependencies. Lets rephrase what I said above to be: | 13:12 |
| ayoung | we want to push the unified policy file as late in the dependency list as possible | 13:12 |
| *** henrynash has quit IRC | 13:12 | |
| ayoung | so...short term, we can get: fetch policy from Keystone | 13:12 |
| samueldmq | ayoung, yes, so we can have a better agreement on that as we go | 13:12 |
| ayoung | lets assume we only get that far...what does that imply? | 13:13 |
| samueldmq | ayoung, yes, keeping the individual policies separete | 13:13 |
| *** edmondsw has joined #openstack-keystone | 13:13 | |
| ayoung | Someone neeeds to upload the policy...and if Nova updates its defaults, we need to, somehow, factro that in | 13:13 |
| samueldmq | ayoung, you may ask me: what did we do differently from what puppet could do, just distributing ? | 13:13 |
| ayoung | So, Lets assume that Nova has a default set of rules laid down before it fetches from Keystone...in Git terms, we would rebase on top of that | 13:14 |
| samueldmq | ayoung, ok | 13:14 |
| ayoung | Novas defaults are always root commit, and then we fetch the one from Keystone and lay it over the top. If Nova updates, we wipe the cache, lay down the one from nova, and update from keystone again | 13:14 |
| samueldmq | ayoung, let me explain you how 1. 2. and 3. above would work imo | 13:14 |
| ayoung | any definitions made by the base policy are overwritten by the ones centralized. This has high risk, as I see it | 13:15 |
| ayoung | because of the internal rules | 13:15 |
| ayoung | i.e. operator might redefine what is meant by "owner:" in keystone | 13:15 |
| samueldmq | ayoung, no, keystone stores 2 versions per endpoint, one is the default as it is i nthe service (uploaded by the cms) | 13:15 |
| ayoung | so..alternative | 13:15 |
| samueldmq | ayoung, and other which is the diff | 13:15 |
| samueldmq | ayoung, when you upgrade a service, CMS updates the default policy on keystone | 13:16 |
| samueldmq | ayoung, the diff (what you've customized) is kept | 13:16 |
| ayoung | if a new policy file is fetched from keystone, it completely replaces any rules that are on the installed system | 13:16 |
| samueldmq | ayoung, and new APIs jsut get the default | 13:16 |
| ayoung | the risk here, then, is that we have just removed any new rules added by the nova team | 13:16 |
| *** charlesw has joined #openstack-keystone | 13:16 | |
| cdent | anybody will to make an opinion on whether this https://bugs.launchpad.net/keystonemiddleware/+bug/1466499 is a keystonemiddleware or webob bug? | 13:16 |
| openstack | Launchpad bug 1466499 in keystonemiddleware "Use of webob.Reponse in AuthProtocol middleware break content-type handling" [Undecided,New] | 13:16 |
| samueldmq | ayoung, yes but when upgrade, CMS updates the default policy on keystone | 13:16 |
| ayoung | samueldmq, even an up[date can't be automated | 13:17 |
| ayoung | we need conflict resolution | 13:17 |
| samueldmq | ayoung, CMS is expected to keep inidivdual policies in sync on keystone | 13:17 |
| ayoung | and, so we need conflict detection | 13:17 |
| samueldmq | ayoung, upload and update when needed | 13:17 |
| ayoung | CMS is no magic bullet | 13:17 |
| samueldmq | ayoung, and it doesn't need to | 13:17 |
| samueldmq | ayoung, give me an example | 13:17 |
| dstanek | cdent: keystonemiddleware bug | 13:18 |
| *** jasondotstar has quit IRC | 13:18 | |
| dstanek | cdent: i'll comment on the bug | 13:18 |
| cdent | dstanek: so I shouldn't bother to report a bugon webob? | 13:18 |
| ayoung | samueldmq, nova has a rule in their default file admin_or_owner. They have a target compute:foo = admin_or_owner. admin_or_wonder depnds on a rule owner, which says that the user has the Member" role on the projec.t Operator has removed the Member role | 13:19 |
| ayoung | and update target compute:foo | 13:19 |
| ayoung | so that it is role:thingy | 13:19 |
| samueldmq | ayoung, when a new API comes, it's defined in terms of default policy | 13:20 |
| ayoung | no a new target i\s define compute:bar = admin_or_owner. | 13:20 |
| samueldmq | ayoung, the admin is supposed to customize it | 13:20 |
| ayoung | samueldmq, yes, that is what I mean by conflioct resoution. It can;'t be automated | 13:20 |
| samueldmq | ayoung, that fails, because that API is based on the defaults, and he customized that | 13:20 |
| samueldmq | ayoung, sure it can't | 13:20 |
| samueldmq | ayoung, we fill out with the defaults | 13:21 |
| ayoung | that is what the nova team does not want | 13:21 |
| dstanek | cdent: you probably can - they shouldn't add it if we don't need it, but i wouldn't be surprised if it were marked as won't fix because it would break backward compat | 13:21 |
| samueldmq | ayoung, this problem is not related to our current work | 13:21 |
| samueldmq | ayoung, it occrus today | 13:21 |
| cdent | roger dstanek, thanks | 13:21 |
| ayoung | samueldmq, true | 13:21 |
| samueldmq | ayoung, if an admin gets a new policy and he has customized his own | 13:21 |
| samueldmq | ayoung, he needs to see what new api's have been introduced | 13:21 |
| samueldmq | ayoung, and adapt their rules | 13:21 |
| *** Ctina_ has joined #openstack-keystone | 13:21 | |
| ayoung | samueldmq, but we are now working at odds with sean dague and the microversion approach | 13:21 |
| ayoung | and that will kill our ability to gain adoption | 13:22 |
| samueldmq | ayoung, yes sure, but I think unified is not the solution for that, it's just adding a dependency we don't need (at least for now) | 13:22 |
| ayoung | samueldmq, I need to work on something with a co-worker for a moment. | 13:22 |
| samueldmq | ayoung, let's keep the paradigm in individual policies, | 13:22 |
| samueldmq | ayoung, distribute them | 13:22 |
| samueldmq | ayoung, and make it possible to policies be customized through the API | 13:23 |
| ayoung | samueldmq, so...that is one reason I was thinking "split" | 13:23 |
| ayoung | we could split policy up into 3 files | 13:23 |
| ayoung | 1: common rules | 13:23 |
| ayoung | 2: roles foir targets | 13:23 |
| ayoung | 3: scope for targets | 13:23 |
| ayoung | only 2: is customizable by the projects | 13:24 |
| ayoung | correction | 13:24 |
| samueldmq | ayoung, yes but you agree that all can come later, after having the mechanism for policy distribution/API for CRUD in place? | 13:24 |
| ayoung | only 1 and 2: are customizable by the operators | 13:24 |
| ayoung | 3: is set by the services | 13:24 |
| ayoung | samueldmq, if we have a clear design in place, we can work on the ordering. I am not certain | 13:25 |
| ayoung | I thik we need to focus on the design first | 13:25 |
| *** ayoung is now known as ayoung-mtg | 13:25 | |
| samueldmq | ayoung-mtg, look at step 3 https://wiki.openstack.org/wiki/DynamicPolicies#Overview_Solution_-_Liberty_Scope | 13:25 |
| samueldmq | ayoung-mtg, if we go unified, instead of uploading/updating a Default policy per endpoint | 13:25 |
| samueldmq | ayoung-mtg, we'll be doing that once for everyone | 13:26 |
| dstanek | cdent: commented | 13:26 |
| samueldmq | ayoung-mtg, that's all to go from separate to unified | 13:26 |
| samueldmq | ayoung-mtg, that's where my diagram and yours differ | 13:26 |
| *** edmondsw has quit IRC | 13:27 | |
| cdent | dstanek: awesome, thanks | 13:27 |
| dstanek | cdent: once you create the webob issue you should add a comment with a link | 13:27 |
| cdent | dstanek: already done, in both directions | 13:27 |
| *** csoukup has joined #openstack-keystone | 13:29 | |
| *** belmoreira has quit IRC | 13:30 | |
| *** richm has quit IRC | 13:30 | |
| *** dsirrine has joined #openstack-keystone | 13:32 | |
| *** fifieldt_ is now known as fifieldt | 13:36 | |
| openstackgerrit | Diane Fleming proposed openstack/keystone-specs: Add side-by-side comparison table of v2 and v3 APIs https://review.openstack.org/187027 | 13:41 |
| *** ayoung-mtg is now known as ayoung | 13:42 | |
| *** HT_sergio has joined #openstack-keystone | 13:42 | |
| *** charlesw has quit IRC | 13:43 | |
| *** richm has joined #openstack-keystone | 13:44 | |
| *** zzzeek has joined #openstack-keystone | 13:46 | |
| *** csoukup has quit IRC | 13:56 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 13:57 | |
| *** jasondotstar has joined #openstack-keystone | 13:58 | |
| *** jasondotstar has quit IRC | 13:58 | |
| *** dsirrine has quit IRC | 14:00 | |
| *** charlesw has joined #openstack-keystone | 14:04 | |
| *** btully has quit IRC | 14:09 | |
| *** afazekas has quit IRC | 14:09 | |
| *** edmondsw has joined #openstack-keystone | 14:10 | |
| mfisch | dolphm: lbragstad: I'm using your benchmarks this morning against my staging environment, comparing to prod and while token creation with fernet is faster token validation is significantly slower | 14:10 |
| mfisch | I didnt manage to get a before and after benchmark but I will have one when we do prod next week | 14:10 |
| mfisch | Wondering why I'm seeing such a bad result | 14:10 |
| *** btully has joined #openstack-keystone | 14:10 | |
| lbragstad | mfisch: what's your testing criteria look like? | 14:11 |
| mfisch | I basically took dolph's benchmarks | 14:11 |
| *** kr4zy has joined #openstack-keystone | 14:11 | |
| mfisch | I dont have a great apples to apples yet since these are different environments | 14:11 |
| *** dsirrine has joined #openstack-keystone | 14:13 | |
| mfisch | lbragstad: once I upgrade production I'll have apples to apples to share | 14:13 |
| *** stevemar has joined #openstack-keystone | 14:13 | |
| *** ChanServ sets mode: +v stevemar | 14:13 | |
| dstanek | mfisch: have you tuned the number of rounds? | 14:13 |
| mfisch | dstanek: no, I have not, how would one do that? | 14:15 |
| *** btully has quit IRC | 14:15 | |
| lbragstad | mfisch: that would be the crypt_strength in your configs | 14:16 |
| lbragstad | mfisch: it defaults to 40,000 rounds | 14:16 |
| mfisch | there it is | 14:17 |
| mfisch | I was looking in the fernet section | 14:17 |
| *** btully has joined #openstack-keystone | 14:17 | |
| dstanek | sorry walked away... | 14:19 |
| dstanek | that will significantly change the time it takes to run each key through the crypto | 14:20 |
| dolphm | mfisch: that's weird... | 14:20 |
| mfisch | for validation or for token creation? | 14:20 |
| lbragstad | I find the validation part weird | 14:21 |
| dolphm | mfisch: token and user creation | 14:21 |
| mfisch | I will do a few more runs today | 14:21 |
| mfisch | token creation is quicker | 14:21 |
| dolphm | mfisch: by how much? | 14:21 |
| mfisch | but this is a real cloud and so there is other stuff going on in it | 14:21 |
| dolphm | mfisch: and how much slower is token validation? | 14:21 |
| mfisch | lemme post | 14:21 |
| dolphm | mfisch: what version of pypi/cryptography and python? | 14:22 |
| mfisch | this is token validation with UUID: Requests per second: 26.28 [#/sec] (mean), concurrent: 401.32 [#/sec] (mean) | 14:22 |
| mfisch | with fernet I get 6.x and 83 concurrent | 14:22 |
| dolphm | mfisch: also, what does your token backend look like for UUID? maybe it's just insanely fast already? | 14:22 |
| dolphm | whoa | 14:22 |
| *** thedodd has joined #openstack-keystone | 14:23 | |
| mfisch | this is not the same cloud again but that staging cloud should have basically no load, it should be quicker | 14:23 |
| dolphm | 6 / sec vs 26 / sec? | 14:23 |
| mfisch | UUID backend is a inter-DC galera with an arbitrator | 14:23 |
| mfisch | but I'm not hitting the GSLB, I'm hitting a per DC LB so only local replication matters | 14:23 |
| mfisch | we have a master node that keystone prefers to read/write into | 14:24 |
| *** btully has quit IRC | 14:24 | |
| *** btully has joined #openstack-keystone | 14:25 | |
| kr4zy | Here is my detail Openstack Keystone Juno setup: https://gist.github.com/anonymous/e9881eda4dea4325a7fa. Line 33, is it possible to use a different value instead of CN for "who=CN=Unknown Name"? | 14:26 |
| mfisch | dolphm: I'll do few more runs today and tomorrow and maybe email you some results | 14:27 |
| dolphm | mfisch: what about pypi/cryptography & python version? | 14:27 |
| dstanek | mfisch: have you tried to adjust the crypt_strength? i curious to know if that helps | 14:28 |
| dolphm | dstanek: that'll help token creation, but not validation | 14:28 |
| mfisch | fernet creation is quicker as expected | 14:28 |
| dstanek | dolphm: crypto is not used for validation? | 14:28 |
| dolphm | dstanek: crypt strength is only used for creating & comparing password hashes | 14:29 |
| dolphm | dstanek: wiiiith... passlib? pypi/cryptography doesn't do rounds like that anywhere in fernet | 14:29 |
| mfisch | python 2.7.6-8 and I cannot find the cryptography library on here which is strange | 14:31 |
| dstanek | dolphm: i'll have to take a look at the code. if we encrypt/sign the token with a number of rounds then the decrypt/verify would also take that number of rounds right? unless we are not checking on validate | 14:31 |
| *** jasondotstar has joined #openstack-keystone | 14:31 | |
| *** btully has quit IRC | 14:32 | |
| *** jasondot_ has joined #openstack-keystone | 14:32 | |
| *** henrynash has joined #openstack-keystone | 14:32 | |
| *** ChanServ sets mode: +v henrynash | 14:32 | |
| *** ninag has joined #openstack-keystone | 14:32 | |
| mfisch | dstanek: let me know what you find | 14:34 |
| *** btully has joined #openstack-keystone | 14:34 | |
| *** kiran-r has quit IRC | 14:34 | |
| *** HT_sergio has quit IRC | 14:36 | |
| mfisch | dolphm: cryptography (0.8) | 14:37 |
| *** e0ne is now known as e0ne_ | 14:37 | |
| lbragstad | mfisch: that looks right | 14:37 |
| *** e0ne_ is now known as e0ne | 14:37 | |
| mfisch | let me gather more data with a few more longer runs and get back to you guys | 14:37 |
| mfisch | we've already notified customers so this is happening regardless ;) | 14:38 |
| mfisch | I need to step away am at a conference supposed to be paying attention | 14:38 |
| dstanek | dolphm: it looks like fernet token_formater uses self.unpack and that uses the crypto lib | 14:38 |
| lbragstad | dstanek: yeah, that's right | 14:41 |
| dstanek | lbragstad: that's why i would expect lowering the rounds to speed up the verification | 14:42 |
| *** jasondotstar has quit IRC | 14:42 | |
| lbragstad | dstanek: ++ that's were I noticed a speed up in our environment | 14:43 |
| *** ihrachyshka has quit IRC | 14:43 | |
| morganfainberg | mfisch: are you also caching anything? | 14:43 |
| kr4zy | Here is my detail Openstack Keystone Juno setup: https://gist.github.com/anonymous/e9881eda4dea4325a7fa. Line 33, is it possible to use a different value instead of CN for "who=CN=Unknown Name"? | 14:43 |
| *** browne has joined #openstack-keystone | 14:46 | |
| *** diazjf has joined #openstack-keystone | 14:48 | |
| dstanek | kr4zy: i don't know much about our LDAP driver, but i'm guessing that's a configurable value | 14:49 |
| *** jasondotstar has joined #openstack-keystone | 14:49 | |
| dstanek | kr4zy: you have two different examples one for LDAP and one for AD. are those from two different Keystone instances? | 14:50 |
| kr4zy | dstanek: from one keystone instance. | 14:50 |
| *** jasondotstar has quit IRC | 14:50 | |
| *** henrynash has quit IRC | 14:50 | |
| *** jasondot_ has quit IRC | 14:51 | |
| kr4zy | dstanek: I don't see an option in keystone.conf to configure he ldap driver | 14:51 |
| dstanek | kr4zy: two different drivers? | 14:51 |
| *** jasondotstar has joined #openstack-keystone | 14:51 | |
| dstanek | as-in domain config | 14:51 |
| *** rdo has quit IRC | 14:52 | |
| *** rdo has joined #openstack-keystone | 14:54 | |
| dolphm | morganfainberg: mfisch: we didn't test without caching, but fernet needs to read a bunch from the db on validate, so caching will be important | 14:54 |
| dolphm | kr4zy: https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L872-L1187 | 14:56 |
| *** charlesw_ has joined #openstack-keystone | 14:58 | |
| *** charlesw has quit IRC | 14:59 | |
| *** charlesw_ is now known as charlesw | 14:59 | |
| *** e0ne has quit IRC | 15:04 | |
| *** HT_sergio has joined #openstack-keystone | 15:05 | |
| kr4zy | dstanek: keystone uses the ldap driver for both ldap and ad right? | 15:06 |
| dstanek | yep, you specify the user in your config. i'm assuming if you have 2 different users that you are using a domain config for something | 15:07 |
| stevemar | kr4zy, i believe so | 15:07 |
| *** boris-42 has joined #openstack-keystone | 15:10 | |
| ayoung | kr4zy, are you trying to do AD alongside straight LDAP in two different machines? | 15:11 |
| kr4zy | I am using AD only | 15:12 |
| ayoung | dolphm, I would set the expectations for Fernet to be: handle distributed much more easily than uuid (no sync) but slightly slower on each validate | 15:12 |
| ayoung | dolphm, the slightly slower due to the number of DB reads | 15:12 |
| kr4zy | on one machine | 15:12 |
| ayoung | dolphm, and I don't think caching will buy you all that much there....but really, who cares? | 15:12 |
| kr4zy | I have two keystone config. One with ldap and one with ad that I switch around to compare | 15:12 |
| ayoung | THe perf difference should be miniscule | 15:12 |
| ayoung | kr4zy, Ah, ok...so, are you using the SQL driver with a domain specific backend for LDAP, or are you using the LDAP driver directly for identity? | 15:13 |
| kr4zy | I am using sql for the assignment and ldap for the identity driver | 15:14 |
| dstanek | kr4zy: what LDAP user do you have in your config? | 15:15 |
| dolphm | mfisch: we also benchmarked an earlier implementation of fernet -- maybe it's worth re-running benchmarks with stable/kilo | 15:16 |
| dolphm | mfisch: but i still can't explain the magnitude of the performance decrease you're seeing | 15:16 |
| kr4zy | user = CN=OpenstackKeystone,OU=Service Accounts,OU=Swift,OU=Applications,DC=adstg,DC=xxx,DC=com | 15:16 |
| dolphm | mfisch: nothing i'm aware of changed *that* much between what we benchmarked and stable/kilo | 15:17 |
| *** rwsu has joined #openstack-keystone | 15:18 | |
| kr4zy | I see in the logs that keystone makes two calls to ad to retrieve the users then it attempt to use the user's CN, specify in the env, to query ad. That's where it didn't work out | 15:19 |
| kr4zy | because of the extra space in the CN | 15:20 |
| kr4zy | I think | 15:20 |
| ayoung | kr4zy, if ldapsearch allows it, I think the Python wrappers allow it | 15:21 |
| kr4zy | I want to understand if there's any option in the keystone.conf that would allow me to specify a specific value for keystone to use instead of the cn | 15:21 |
| *** arunkant_ has quit IRC | 15:21 | |
| ayoung | kr4zy, you want this for groups or for users? | 15:22 |
| ayoung | in either case, I think you can provide a query | 15:22 |
| ayoung | I know you can fro groups | 15:22 |
| ayoung | kr4zy, one thing about LDAP...it has lots of knobs and buttons | 15:23 |
| ayoung | kr4zy, did you specify user_filter in the ldap section? | 15:24 |
| ayoung | kr4zy, or group_filter? | 15:24 |
| *** browne has quit IRC | 15:27 | |
| *** kfox1111 has joined #openstack-keystone | 15:30 | |
| *** spandhe has joined #openstack-keystone | 15:30 | |
| *** gyee has joined #openstack-keystone | 15:32 | |
| *** ChanServ sets mode: +v gyee | 15:32 | |
| kr4zy | ayoung: but are all the settings for ldap is handle in keystone.conf? | 15:34 |
| ayoung | kr4zy, yes, unless you do a domain specific backend. | 15:34 |
| kfox1111 | ayoung: Is a project scoped token allowed to get a new token associated with a trust on the account, or must that use an unscoped token? | 15:35 |
| ayoung | kfox1111, it is today, yes | 15:35 |
| kfox1111 | and forever? | 15:35 |
| ayoung | kfox1111, so, put ojn your security hat...the geernal rule is that you should beable to go from more general to more specific, but not the other way | 15:36 |
| ayoung | I'm not certain it would make sense to go from a scoped token to a trust scoped token...why would you want to? | 15:36 |
| lbragstad | just out of curiosity, is anyone aware of any places that still have some availability in Boston for the meetup? | 15:38 |
| kfox1111 | to save some steps. If I provided a scoped token from the nova metadata server to the vm, then the vm could use the service catalog as is, and acl's would work without an extra call to keystone. | 15:38 |
| kfox1111 | with requiring unscoped tokens to go to trusts, I have to return unscoped tokens to the vm, so to talk to barbican, the vm get token workflow ends up authenticating with keystone twice. once from the metadata server to get the unscoped token, and once from the vm, unscoped to scoped. | 15:39 |
| kr4zy | what does this message mean "REFERRAL: {'info': 'Referral:\nldap://xxxxx.com/ou=UserGroups,DC=xxxxx,DC=com', 'desc': 'Referral'}" | 15:40 |
| kfox1111 | so I'm going to have to make a nova dummy project, return the unscoped token and dummy project name, then the vm's got to go and contact keystone using the token and the dummy project name and get a scoped one, get a new token and service catalog, and then it can talk to barbican. | 15:40 |
| *** charlesw has quit IRC | 15:41 | |
| *** charlesw_ has joined #openstack-keystone | 15:41 | |
| *** charlesw_ is now known as charlesw | 15:41 | |
| kfox1111 | maybe that's just the best we can do. | 15:41 |
| *** afazekas has joined #openstack-keystone | 15:42 | |
| *** arunkant_ has joined #openstack-keystone | 15:45 | |
| ayoung | kfox1111, I'm still processing | 15:47 |
| ayoung | lbragstad, besides the Dorm? | 15:47 |
| *** ErickCharles has joined #openstack-keystone | 15:48 | |
| dstanek | lbragstad: last i looked our travel tool showed a few | 15:48 |
| *** belmoreira has joined #openstack-keystone | 15:49 | |
| *** afazekas has quit IRC | 15:50 | |
| *** pnavarro has quit IRC | 15:52 | |
| *** ducttape_ has joined #openstack-keystone | 15:53 | |
| ducttape_ | I have a question, related to fernet tokens: In horizon (with the mysql UUID tokens), you might change your own permissions for a project - and it could invalidate your token. It seems like fernet works a bit differently ? | 15:56 |
| ayoung | kr4zy, I have no idea | 15:56 |
| ayoung | ducttape_, not exactly...but we got a little better in handling those things with revocation events | 15:57 |
| ayoung | with uuid, you could actually enable revocation events as well, and then they would behave the same, but the default for UUID tokens is to revoke-by-id | 15:58 |
| ayoung | kfox1111, I'm still thinking it through. I know I come across as trying to make your life difficult, but I assure, that is not my intention...just a side effect | 15:58 |
| ayoung | richm, can you answer kr4zy 's question there? I know too little LDAP to be useful here | 15:59 |
| kfox1111 | ayoung: I understand. I want to ensure this thing's secure and future proof. | 16:00 |
| kfox1111 | I also really need it in liberty. :/ | 16:00 |
| *** jasondotstar is now known as jasondotstar|afk | 16:01 | |
| kfox1111 | so if its not perfect, but can be perfected in m+ without breaking things, I'm all for that. | 16:01 |
| ayoung | kfox1111, yeah... | 16:01 |
| ayoung | kfox1111, so Nova is going to be a proxy for tokens from the VM? | 16:01 |
| *** afazekas has joined #openstack-keystone | 16:01 | |
| *** ninag has quit IRC | 16:01 | |
| ayoung | kfox1111, a VM will ask the metadata server for a token, and that will trigger a call to keystone to get it? | 16:02 |
| kfox1111 | I was thinking nova would only proxy the inital requiest to keystone to get the unscoped token. | 16:02 |
| kfox1111 | but if a project scoped token is required to talk to barbican to use acl's, then the vm's got to talk to keystone and get a scoped one first. | 16:02 |
| kfox1111 | correct. | 16:02 |
| ayoung | kfox1111, hmmm. Maybe that is not the right idea. Maybe Nova should only hand over scoped tokens, scoped down to what they are targetted to do. | 16:02 |
| kfox1111 | that could work, but I'm a bit worried then the nova api will have to chaise the keystone one. | 16:03 |
| ayoung | limits the damage that can be done. | 16:03 |
| *** jasondotstar has joined #openstack-keystone | 16:03 | |
| *** HT_sergio has quit IRC | 16:03 | |
| kfox1111 | you add service scoped or different trust flags, nova's gota change too. | 16:03 |
| ayoung | kfox1111, so what if it does...Keystone tokens are already chatty...I was trying to fix that in the past, but have given up on it | 16:03 |
| ayoung | don't prematurely optimize | 16:03 |
| kfox1111 | fair enough. | 16:04 |
| ayoung | kfox1111, is it easy to write metadata plugins? | 16:04 |
| kfox1111 | yup. got a prototype of the metadata server handing back keystone tokens to the vm already. :) | 16:04 |
| kfox1111 | took less then 4 hours to get working. | 16:04 |
| ayoung | kfox1111, so you can always send the project ID in a token request. No need to get a scoped token first. So lets set the project ID as a parameter to the plugin | 16:05 |
| kfox1111 | will take more work since we're switching things to the barbican ca workflow. | 16:05 |
| *** _cjones_ has joined #openstack-keystone | 16:05 | |
| ayoung | kfox1111, I like this....I need to think it through, but there is something very powerful you are starting here | 16:05 |
| *** jamie_h has joined #openstack-keystone | 16:05 | |
| ayoung | we havea chain of trust, we want to make sure we can follow it | 16:06 |
| kfox1111 | yeah. | 16:06 |
| kfox1111 | so, here's one detail still to resolve.... | 16:06 |
| ayoung | user kicks off vm...nova now has the knowledge of the vm...if the vm needs to do something, nova provides access to that... | 16:06 |
| *** _cjones_ has quit IRC | 16:06 | |
| *** _cjones_ has joined #openstack-keystone | 16:06 | |
| jamie_h | how do you change the token expiration in v3? I edited the expiration key in [token] section of keystone.conf, and restarted the "key" and "key-access" screens. nothing happened | 16:06 |
| ayoung | the question is how to configure things between nova and keystone...its kindof like an implicit trust | 16:06 |
| ayoung | jamie_h, wrong value | 16:06 |
| ayoung | key and key-access? | 16:07 |
| kfox1111 | ayoung: exactly. thats what the spec was changed to say recently. | 16:07 |
| *** afazekas has quit IRC | 16:07 | |
| kfox1111 | using a new liberty feature to allow nova+barbican to act as an identity provider | 16:07 |
| jamie_h | ayoung the "expiration" value has this comment "# Amount of time a token should remain valid (in seconds). (integer value)". does this not control expiration time? | 16:08 |
| ayoung | 'expiration' | 16:08 |
| ayoung | ah..ok, not the key stuff | 16:08 |
| ayoung | jamie_h, yes, that is the right value | 16:08 |
| *** HT_sergio has joined #openstack-keystone | 16:08 | |
| jamie_h | "key" and "key-access" are the screens in devstack running keystone services | 16:08 |
| ayoung | jamie_h, if you hit keystone with curl, you can see all the values in the token body, including expiration | 16:08 |
| ayoung | ah..I see | 16:08 |
| ayoung | jamie_h, so keystone runs in httpd | 16:09 |
| jamie_h | ayoung yes, but it's giving me tokens that have a millisecond expiry time | 16:09 |
| ayoung | to restart httpd, run the equivalent ofo sudo service httpd restart | 16:09 |
| jamie_h | I basically uncommented the keystone.conf line so it's 3600 - but restarting services isn't picking it up in devstack | 16:09 |
| ayoung | jamie_h, devstack is running with Keystone in httpd, right? | 16:09 |
| kfox1111 | so... barbican needs a scoped token to allow acl's to work. its not going to actually ever use the project info though. | 16:10 |
| kfox1111 | keystone needs a user to be a member of a project in order to get a scoped token. | 16:11 |
| jamie_h | ayoung I don't know. I tried `sudo service apache2 restart`, revoked the token and generated it again - still the same expiry | 16:11 |
| kfox1111 | so should the users nova hands out have a dummy "nova-user" project or something that they always get added to, | 16:11 |
| ayoung | jamie_h, maybe you changed th wrong config file? | 16:11 |
| ayoung | gah...too many directions at once! | 16:11 |
| kfox1111 | and the vm can rely on getting the unscoped token and ask it to be scoped to that dummy project so it can get a service catalog and talk to services that support acl's? | 16:12 |
| *** kr4zy_ has joined #openstack-keystone | 16:12 | |
| dstanek | jamie_h: 'ps -ef | grep keystone' to see if it is running as keystone-all | 16:12 |
| ayoung | kfox1111, why not a barbican project? | 16:12 |
| kfox1111 | why create a project for nova instance users for barbican and zaqar for example? | 16:12 |
| kfox1111 | when it relay's no real permissions? | 16:12 |
| ayoung | kfox1111, ... but you are on the right. Let's not create an explicit project | 16:13 |
| kfox1111 | its there simply because you don't want to allow an unscoped token to pass to that service. | 16:13 |
| kfox1111 | yeah. | 16:13 |
| kfox1111 | I think the identity provider thing of nova+barbican thingy could do that part. | 16:13 |
| ayoung | just that the nova user needs to be able to authenticate to keystone to get a token on behalf of a user...and that should be some sort of federation setup...we could use X509 for that | 16:13 |
| kfox1111 | maybe... | 16:13 |
| jamie_h | dstanek I don't see `keystone-all`. I see a few processes tailing the logs for /var/log/apache2/keystone.log and /var/log/apache2/keystone_access.log | 16:13 |
| ayoung | or even something else... | 16:13 |
| kfox1111 | ayoung: thats the plan. see the spec. | 16:14 |
| kfox1111 | specifically: http://specs.openstack.org/openstack/keystone-specs/specs/liberty/keystone-tokenless-authz-with-x509-ssl-client-cert.html | 16:14 |
| ayoung | kfox1111, ok...need to get lucnh and run an errand...I think I like where this is headed | 16:14 |
| dstanek | jamie_h: yep, then you are running under apache. so you are getting new tokens generated with the wrong timeout? | 16:14 |
| ayoung | we could possibly treat token for token exahcnes as another form of federation. | 16:14 |
| kfox1111 | ayoung: Cool. thanks for helping flesh this out. :) | 16:14 |
| jamie_h | dstanek the expiries are ridiculously short, like 1 millisecond | 16:14 |
| ayoung | actually...it could be like K2K | 16:14 |
| jamie_h | and it seems to be ignoring the keystone.conf `expiration` value | 16:14 |
| ayoung | jamie_h, when you start, it should dump the config into the log file | 16:15 |
| ayoung | I think it ieven shows where it is reading the config from | 16:15 |
| dstanek | jamie_h: what config are you editing? the one is /etc? | 16:15 |
| ayoung | and see what values are set there..you might need to turn on debugging | 16:15 |
| kfox1111 | ayoung: I thought I saw somehwere that sayd nova specs had to be in by the 21st. | 16:15 |
| kfox1111 | so we're quickly running out of time on approving the spec though. | 16:15 |
| ayoung | kfox1111, maybe we can do this out of the scope of Nova proper. | 16:16 |
| kfox1111 | I'm not tied really heavly to the details, more the concept at this point. | 16:16 |
| *** ihrachyshka has joined #openstack-keystone | 16:16 | |
| ayoung | 3rd party metadata plugin? | 16:16 |
| richm | kr4zy: A referral is like a redirect | 16:16 |
| kfox1111 | well, I'm afraid it requires direct modification to the metadata server. | 16:16 |
| ayoung | meh | 16:16 |
| jamie_h | ah, I think it's working now. thanks all! :) | 16:16 |
| kfox1111 | the plugin mechanism caches things, so wouldn't work. :/ | 16:16 |
| ayoung | I need to head out. | 16:16 |
| *** ayoung is now known as ayoung-afk | 16:16 | |
| kfox1111 | ok. | 16:16 |
| *** rushiagr_away is now known as rushiagr | 16:16 | |
| *** kr4zy_ has quit IRC | 16:16 | |
| dstanek | jamie_h: what was the problem? | 16:16 |
| *** kr4zy_ has joined #openstack-keystone | 16:17 | |
| *** kr4zy has quit IRC | 16:17 | |
| richm | kr4zy: Can you paste your keystone ldap config to http://paste.openstack.org/, with your sensitive information obscured? | 16:17 |
| jamie_h | no problem - I wasn't reading the hour value properly. restarting value picked up the right expiration | 16:18 |
| dstanek | jamie_h: ah, ok. cool | 16:19 |
| *** afazekas has joined #openstack-keystone | 16:20 | |
| *** aix has quit IRC | 16:20 | |
| *** vilobhmm has joined #openstack-keystone | 16:20 | |
| *** vilobhmm1 has joined #openstack-keystone | 16:22 | |
| *** openstackgerrit has quit IRC | 16:22 | |
| *** openstackgerrit has joined #openstack-keystone | 16:23 | |
| *** vilobhmm has quit IRC | 16:25 | |
| *** jasondotstar has quit IRC | 16:25 | |
| *** browne has joined #openstack-keystone | 16:26 | |
| sigmavirus24 | dolphm: ping | 16:30 |
| *** gsilvis has quit IRC | 16:30 | |
| *** charlesw_ has joined #openstack-keystone | 16:30 | |
| *** afazekas has quit IRC | 16:30 | |
| *** ninag has joined #openstack-keystone | 16:31 | |
| sigmavirus24 | alternatively if you're around lbragstad, ping | 16:31 |
| *** charlesw has quit IRC | 16:31 | |
| lbragstad | sigmavirus24: o/ | 16:31 |
| *** charlesw_ is now known as charlesw | 16:31 | |
| lbragstad | sigmavirus24: what can I help with? | 16:31 |
| *** jasondotstar|afk is now known as jasondotstar | 16:33 | |
| sigmavirus24 | so dolphm mentioned that if I re-run keystone-manage fernet_setup --keystone-user... --keystone-group... that it should rotate the keys in the configured key repository but I'm not seeing that behaviour | 16:33 |
| sigmavirus24 | Am I missing something? | 16:34 |
| dolphm | sigmavirus24: o/ | 16:34 |
| sigmavirus24 | \o | 16:34 |
| lbragstad | sigmavirus24: s/fernet_setup/fernet_rotate/ | 16:34 |
| sigmavirus24 | Ahh | 16:34 |
| dolphm | sigmavirus24: no, the behavior i was describing was something that cloudnull described ansible implementing | 16:34 |
| dstanek | shouldn't it be fernet_rotate? | 16:34 |
| lbragstad | sigmavirus24: fernet_setup will init a repo for you and rotate *once* | 16:35 |
| sigmavirus24 | Yeah that makes more sense | 16:35 |
| sigmavirus24 | Those are the bits I was missing | 16:35 |
| dolphm | fernet_setup -> fernet_rotate -> fernet_rotate -> fernet_rotate -> fernet_rotate | 16:35 |
| * sigmavirus24 was also missing it in keystone-manage's -h | 16:35 | |
| sigmavirus24 | thanks all | 16:35 |
| sigmavirus24 | sorry for the noise | 16:35 |
| *** ninag has quit IRC | 16:35 | |
| dolphm | sigmavirus24: is it not in --help? | 16:35 |
| sigmavirus24 | it is but my eyes were missing it for some reason | 16:36 |
| lbragstad | dolphm: sigmavirus24 it was when keystone/bin/keystone-manage was still around | 16:36 |
| *** ninag has joined #openstack-keystone | 16:36 | |
| sigmavirus24 | it is | 16:36 |
| * sigmavirus24 just needs better eyes | 16:36 | |
| sigmavirus24 | or more coffe | 16:36 |
| sigmavirus24 | *coffee | 16:36 |
| dolphm | always coffee | 16:36 |
| lbragstad | sigmavirus24: ++ more coffee | 16:36 |
| sigmavirus24 | coffee is bae | 16:36 |
| *** gsilvis has joined #openstack-keystone | 16:37 | |
| *** Ctina__ has joined #openstack-keystone | 16:37 | |
| *** samueldmq has quit IRC | 16:37 | |
| *** samueldmq has joined #openstack-keystone | 16:38 | |
| *** afazekas has joined #openstack-keystone | 16:39 | |
| dolphm | --sigmavirus24 | 16:40 |
| *** vilobhmm1 has quit IRC | 16:40 | |
| * sigmavirus24 is good at killing conversations | 16:40 | |
| sigmavirus24 | c-c-c-c-c-convo killer | 16:40 |
| *** Ctina_ has quit IRC | 16:40 | |
| dolphm | sigmavirus24++ | 16:42 |
| sigmavirus24 | really? I was expecting another -- | 16:43 |
| *** HT_sergio has quit IRC | 16:44 | |
| *** jasondotstar is now known as jasondotstar|afk | 16:44 | |
| *** ErickCharles has quit IRC | 16:45 | |
| *** jasondotstar|afk is now known as jasondotstar | 16:46 | |
| *** afazekas has quit IRC | 16:46 | |
| openstackgerrit | Fernando Diaz proposed openstack/keystone: Adding Documentation for Mapping Combinations https://review.openstack.org/192850 | 16:46 |
| *** jasondotstar is now known as jasondotstar|afk | 16:46 | |
| *** afazekas has joined #openstack-keystone | 16:49 | |
| diazjf | ***sigmavirus24 coffee is bae | 16:49 |
| sigmavirus24 | diazjf: it is | 16:49 |
| *** RichardRaseley has joined #openstack-keystone | 16:51 | |
| *** kiran-r has joined #openstack-keystone | 16:51 | |
| *** jasondotstar|afk is now known as jasondotstar | 16:53 | |
| dolphm | dstanek: what's the issue with keystone here? it sounds like something is wrong with the deploy config to me, but i'm not sure what https://bugs.launchpad.net/grenade/+bug/1466485 | 16:53 |
| openstack | Launchpad bug 1466485 in Keystone "keystone fails with: ArgsAlreadyParsedError: arguments already parsed: cannot register CLI option" [Critical,Confirmed] | 16:53 |
| *** jasondotstar is now known as jasondotstar|afk | 16:53 | |
| dstanek | dolphm: i'm trying to reproduce it now - this is based on the thread from sdague about keystone breaking one of the upgrade tenants by having some code that potentially needs to be copied after an upgrade (the wsgi handlers) | 16:55 |
| *** eandersson has quit IRC | 16:55 | |
| dolphm | dstanek: the example httpd/ stuff? | 16:56 |
| dstanek | yes | 16:57 |
| *** ducttape_ has quit IRC | 16:57 | |
| dolphm | dstanek: i really don't consider that to be part of keystone itself... it should be managed separately by the deploy tool | 16:57 |
| dstanek | there was some discussion in here a few days ago about this becoming a problem soon | 16:57 |
| dolphm | it's handy as a canonical reference, but not much more | 16:57 |
| bknudson | it must be http://git.openstack.org/cgit/openstack/keystone/tree/httpd/keystone.py | 16:57 |
| dolphm | bknudson: right. normally the deploy tool would own that file because that's the non-paste way to build your WSGI application stack | 16:58 |
| bknudson | question might be why copy it... should be able to reference it wherever it is | 16:58 |
| bknudson | http://git.openstack.org/cgit/openstack/keystone/tree/httpd/wsgi-keystone.conf has /var/www/cgi-bin/keystone/main | 16:58 |
| bknudson | oh, I guess you have to rename it. | 16:59 |
| dstanek | bknudson: that's exactly what i was saying :-) our docs, i believe, say to copy it | 16:59 |
| bknudson | name = os.path.basename(__file__) -- that's the prob | 16:59 |
| dstanek | well, in any case i can't get grenade to actually run | 17:00 |
| bknudson | we might be better off having admin and public copies of that file rather than using __file__ | 17:00 |
| bknudson | it's small enough | 17:00 |
| bknudson | then you could ref it from anywhere | 17:00 |
| *** belmoreira has quit IRC | 17:01 | |
| dstanek | bknudson: the problem i what file to you reference? it will be different on different distros | 17:01 |
| dolphm | bknudson: if that's the case, then put them into the keystone package so they can be imported and deployed into real wsgi.py files | 17:01 |
| bknudson | nice | 17:01 |
| bknudson | wait, why's it different? | 17:01 |
| dolphm | bknudson: because it should be owned by the deploy tool! | 17:01 |
| dolphm | maybe they wrap it with middleware, change the application name, etc | 17:02 |
| morganfainberg | bknudson, dolphm: there are also much stricter permission issues with mod_wsgi and how it can run than "just source" from the pythonpath | 17:02 |
| bknudson | putting it in the keystone package makes sense | 17:02 |
| morganfainberg | we could *potentially* make what is copied a very very very very basic stub that imports from the python path | 17:03 |
| *** Lactem has joined #openstack-keystone | 17:03 | |
| morganfainberg | so zero logic | 17:03 |
| *** krykowski has quit IRC | 17:03 | |
| morganfainberg | but in the python package afair wont work | 17:03 |
| dolphm | bknudson: we don't expose actual wsgi application objects anywhere in keystone, so i'd be in favor of that | 17:03 |
| morganfainberg | because of apache wsgi limits | 17:03 |
| dstanek | morganfainberg: that's basically what it is now | 17:03 |
| *** jasondotstar|afk has quit IRC | 17:03 | |
| morganfainberg | dstanek: the break is because we moved the code from it in juno | 17:03 |
| morganfainberg | erm kilo | 17:04 |
| morganfainberg | so upgrade doesn't work | 17:04 |
| morganfainberg | if we backport shuffling that code into the keystone package and similarly make it do nothing in the wsgi module | 17:04 |
| morganfainberg | the upgrade would work | 17:04 |
| Lactem | If I'm attempting to make a branch for myself in order to test code, could I just use https://github.com/openstack/keystone? It looks like that is behind https://git.openstack.org/cgit/openstack/keystone/ in commits, but I can't clone the latter. | 17:04 |
| *** diazjf has quit IRC | 17:05 | |
| morganfainberg | Lactem: https://github.com/openstack/keystone/commit/6b274951828955f65d35eb2fb9092f15d15a7bd7 is the same as http://git.openstack.org/cgit/openstack/keystone/commit/?id=6b274951828955f65d35eb2fb9092f15d15a7bd7 | 17:05 |
| morganfainberg | Lactem: you would clone from https://git.openstack.org/openstack/keystone (not the lack of cgit) | 17:06 |
| Lactem | Okay thanks. | 17:06 |
| morganfainberg | dstanek: so i don't think we can make this strictly part of the python package. but we can eliminate the issue | 17:06 |
| morganfainberg | or at least really mitigate it | 17:07 |
| Lactem | Also is there a guide on how to test my new branch of Keystone once I make it? I assume I would use git clone <url> like in http://docs.openstack.org/developer/keystone/setup.html, but instead use my branch for the url? | 17:07 |
| dstanek | morganfainberg: when you say 'make it do nothing in the wsgi module' are you talking about http/keystone.py or keystone/server/wsgi.py? | 17:10 |
| morganfainberg | dstanek: http/keystone.py | 17:10 |
| morganfainberg | dstanek: if that has no logic, the upgrade could work w/o needing to re-copy things | 17:11 |
| morganfainberg | the issue is juno->Kilo we moved the logic | 17:11 |
| morganfainberg | and the juno wsgi can't work with kilo | 17:11 |
| dstanek | morganfainberg: that side steps the issue so grenade is happy. what about people upgrading their existing installations? | 17:11 |
| morganfainberg | dstanek: again, if the wsgi file doesn't change, the upgrade is easy | 17:12 |
| morganfainberg | this is only really an issue with pip upgrades | 17:12 |
| morganfainberg | distributions will put wsgi files in sane places | 17:12 |
| *** vilobhmm has joined #openstack-keystone | 17:12 | |
| morganfainberg | but as long as we don't move the import location the wsgi file relies on, even a pip upgrade would work | 17:13 |
| morganfainberg | and i'm ok saying "this cannot move" | 17:13 |
| *** vilobhmm1 has joined #openstack-keystone | 17:14 | |
| dstanek | morganfainberg: i guess i'm confused. what, if anything, can be do here? the only think i can see is making kilo work using the old wsgi stub | 17:16 |
| morganfainberg | dstanek: we could move the logic for juno | 17:16 |
| morganfainberg | backport the basic shuffle of code | 17:16 |
| morganfainberg | i don't think it's going to be possible to make kilo work with the old stub | 17:16 |
| *** vilobhmm has quit IRC | 17:16 | |
| morganfainberg | and we document "hey if you aren't on juno X.Y.Z, copy this when upgrading" | 17:17 |
| *** ihrachyshka has quit IRC | 17:17 | |
| morganfainberg | it would solve the gate issue, and solve future pip upgrades. | 17:17 |
| morganfainberg | again packagers/distributions will do what they're going to do anyway | 17:17 |
| *** cdent has quit IRC | 17:17 | |
| dstanek | so basically make grenade happy | 17:18 |
| morganfainberg | dstanek: yep | 17:18 |
| morganfainberg | we take a long hard look at that wsgi stub in kilo | 17:18 |
| morganfainberg | make sure it's really doing *nothing* | 17:18 |
| morganfainberg | and is py3 compat | 17:18 |
| dstanek | hopefully it's just the one commit - ea8845a48f3def7a53407aadc14d45bf0609cc7d | 17:18 |
| morganfainberg | then we backport the same kind of shuffle to juno | 17:18 |
| morganfainberg | i don't want to be fighting this again next cycle | 17:18 |
| dstanek | ok, back it figuring out why grenade doesn't work for me :-( | 17:19 |
| dstanek | morganfainberg: i think the current version is as minimal as you can get | 17:19 |
| *** jasondotstar has joined #openstack-keystone | 17:20 | |
| morganfainberg | dstanek: i think we could avoid the os.path.basename | 17:20 |
| morganfainberg | but that should be compat across versions | 17:20 |
| morganfainberg | so yeah | 17:20 |
| dstanek | although is still breaks their upgrade tenant | 17:20 |
| *** jasondotstar is now known as jasondotstar|afk | 17:20 | |
| morganfainberg | ? | 17:20 |
| *** jasondotstar|afk is now known as jasondotstar | 17:20 | |
| dstanek | "New code should need nothing more than 'db migrations'" - http://git.openstack.org/cgit/openstack-dev/grenade/tree/README.rst | 17:21 |
| *** fangzhou has joined #openstack-keystone | 17:21 | |
| *** cdent has joined #openstack-keystone | 17:21 | |
| morganfainberg | we are making that the case if we backport the shuffle of code | 17:21 |
| morganfainberg | new code is contained strictly in the keystone package | 17:22 |
| morganfainberg | and db migrations are what are needed | 17:22 |
| morganfainberg | grenade doesn't need to get smarter about upgradeing the wsgi file | 17:23 |
| morganfainberg | since it becomes a fairly (100%?) static file that shouldnt change across releases | 17:23 |
| dstanek | yeah, until it's not - which is what i fear | 17:24 |
| *** cdent has quit IRC | 17:24 | |
| dstanek | in genade horizon seems to use the django.wsgi right out of their project | 17:25 |
| *** jasondotstar is now known as jasondotstar|afk | 17:26 | |
| morganfainberg | really it's no better or worse | 17:27 |
| morganfainberg | https://github.com/openstack-dev/devstack/blob/master/files/apache-horizon.template#L2 | 17:27 |
| morganfainberg | devstack mangles and assumes where this exists | 17:27 |
| morganfainberg | the assumption that a pip upgrade is all that is needed for a wsgi app is a bad assumption | 17:28 |
| morganfainberg | there is more than python things involved here | 17:28 |
| morganfainberg | we can't say "it can only ever be a python thing" | 17:28 |
| dstanek | morganfainberg: yeah, i agree. like dolphm said, it's really a deployment tool issue. | 17:28 |
| morganfainberg | so, i'm going to go out on a limb and say we need to solve this in grenade - and convince them that pip install is not sufficient | 17:29 |
| morganfainberg | with cinder also looking at wsgi installs | 17:29 |
| *** jasondotstar|afk is now known as jasondotstar | 17:29 | |
| morganfainberg | and every api leaning (slowly) that way | 17:29 |
| morganfainberg | i don't think we want broad assumptions like that | 17:29 |
| *** dguerri is now known as dguerri` | 17:30 | |
| morganfainberg | no sane deployer is going to point apache at $PYTHON_PATH/site-packages/<app>/wsgi/<app>.wsgi.py | 17:30 |
| * morganfainberg believes devstack should represent a basic level of common sense | 17:30 | |
| morganfainberg | but i might lose that argument | 17:30 |
| dstanek | haha | 17:31 |
| dstanek | i hope not | 17:31 |
| bknudson | is somebody supposed to merge master with the feature/keystoneauth_integration branch? | 17:42 |
| *** kiran-r has quit IRC | 17:42 | |
| *** rushiagr is now known as rushiagr_away | 17:49 | |
| dolphm | bknudson: to update the feature branch? | 17:49 |
| bknudson | dolphm: yes, to keep the feature branch in sync with master | 17:50 |
| *** openstackgerrit has quit IRC | 17:50 | |
| bknudson | according to -infra, nobody has merge authority so nobody can do it. | 17:51 |
| *** openstackgerrit has joined #openstack-keystone | 17:51 | |
| *** jasondot_ has joined #openstack-keystone | 17:51 | |
| *** marzif has joined #openstack-keystone | 17:52 | |
| *** jasondot_ has quit IRC | 17:53 | |
| *** kr4zy_ has quit IRC | 18:02 | |
| *** henrynash has joined #openstack-keystone | 18:03 | |
| *** ChanServ sets mode: +v henrynash | 18:03 | |
| *** kr4zy has joined #openstack-keystone | 18:04 | |
| *** jasondotstar is now known as jasondotstar|afk | 18:07 | |
| *** afazekas has quit IRC | 18:08 | |
| *** HT_sergio has joined #openstack-keystone | 18:12 | |
| *** yottatsa has joined #openstack-keystone | 18:13 | |
| *** roxanaghe has joined #openstack-keystone | 18:13 | |
| *** samueldmq2 has joined #openstack-keystone | 18:14 | |
| *** samueldmq__ has joined #openstack-keystone | 18:15 | |
| *** jasondotstar|afk is now known as jasondotstar | 18:15 | |
| *** jasondotstar is now known as jasondotstar|afk | 18:15 | |
| *** yottatsa has quit IRC | 18:16 | |
| *** samueldmq has quit IRC | 18:17 | |
| *** samueldmq2 has quit IRC | 18:18 | |
| *** jamie_h has quit IRC | 18:19 | |
| Lactem | Could anyone help direct me where to find the file in which commands are handled in Keystone? I'm specifically looking for keystone endpoint-create and delete. (Sorry. I'm good with Java, but not so much Python and this API yet.) | 18:21 |
| dstanek | Lactem: that's in python-keystoneclient, but will be removed in favor of python-openstackclient | 18:21 |
| *** samueldmq2 has joined #openstack-keystone | 18:22 | |
| Lactem | I'm actually trying to work on this bug since I'm a beginner to OpenStack (it doesn't look too hard): https://bugs.launchpad.net/keystone/+bug/1098564. @dolphm commented on it before. | 18:22 |
| openstack | Launchpad bug 1098564 in Keystone "Cannot delete a service or endpoint" [Low,Confirmed] | 18:22 |
| Lactem | dstanek: So that command is being removed entirely? It needs an equivalent to still be used in cmd line, right? | 18:22 |
| dstanek | Lactem: the command-line portion of it is being removed in favor of the openstackclient - the functionality will remain | 18:23 |
| Lactem | Hmm. | 18:23 |
| *** samueldmq has joined #openstack-keystone | 18:23 | |
| Lactem | What if people need to use command line, though? Is it not going to still be an option? | 18:24 |
| dstanek | so it looks like you want the server side of the logic anyway - at least according to that bug | 18:24 |
| Lactem | Yes. | 18:24 |
| Lactem | But I don't know where the command is being handled. | 18:24 |
| dstanek | keystone.catalog handles managing endpoints | 18:25 |
| Lactem | Fixing this bug should contribute to python-openstackclient, too, right, since it's functionality? | 18:25 |
| dstanek | you'll find a controllers module in there that is the starting point for the work flow | 18:25 |
| Lactem | Okay thank you. I'll read through that code. | 18:25 |
| *** samueldmq__ has quit IRC | 18:25 | |
| dstanek | routers will show you how the url maps to the controller | 18:25 |
| dstanek | the controller will mostly use a driver that you'll find in the backends package | 18:26 |
| *** samueldmq2 has quit IRC | 18:26 | |
| Lactem | Thank you very much. | 18:26 |
| dstanek | np | 18:27 |
| *** jasondotstar|afk has quit IRC | 18:27 | |
| *** rlt_ has quit IRC | 18:29 | |
| *** samueldmq2 has joined #openstack-keystone | 18:30 | |
| *** Ctina__ has quit IRC | 18:34 | |
| *** samueldmq has quit IRC | 18:34 | |
| *** marzif has quit IRC | 18:37 | |
| *** samueldmq__ has joined #openstack-keystone | 18:38 | |
| *** thedodd has quit IRC | 18:38 | |
| *** charlesw_ has joined #openstack-keystone | 18:38 | |
| *** charlesw has quit IRC | 18:39 | |
| *** charlesw_ is now known as charlesw | 18:39 | |
| *** samueldmq has joined #openstack-keystone | 18:39 | |
| *** marzif has joined #openstack-keystone | 18:40 | |
| *** samueldmq2 has quit IRC | 18:42 | |
| *** samueldmq__ has quit IRC | 18:42 | |
| *** samueldmq2 has joined #openstack-keystone | 18:44 | |
| *** samueldmq__ has joined #openstack-keystone | 18:44 | |
| *** henrynash has quit IRC | 18:45 | |
| *** kfox1111 has quit IRC | 18:47 | |
| *** marzif has quit IRC | 18:47 | |
| *** samueldmq has quit IRC | 18:47 | |
| *** samueldmq2 has quit IRC | 18:48 | |
| *** samueldmq has joined #openstack-keystone | 18:48 | |
| *** henrynash has joined #openstack-keystone | 18:50 | |
| *** ChanServ sets mode: +v henrynash | 18:50 | |
| *** kfox1111 has joined #openstack-keystone | 18:51 | |
| *** samueldmq__ has quit IRC | 18:51 | |
| *** samueldmq2 has joined #openstack-keystone | 18:51 | |
| *** spandhe has quit IRC | 18:54 | |
| *** samueldmq__ has joined #openstack-keystone | 18:54 | |
| *** samueldmq has quit IRC | 18:55 | |
| *** samueldmq has joined #openstack-keystone | 18:55 | |
| *** samueldmq2 has quit IRC | 18:57 | |
| *** samueldmq2 has joined #openstack-keystone | 18:57 | |
| *** samueldmq__ has quit IRC | 18:58 | |
| samueldmq2 | Oh, looks like I've been disconnecting too many times :( | 18:59 |
| *** samueldmq has quit IRC | 19:00 | |
| *** samueldmq2 is now known as samueldmq | 19:00 | |
| dstanek | samueldmq: just a bit :-) | 19:00 |
| *** samueldmq2 has joined #openstack-keystone | 19:01 | |
| *** jasondotstar has joined #openstack-keystone | 19:01 | |
| *** jasondot_ has joined #openstack-keystone | 19:01 | |
| *** jasondotstar has quit IRC | 19:02 | |
| *** diazjf has joined #openstack-keystone | 19:02 | |
| *** samueldmq has quit IRC | 19:05 | |
| *** samueldmq2 has quit IRC | 19:05 | |
| *** jasondot_ is now known as jasondotstar|afk | 19:07 | |
| morganfainberg | dolphm: Swype keyboard for iOS has gotten way better. | 19:15 |
| * morganfainberg is amazed | 19:15 | |
| morganfainberg | It mostly just works | 19:15 |
| *** fangzhou_ has joined #openstack-keystone | 19:16 | |
| *** fangzhou has quit IRC | 19:16 | |
| *** fangzhou_ is now known as fangzhou | 19:16 | |
| morganfainberg | bknudson: huh we should fix the merge authority for the feature branch then | 19:18 |
| dolphm | *reinstalling* | 19:18 |
| morganfainberg | Dolphm: It doesn't do the autocorrect as much. You have to select from the prediction bar. | 19:19 |
| dolphm | that sounds like a fantastic change | 19:19 |
| dolphm | i have autocorrect turned off completely with the regular keyboard. i'd rather type garbage than something i didn't intend at all | 19:20 |
| morganfainberg | dolphm: i also have the full access turned off so i am not getting the"new trending words " feature atm | 19:20 |
| morganfainberg | But it does seem to really do quite a good job. The spacing is a little different than the default keyboard so normal typing is a bit slower for me atm | 19:21 |
| morganfainberg | But not a lot slower | 19:22 |
| *** Lactem has quit IRC | 19:22 | |
| dolphm | morganfainberg: is new trending words like things you've added to your local dictionary, or like new pronouns invented on twitter today? | 19:22 |
| morganfainberg | I assume intertube based words. | 19:22 |
| *** uschreiber_ has joined #openstack-keystone | 19:23 | |
| morganfainberg | It seems to learn what I type. It also asks if I want to add any words to the dictionary when it doesn't know / can't predict anything based on what you're typing. | 19:23 |
| morganfainberg | S/you're/i'm | 19:24 |
| *** thedodd has joined #openstack-keystone | 19:25 | |
| dolphm | how do you make it learn new words? swyping "riverwalk" results in "riverbank" everytime, but i don't see a way to tell it something different | 19:25 |
| morganfainberg | dolphm: my guess is type it multiple times. | 19:25 |
| *** uschreiber_ has quit IRC | 19:25 | |
| dolphm | OH - you have to type it without swyping at all | 19:26 |
| dolphm | and THEN it'll appear in the suggestion list, you hit it, and it'll ask if you want it to learn that word | 19:26 |
| morganfainberg | Yeah Swype can't guess things it doesn't know. | 19:26 |
| *** roxanaghe has quit IRC | 19:27 | |
| *** jasondotstar|afk is now known as jasondot_ | 19:27 | |
| *** jasondot_ is now known as jasondotstar|afk | 19:27 | |
| *** jasondotstar|afk has quit IRC | 19:27 | |
| dolphm | Well yeah, but I'd expect a better UX to teach our new words though | 19:27 |
| morganfainberg | Oh crap I may have to uninstall it. It just suggested dynasty as the logical prediction after duck.:p | 19:28 |
| dolphm | s/our/it/ | 19:28 |
| dolphm | rofl | 19:28 |
| morganfainberg | Yeah the learn UX has some glaring gaps still. | 19:29 |
| morganfainberg | But overall the keyboard is much much better than before. | 19:29 |
| morganfainberg | Ooh. https://www.python.org/dev/peps/pep-0447/ | 19:33 |
| morganfainberg | That's cool. | 19:33 |
| morganfainberg | Also. https://www.python.org/dev/peps/pep-0484/ | 19:34 |
| *** jasondotstar has joined #openstack-keystone | 19:36 | |
| morganfainberg | dolphm: found an issue with Swype. No way to hide the keyboard. | 19:38 |
| morganfainberg | Or... Hmm | 19:38 |
| morganfainberg | Nvm | 19:38 |
| dstanek | type hints will be interesting | 19:38 |
| dstanek | lots of talk about that at pycon this year | 19:39 |
| *** samueldmq has joined #openstack-keystone | 19:43 | |
| openstackgerrit | Diane Fleming proposed openstack/keystone-specs: Add side-by-side comparison table of v2 and v3 APIs https://review.openstack.org/187027 | 19:44 |
| *** ninag has quit IRC | 19:45 | |
| *** samueldmq2 has joined #openstack-keystone | 19:46 | |
| *** r-daneel has joined #openstack-keystone | 19:47 | |
| *** jasondotstar is now known as jasondotstar|afk | 19:47 | |
| *** samueldmq has quit IRC | 19:49 | |
| *** samueldmq2 has quit IRC | 19:50 | |
| *** jasondotstar|afk is now known as jasondotstar | 19:52 | |
| *** belmoreira has joined #openstack-keystone | 19:58 | |
| *** diazjf has quit IRC | 20:02 | |
| *** ankita_wagh has joined #openstack-keystone | 20:05 | |
| *** jasondotstar is now known as jasondotstar|afk | 20:06 | |
| *** jasondotstar|afk is now known as jasondotstar | 20:06 | |
| *** jasondotstar is now known as jasondotstar|afk | 20:06 | |
| bknudson | let's just use java | 20:07 |
| dstanek | sounds like those crusty old guys that use to say, "let's just use cobol" | 20:08 |
| bknudson | python seems to be looking for things to do. | 20:08 |
| *** charlesw_ has joined #openstack-keystone | 20:08 | |
| *** jasondotstar|afk is now known as jasondotstar | 20:08 | |
| bknudson | just call it done | 20:08 |
| dstanek | we haven't even gotten to the 4.0 rewrite yet! | 20:08 |
| morganfainberg | htruta: so the only concern i have with only requiring the hierarchy in a name conflict remains | 20:09 |
| *** charlesw has quit IRC | 20:09 | |
| *** charlesw_ is now known as charlesw | 20:09 | |
| morganfainberg | htruta: you're going to break people when renames happen. in cases that worked even minutes/seconds before | 20:09 |
| morganfainberg | htruta: I am thinking the only real solution is never issue a domain scope token again | 20:10 |
| *** kr4zy has quit IRC | 20:10 | |
| *** kr4zy has joined #openstack-keystone | 20:10 | |
| morganfainberg | htruta: i don't think without redesigning the HMT stuff we are going to back ourselves out of this corner | 20:10 |
| morganfainberg | raildo, rodrigods, cc ^^ | 20:11 |
| morganfainberg | is there a reason we even need domain scope in reality? or can we really just drop domain scoped tokens and allow extra actions to occur on "is_domain" projects. | 20:11 |
| morganfainberg | also, at any reasonable depth of project hierarchy we don't have compatibility issues. | 20:11 |
| *** kr4zy has quit IRC | 20:12 | |
| *** kr4zy has joined #openstack-keystone | 20:14 | |
| *** samueldmq has joined #openstack-keystone | 20:14 | |
| samueldmq | ayoung-afk: good news | 20:14 |
| *** ayoung-afk is now known as ayoung | 20:14 | |
| ayoung | samueldmq, I like hearing good news | 20:15 |
| samueldmq | ayoung: https://wiki.openstack.org/wiki/DynamicPolicies#Workflows_-_Liberty_Scope | 20:15 |
| samueldmq | ayoung:what you asked me earlier :) | 20:15 |
| *** samueldmq2 has joined #openstack-keystone | 20:15 | |
| samueldmq2 | ayoung: the sequence diagram (I used the tool you suggested, and put more details) | 20:15 |
| ayoung | samueldmq, there is something wonky with your diagram, though. Where is the source? | 20:16 |
| *** samueldmq has quit IRC | 20:16 | |
| ayoung | samueldmq2, I see at least one place where Keystone is calling into the CMS. I assume that is just an artifact of trial and error. | 20:17 |
| *** samueldmq2 has quit IRC | 20:17 | |
| htruta | morganfainberg: why are we breaking people after renaming? | 20:18 |
| *** kr4zy has quit IRC | 20:18 | |
| *** samueldmq2 has joined #openstack-keystone | 20:18 | |
| morganfainberg | htruta: so what happens is project is in a hierarchy | 20:18 |
| samueldmq2 | ayoung, my connection is too bad today, sorry | 20:18 |
| samueldmq2 | ayoung, http://www2.lsd.ufcg.edu.br/~samuel/dynamic-policies-workflow.diag | 20:18 |
| morganfainberg | htruta: that has no conflict, then you rename it's parent (which is allowed) | 20:19 |
| samueldmq2 | ayoung, there is the source ^ | 20:19 |
| morganfainberg | htruta and now there is a conflict, now the auth request fails - and it was 100% valid/working before | 20:19 |
| morganfainberg | htruta: or someone drops a project with a name conflict under it | 20:19 |
| samueldmq2 | ayoung, I generated that diagram using the python tool though, it couldn't be generated online since it's big, hehe | 20:19 |
| morganfainberg | htruta: basically there isn't a consistent "this will work" interface people can program to. You always need to pass the hierarchy or are at risk of having random failures in the future. in short, we should always require the hierarchy -- it means there isn't a chance something will break because of an action of another user. | 20:20 |
| htruta | morganfainberg: that renaming issue will always happen, unless I use project_id... so, I do not understand how always passing the hierarchy will solve it | 20:21 |
| htruta | that's something the child projects will always be depending on the parents | 20:22 |
| morganfainberg | htruta: the issue is a rename of a child could *also* break it | 20:22 |
| morganfainberg | the interface is basically saying "requesting things like X will work, until they don't then you need to do Y", so the logical conclusion is always do Y. | 20:23 |
| morganfainberg | why not just make that the norm | 20:23 |
| htruta | morganfainberg: got it | 20:23 |
| htruta | morganfainberg: then, considering that we'll do Y (always requiring the hierarchy), how won't we break every single deploy that makes the request by name? | 20:24 |
| htruta | project name | 20:24 |
| morganfainberg | htruta: we *can* make it so that in a hierarchy you need the hierarchy passed. outside of a hierarchy you just do things as you would normally | 20:25 |
| morganfainberg | no one is broken that way | 20:25 |
| morganfainberg | right? | 20:25 |
| morganfainberg | and i *think* we said where project.is_domain=True, you never issue a project scoped token for anyway, right? | 20:26 |
| * morganfainberg can't remember the result of that conversation | 20:26 | |
| *** samueldmq2 has quit IRC | 20:27 | |
| raildo | morganfainberg, in fact, we want to provide a project scoped token to project.is_domain=True | 20:27 |
| morganfainberg | oh ok so never a domain_scoped token | 20:27 |
| morganfainberg | ? | 20:27 |
| morganfainberg | or still possible to get either/or | 20:27 |
| htruta | morganfainberg: we wanted both of them | 20:27 |
| * morganfainberg isn't sure this is a good idea | 20:27 | |
| htruta | either | 20:27 |
| morganfainberg | not sure what the benefit of the domain scope really is. | 20:27 |
| htruta | not both, not dual | 20:27 |
| htruta | I've heard someone say that they don't want to mix the capabilities of a domain admin and project admin | 20:28 |
| morganfainberg | would it make it easier if domain scope just went away? | 20:28 |
| morganfainberg | who said that? | 20:28 |
| * morganfainberg looks at ayoung (just a guess) | 20:28 | |
| htruta | I don't think domain scoped token is a problem for us, at all | 20:28 |
| htruta | guess it was gyee | 20:28 |
| morganfainberg | we could (initially) only ever allow domain scoped tokens for the domains as we do today | 20:29 |
| morganfainberg | and loosen that restriction down the line | 20:29 |
| gyee | \o | 20:29 |
| raildo | morganfainberg, if a domain_admin will do the same actions with a project scoped token then before, I'm ok with this. | 20:29 |
| gyee | we mix domain and project admin, there will be trouble | 20:29 |
| morganfainberg | gyee: then lets not allow project admins on domains for now | 20:29 |
| gyee | absolutely | 20:30 |
| morganfainberg | lets not try and boil the ocean and solve every issue | 20:30 |
| morganfainberg | raildo, ^^ | 20:30 |
| morganfainberg | we can circle up on that after - it narrows the complexity of potential issues down a lot | 20:30 |
| * morganfainberg is seeing a lot of landmines around reseller atm | 20:30 | |
| morganfainberg | and i don't want us to step in them. | 20:30 |
| * gyee let morganfainberg walk in front of him | 20:31 | |
| htruta | morganfainberg: so, you are suggesting that we don't allow is_domain projects to get project scoped tokens? | 20:32 |
| htruta | at least, not in Liberty | 20:32 |
| morganfainberg | htruta: yes. | 20:32 |
| morganfainberg | htruta: it's a simple if-check and it can allow us to be more directed about avoiding edge cases while opening up reseller | 20:32 |
| *** aix has joined #openstack-keystone | 20:33 | |
| *** samueldmq has joined #openstack-keystone | 20:33 | |
| morganfainberg | htruta: with a resource that can be both project and domain (but not at the same time in a authz scope) we open a lot of strange edge cases we need to evaluate | 20:33 |
| samueldmq | dstanek: I think I am good now ... no more issues with connection :) | 20:33 |
| gyee | first bug you are going to see will be "elevated privilege" if we allow project admin to get a domin admin token or vice versa :) | 20:34 |
| samueldmq | dstanek: connected to the laboratory and set up tmux + irssi | 20:34 |
| samueldmq | ayoung: I am back, sorry I was having issues with my connection | 20:34 |
| htruta | gyee: the idea wasn't that... the assignments would remain separated | 20:34 |
| morganfainberg | htruta: lets totally dodge that for the moment | 20:35 |
| htruta | morganfainberg: isn't this approach making it difficult to set quotas in reseller? | 20:35 |
| raildo | morganfainberg, imo, it will limit a lot the reseller usability, since we can set quotas to a project.is_domain=True, without provide a project scoped token. | 20:35 |
| raildo | we can't* | 20:36 |
| morganfainberg | raildo: i'm honestly worried reseller is going to be rife with CVEs at the moment | 20:36 |
| *** pnavarro has joined #openstack-keystone | 20:36 | |
| morganfainberg | i would rather solve the quota on a domain issue than deal with 5 new priv escalation issues | 20:36 |
| morganfainberg | this is personal preference | 20:36 |
| gyee | morganfainberg, ++ | 20:37 |
| morganfainberg | i know it sucks to make other projects domain aware | 20:38 |
| htruta | morganfainberg: I think no one outside of keystone wants domains | 20:38 |
| morganfainberg | but either that *or* we do away with domain scope 100% | 20:38 |
| morganfainberg | and we commit to fixing the mix/priv issues | 20:38 |
| raildo | morganfainberg, I see your point, I'm just tough that behaviour(provide project scoped token) will be normal, and really useful in a future... | 20:38 |
| morganfainberg | i don't think we want either/or | 20:38 |
| morganfainberg | the resource acting as either a domain or project is what worries me, because it opens a lot of edge cases | 20:39 |
| htruta | is henrynash around? | 20:39 |
| morganfainberg | if we pick one side or the other - we can focus on making it correct that way | 20:39 |
| morganfainberg | i don't have a strong opinion which side, just that having a mish-mash scares me | 20:39 |
| *** HT_sergio has quit IRC | 20:39 | |
| morganfainberg | i know gyee would rather have the clear separation, but i think we can address the problems if we make everything project only | 20:40 |
| raildo | morganfainberg, I prefer work to deprecated domain scoped token :P | 20:40 |
| raildo | deprecate* | 20:40 |
| morganfainberg | raildo: i'd not deprecate domain scope, i'd make it just disappear. | 20:40 |
| raildo | ++ | 20:40 |
| htruta | I was really liking the idea of domains being a powerful project, once we won't need to put domains in other services | 20:40 |
| morganfainberg | no longer issued, make keystone handle project scope correctly in the project.is_domain=True case | 20:40 |
| morganfainberg | htruta: i think that if we want domains to be a special powerful class of object, we need other services aware of them | 20:41 |
| morganfainberg | it's not something we can isolate to keystone | 20:41 |
| morganfainberg | otherwise it's "that weird thing keystone does, and isn't that useful in most cases" | 20:41 |
| morganfainberg | if that makes sense. | 20:41 |
| *** marzif has joined #openstack-keystone | 20:41 | |
| gyee | domain is a keystone only concept, other services don't care about it | 20:42 |
| morganfainberg | gyee: it either needs to be supported by other services (quota, etc for hierarchy reasons) | 20:43 |
| morganfainberg | or .. it needs to go away | 20:43 |
| morganfainberg | i don't think there is a good middleground here | 20:43 |
| gyee | it offer a great deal of value for multitenancy and resource isolation | 20:44 |
| lbragstad | dstanek: question for you on some database fixture stuff https://github.com/openstack/keystone/commit/01b0f4cd7da5773e2a8d865a181899ff5b856ff2 | 20:44 |
| morganfainberg | gyee: so it can't be just a keystone concept then | 20:44 |
| morganfainberg | or it shouldn't be | 20:44 |
| lbragstad | because of this line (https://github.com/openstack/keystone/commit/01b0f4cd7da5773e2a8d865a181899ff5b856ff2#diff-c5219e3fcf442ecbfa092ae7d06e6908R105) the test database will be dropped after the tests run, right? | 20:45 |
| dstanek | either way other services will have to know about domains; the question i have is should they be aware of domains that act as projects too | 20:45 |
| *** belmoreira has quit IRC | 20:45 | |
| morganfainberg | dstanek: if we squash all scopes to project - it means other services just need to learn what an is_domain flag is vs. learning what a domain scope is | 20:45 |
| morganfainberg | i think that is a lower barrier | 20:45 |
| raildo | I agree that we need to extend the domain concept to other services, maybe think in some use cases and do a cross project session in the next summit to discuss this | 20:45 |
| gyee | so what do they do with domains? | 20:45 |
| morganfainberg | but... if we need the separation | 20:45 |
| gyee | for quota management? | 20:45 |
| htruta | but having them as projects might make it easier | 20:45 |
| morganfainberg | gyee: quota, image management, swift bucket collections, barbican shared secrets across all projects | 20:46 |
| morganfainberg | gyee: etc | 20:46 |
| gyee | I thought we are centralize quota management in Keystone at one point | 20:46 |
| morganfainberg | no | 20:46 |
| morganfainberg | no | 20:46 |
| morganfainberg | and no | 20:46 |
| morganfainberg | please no | 20:46 |
| raildo | haha | 20:46 |
| *** charlesw has quit IRC | 20:46 | |
| htruta | lol | 20:46 |
| morganfainberg | oh god no | 20:46 |
| gyee | wow, 5 nos | 20:46 |
| raildo | keep calm and no quotas in keystone | 20:47 |
| *** kr4zy has joined #openstack-keystone | 20:47 | |
| morganfainberg | raildo: ++ | 20:47 |
| *** henrynash has quit IRC | 20:47 | |
| *** stevemar has quit IRC | 20:48 | |
| raildo | ok, I'm sad but we will remove project scoped token to project.is_domain=True | 20:48 |
| morganfainberg | raildo: so like i said, i don't really mind if we go the otherway | 20:48 |
| morganfainberg | you just need to help me sway gyee 's view on it | 20:49 |
| * morganfainberg would prefer to make "domain scope" [being an explicit scope] disappear | 20:49 | |
| raildo | i will think more about this. If we don't find a way to do this in Liberty, i'll come back in M with a solution | 20:49 |
| morganfainberg | but i get that we have to pick what is achievable. | 20:49 |
| gyee | if we can make it work without privilege bleedover | 20:49 |
| morganfainberg | gyee: if we commit to no explicit domain scope, i think we can | 20:50 |
| *** Lactem has joined #openstack-keystone | 20:50 | |
| morganfainberg | if we allow for a resource to be domain and/or project | 20:50 |
| morganfainberg | we're going to run into lots of edge cases | 20:50 |
| Lactem | Is there a guide somewhere that explains how to do unit tests on Keystone? | 20:50 |
| morganfainberg | i'd rather commit to clear cut target case. | 20:50 |
| Lactem | I edited a .py file on my computer and need to test it on the vm. | 20:50 |
| morganfainberg | Lactem: so we us tox, i typically rune "tox -epy27" | 20:51 |
| *** pnavarro has quit IRC | 20:51 | |
| morganfainberg | Lactem in the keystone directory | 20:51 |
| morganfainberg | Lactem: that will make a venv and build all the dependencies for you and then run the unit tests | 20:51 |
| Lactem | How will I tell it to use my new file instead of the old? | 20:51 |
| morganfainberg | Lactem: if you updated a file in-place, it will test the file | 20:51 |
| morganfainberg | it tests what is in that directory | 20:51 |
| morganfainberg | if you're adding a new file, you need to write specific tests to make sure the new module is tested (aka if it's a driver) | 20:52 |
| Lactem | But you see my directory that I edited is in my actual computer. I have the actual Keystone running in a VM. | 20:52 |
| Lactem | I just edited a file. It's not new. | 20:52 |
| morganfainberg | Lactem: so unit tests are run local to the tox command | 20:52 |
| morganfainberg | if you're looking to do a functional/does this api work like i expect test | 20:52 |
| gyee | morganfainberg, raildo, can you update the spec? I need to think it through | 20:52 |
| Lactem | Okay so I can just run tox in my vagrant directory? | 20:53 |
| morganfainberg | you'd need to upload your new file to the VM | 20:53 |
| Lactem | Yeah okay so how do I do that? | 20:53 |
| morganfainberg | Lactem: i don't know enough about your setup. | 20:53 |
| morganfainberg | Lactem: i do my development on linux these days | 20:53 |
| morganfainberg | so i just run tox locally | 20:53 |
| Lactem | I'm running Ubuntu. | 20:53 |
| morganfainberg | or i upload the whole (scp?) keystone project to a vm | 20:53 |
| raildo | gyee, sure, we will do this asap :) | 20:53 |
| morganfainberg | then run tests in the vm | 20:53 |
| Lactem | Okay so I have to get the edited file to my VM. | 20:54 |
| morganfainberg | gyee: i'm trying to make it so you don't have to think about it three different ways man ;) | 20:54 |
| Lactem | How would I go about that? Sorry for my noob questions. | 20:54 |
| morganfainberg | Lactem: you can scp the keystone directory to your VM. | 20:54 |
| morganfainberg | i have no idea how vagrant works these days since i don't use it | 20:54 |
| htruta | morganfainberg: so, those beautiful things about passing the hierarchy are going to M ? | 20:54 |
| dstanek | Lactem: why don't you just edit directly on the VM? | 20:54 |
| htruta | and we'll keep project names unique in domains (not in parents) | 20:54 |
| morganfainberg | htruta: we probably still need it. | 20:55 |
| morganfainberg | dstanek: ++ | 20:55 |
| morganfainberg | htruta: depends which way the spec is updated (all project scope, or domain's can't be project scope) | 20:55 |
| *** ankita_w_ has joined #openstack-keystone | 20:56 | |
| Lactem | dstanek: Because I'm not that experienced with Linux and would screw up trying to edit code from inside a VM. | 20:56 |
| bknudson | Lactem: there's an #openstack-101 channel for new contributors | 20:56 |
| dstanek | when you get a project scoped token you'll still pass in the domain to use right? | 20:56 |
| htruta | dstanek: yes | 20:56 |
| Lactem | I'm just here because I'm working on a Keystone bug. | 20:56 |
| dstanek | why is the Project<is_domain=True>'s domain itself? | 20:57 |
| htruta | dstanek: because it is a domain | 20:57 |
| dstanek | Lactem: that's the beauty of VMs. if you mess it up too badly you can recreate | 20:57 |
| Lactem | I don't know how to do it, though, since I'm in SSH. | 20:58 |
| Lactem | I kind of need a GUI like Sublime to edit Python code. | 20:58 |
| dstanek | Lactem: nano? | 20:58 |
| dstanek | Lactem: also with virtualbox you can mount the directory from the VM to your machine | 20:58 |
| htruta | Lactem: or vim | 20:59 |
| *** ankita_wagh has quit IRC | 20:59 | |
| *** e0ne has joined #openstack-keystone | 20:59 | |
| Lactem | I don't like vim. | 20:59 |
| Lactem | I think I'll try the mounting, though. Thanks. | 21:00 |
| bknudson | I tried mounting from my host system and it wound up being a disaster. | 21:00 |
| *** jamielennox is now known as jamielennox|away | 21:01 | |
| bknudson | I tried using sshfs | 21:02 |
| bknudson | I forget what the issues were. | 21:02 |
| *** marzif has quit IRC | 21:03 | |
| kfox1111 | 23'rds cutoff day for the instance users spec. Please +1 or raise issues now. | 21:03 |
| *** pnavarro has joined #openstack-keystone | 21:03 | |
| dstanek | lbragstad: yes, i think so | 21:05 |
| *** raildo has quit IRC | 21:06 | |
| lbragstad | dstanek: gotcha, I was attempting to load a test database with specific data but i would fail most of the tests because they can't access assumed values in the database (like the default domain) | 21:06 |
| dstanek | lbragstad: using the fixture? | 21:07 |
| lbragstad | dstanek: yeah | 21:07 |
| *** jamielennox|away is now known as jamielennox | 21:09 | |
| dstanek | lbragstad: do you have an example i can look at? i have to run for a bit, but i'll be back on later | 21:10 |
| lbragstad | dstanek: yeah, I'll see if I can get one together and ping it to you | 21:11 |
| dstanek | lbragstad: perfect | 21:11 |
| lbragstad | it might be a bit though | 21:11 |
| morganfainberg | kfox1111: please link the spec for review. | 21:12 |
| morganfainberg | keystone-core, please review kfox1111's nova spec. | 21:12 |
| gyee | on it | 21:13 |
| *** diazjf has joined #openstack-keystone | 21:15 | |
| *** Xurong has quit IRC | 21:15 | |
| *** Xurong has joined #openstack-keystone | 21:15 | |
| *** Xurong has quit IRC | 21:16 | |
| *** Xurong has joined #openstack-keystone | 21:16 | |
| *** openstack_ has joined #openstack-keystone | 21:17 | |
| *** openstack__ has joined #openstack-keystone | 21:18 | |
| *** openstack__ has quit IRC | 21:18 | |
| *** openstack__ has joined #openstack-keystone | 21:19 | |
| *** openstack__ has quit IRC | 21:19 | |
| *** openstack__ has joined #openstack-keystone | 21:20 | |
| *** openstack__ has quit IRC | 21:20 | |
| *** Xurong has quit IRC | 21:21 | |
| *** kfox1111 is now known as kfox1111_afk | 21:22 | |
| *** htruta_ has joined #openstack-keystone | 21:23 | |
| *** openstack_ has quit IRC | 21:23 | |
| *** fangzhou has quit IRC | 21:25 | |
| *** ankita_wagh has joined #openstack-keystone | 21:32 | |
| *** ankita_w_ has quit IRC | 21:35 | |
| *** timburke has joined #openstack-keystone | 21:38 | |
| bknudson | what do you think about deprecating the sizelimit middleware in the keystone paste pipeline? | 21:40 |
| bknudson | if you're running in apache you should use apache's functionality for this | 21:40 |
| bknudson | not sure how we would code that up other than to remove it from the default pipeline | 21:40 |
| bknudson | from the sample | 21:40 |
| bknudson | I'll just make a blueprint and propose the patch | 21:44 |
| *** pnavarro has quit IRC | 21:45 | |
| bigjools | good morning, 'stoners | 21:46 |
| *** fangzhou has joined #openstack-keystone | 21:50 | |
| *** Raildo has joined #openstack-keystone | 21:50 | |
| morganfainberg | bknudson: i think that is fine to do | 21:50 |
| morganfainberg | bknudson: as long as we document the alternative and how to configure it | 21:50 |
| bknudson | I'll fill in the bp so we can write up some release notes. | 21:51 |
| openstackgerrit | Merged openstack/keystone: Update version for Liberty https://review.openstack.org/192405 | 21:52 |
| bknudson | version 8! | 21:52 |
| bknudson | we're going backwards | 21:52 |
| *** bknudson has quit IRC | 21:54 | |
| Lactem | https://bugs.launchpad.net/keystone/+bug/1098564/comments/3 Could anyone take a quick look at that please? I think I did this correctly, but I'm not 100% sure since the bug was already confirmed. It wasn't a problem when I did it this way, though. | 21:54 |
| openstack | Launchpad bug 1098564 in Keystone "Cannot delete a service or endpoint" [Low,Confirmed] | 21:54 |
| Lactem | You also commented on this bug two years ago @dolphm. | 21:57 |
| *** kr4zy has quit IRC | 22:00 | |
| *** browne has quit IRC | 22:01 | |
| *** browne has joined #openstack-keystone | 22:02 | |
| *** diazjf has quit IRC | 22:03 | |
| *** zzzeek has quit IRC | 22:03 | |
| *** trey has joined #openstack-keystone | 22:04 | |
| dolphm | Lactem: looking | 22:06 |
| dolphm | Lactem: ooh, this bug is familiar | 22:07 |
| dolphm | Lactem: what's the output of your `keystone catalog` now? | 22:07 |
| dolphm | Lactem: i'm hoping the broken endpoint is actually supressed from that output? | 22:07 |
| *** Lactem has quit IRC | 22:15 | |
| *** Lactem has joined #openstack-keystone | 22:15 | |
| dolphm | Lactem: https://bugs.launchpad.net/keystone/+bug/1098564/comments/4 | 22:16 |
| openstack | Launchpad bug 1098564 in Keystone "Cannot delete a service or endpoint" [Low,Incomplete] | 22:16 |
| Lactem | Hey. | 22:16 |
| Lactem | Sorry I left. My computer froze. | 22:16 |
| dolphm | Lactem: no worries, did you get my messages from the last few minutes? | 22:17 |
| Lactem | Thanks for the reply! That was fast. | 22:17 |
| Lactem | I just saw you link me your comment, but that's it. | 22:17 |
| dolphm | Lactem: http://cdn.pasteraw.com/qdvz8p6s7smjx7qfe789h4h8vh5pmnj | 22:17 |
| dolphm | Lactem: as a sanity check, add both an invalid/broken endpoint AND a valid endpoint, and then verify your `keystone catalog` only contains the good one | 22:18 |
| dolphm | and hopefully there's a warning in the server logs about the presence of a malformed endpoint | 22:18 |
| Lactem | Okay. I may have to restart the vm and it might take a while since I crashed. | 22:18 |
| dolphm | no worries | 22:19 |
| *** __TheDodd__ has joined #openstack-keystone | 22:23 | |
| *** thedodd has quit IRC | 22:27 | |
| *** diazjf has joined #openstack-keystone | 22:27 | |
| *** ankita_w_ has joined #openstack-keystone | 22:29 | |
| *** e0ne has quit IRC | 22:31 | |
| *** ankita_wagh has quit IRC | 22:32 | |
| *** browne has quit IRC | 22:32 | |
| *** edmondsw has quit IRC | 22:43 | |
| lifeless | jamielennox: ping. nag. you know what i want :) | 22:44 |
| lifeless | morganfainberg: also have you updated your talk ? I haven't logged into cross check yet. | 22:44 |
| *** crinkle has quit IRC | 22:44 | |
| *** browne has joined #openstack-keystone | 22:44 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 22:44 | |
| Lactem | dolphm: I have to completely remake the VM. After it's ready, you want me to try doing the stuff I did in my post and then tell you what keystone catalog says? | 22:45 |
| *** RichardRaseley has quit IRC | 22:46 | |
| morganfainberg | lifeless: on my list to do today/tomorrow | 22:46 |
| *** jasondotstar has quit IRC | 22:46 | |
| *** RichardRaseley has joined #openstack-keystone | 22:46 | |
| lifeless | morganfainberg: please. Its much easier for me to heckle jamielennox when your one is done. | 22:46 |
| morganfainberg | Lol | 22:47 |
| *** telemonster has quit IRC | 22:47 | |
| morganfainberg | Will do what I can tonight | 22:48 |
| *** telemonster has joined #openstack-keystone | 22:48 | |
| morganfainberg | So you can heckle jamielennox more | 22:48 |
| Lactem | So is this a job for all of you? | 22:49 |
| lifeless | thank you! | 22:49 |
| Lactem | Or hobby? | 22:49 |
| morganfainberg | Lactem: my full time job is OpenStack | 22:49 |
| *** nkinder has quit IRC | 22:49 | |
| Lactem | Cool. | 22:49 |
| Lactem | I'm an intern. This is my first week. | 22:50 |
| morganfainberg | Most of us who are constantly active here are employed to work on OpenStack or open source | 22:50 |
| Lactem | I figured. | 22:50 |
| morganfainberg | :) | 22:50 |
| *** jdennis has quit IRC | 22:51 | |
| morganfainberg | Happy to have you join us:) | 22:51 |
| Lactem | Haha thanks. I'm happy to join, although it's not a paid internship, so I'm not really "employed." | 22:51 |
| *** boris-42 has quit IRC | 22:52 | |
| *** jdennis has joined #openstack-keystone | 22:53 | |
| *** browne has quit IRC | 22:55 | |
| *** openstackgerrit has quit IRC | 22:55 | |
| *** markvoelker_ has quit IRC | 22:55 | |
| *** ericksonsantos has quit IRC | 22:55 | |
| *** tellesnobrega has quit IRC | 22:55 | |
| *** ngupta has quit IRC | 22:55 | |
| *** EmilienM has quit IRC | 22:55 | |
| *** nkinder has joined #openstack-keystone | 22:57 | |
| *** dims_ has joined #openstack-keystone | 23:01 | |
| *** dims has quit IRC | 23:04 | |
| *** crinkle has joined #openstack-keystone | 23:06 | |
| *** openstackgerrit has joined #openstack-keystone | 23:06 | |
| *** markvoelker_ has joined #openstack-keystone | 23:06 | |
| *** ericksonsantos has joined #openstack-keystone | 23:06 | |
| *** tellesnobrega has joined #openstack-keystone | 23:06 | |
| *** ngupta has joined #openstack-keystone | 23:06 | |
| *** EmilienM has joined #openstack-keystone | 23:06 | |
| *** diazjf has quit IRC | 23:07 | |
| *** marzif has joined #openstack-keystone | 23:10 | |
| *** __TheDodd__ has quit IRC | 23:12 | |
| *** arunkant_ has quit IRC | 23:16 | |
| morganfainberg | where is stevemar when you need him :P | 23:23 |
| *** markvoelker_ has quit IRC | 23:26 | |
| *** boris-42 has joined #openstack-keystone | 23:28 | |
| dstanek | morganfainberg: how often does that happen :-P | 23:28 |
| morganfainberg | dstanek: what? | 23:28 |
| morganfainberg | steve being offline? | 23:28 |
| * morganfainberg doesn't know | 23:29 | |
| dstanek | no....needing him :-) | 23:29 |
| *** kfox1111_afk is now known as kfox1111 | 23:30 | |
| morganfainberg | hah | 23:31 |
| dstanek | morganfainberg: where are you this week? | 23:34 |
| morganfainberg | In Pasadena | 23:35 |
| morganfainberg | So home | 23:35 |
| *** RichardRaseley has quit IRC | 23:37 | |
| dstanek | oh, nice | 23:38 |
| *** chlong has joined #openstack-keystone | 23:47 | |
| *** RichardRaseley has joined #openstack-keystone | 23:48 | |
| *** RichardRaseley has quit IRC | 23:48 | |
| *** dims_ has quit IRC | 23:53 | |
| *** RichardRaseley has joined #openstack-keystone | 23:54 | |
| Lactem | dolphm: I finally did it. I'm pasting the log now. | 23:55 |
| Lactem | http://pastebin.com/D16WXLEV @dolphm | 23:56 |
| dolphm | Lactem: awesome! looking | 23:56 |
| dolphm | Lactem: welcome, btw! | 23:56 |
| dolphm | Lactem: who's your internship with? | 23:56 |
| Lactem | Thanks. | 23:56 |
| Lactem | Intel | 23:56 |
| Lactem | It's my first week. | 23:56 |
| Lactem | I'm actually about to go since it's almost 5. | 23:56 |
| *** RichardRaseley has quit IRC | 23:57 | |
| lbragstad | Lactem: congrats on the internship :) | 23:57 |
| dolphm | Lactem: eek, your "good" endpoint (860843c8c6984cec8f5ae1bd2d4808ef) isn't returned by keystone catalog either | 23:57 |
| dolphm | Lactem: let's pick this up tomorrow? ping me whenever you have time | 23:57 |
| Lactem | Alright. | 23:57 |
| Lactem | Thanks see you tomorrow. | 23:57 |
| *** Lactem has quit IRC | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!