| *** felipemonteiro has quit IRC | 00:07 | |
| *** masber has joined #openstack-keystone | 00:10 | |
| *** masuberu has quit IRC | 00:13 | |
| *** masuberu has joined #openstack-keystone | 00:26 | |
| *** masber has quit IRC | 00:29 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 00:33 | |
| *** gyee has quit IRC | 00:34 | |
| *** felipemonteiro has joined #openstack-keystone | 01:17 | |
| *** felipemonteiro has quit IRC | 01:30 | |
| openstackgerrit | Harry Rybacki proposed openstack/keystone master: Ensure default roles created during bootstrap https://review.openstack.org/572243 | 01:51 |
|---|---|---|
| *** liuzz_ has quit IRC | 01:53 | |
| *** liuzz has joined #openstack-keystone | 01:54 | |
| *** itlinux has joined #openstack-keystone | 02:24 | |
| *** annp has joined #openstack-keystone | 02:40 | |
| kmalloc | hm | 02:42 |
| kmalloc | lbragstad: this is being too clever, right? --> app.after_request(lambda r: [r.headers.__setitem__('Vary', 'X-Auth-Token')][1]) | 02:42 |
| *** dtruong has quit IRC | 02:45 | |
| * kmalloc makes it not a lambda. | 02:46 | |
| *** dtruong has joined #openstack-keystone | 02:47 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Convert json_home and version discovery to Flask https://review.openstack.org/574736 | 02:47 |
| openstackgerrit | ayoung proposed openstack/keystone master: Ensure default roles created during bootstrap https://review.openstack.org/572243 | 02:52 |
| *** dave-mccowan has quit IRC | 02:57 | |
| *** sheel has joined #openstack-keystone | 03:03 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Update flask common scafolding for json_home https://review.openstack.org/574953 | 03:09 |
| *** hoonetorg has joined #openstack-keystone | 03:28 | |
| *** boris_42_ has quit IRC | 03:29 | |
| *** germs has quit IRC | 04:00 | |
| *** germs has joined #openstack-keystone | 04:00 | |
| *** germs has quit IRC | 04:00 | |
| *** germs has joined #openstack-keystone | 04:00 | |
| *** germs has quit IRC | 04:04 | |
| *** links has joined #openstack-keystone | 04:24 | |
| *** ykarel|away has joined #openstack-keystone | 04:43 | |
| *** pcaruana has joined #openstack-keystone | 04:50 | |
| *** Kumar has joined #openstack-keystone | 04:54 | |
| *** Dinesh__Bhor has joined #openstack-keystone | 04:59 | |
| *** Dinesh_Bhor has quit IRC | 04:59 | |
| *** felipemonteiro has joined #openstack-keystone | 05:03 | |
| *** pcaruana has quit IRC | 05:18 | |
| *** ykarel|away is now known as ykarel | 05:20 | |
| *** Kumar has quit IRC | 05:34 | |
| *** Kumar has joined #openstack-keystone | 05:35 | |
| *** Kumar has quit IRC | 05:38 | |
| *** felipemonteiro has quit IRC | 05:43 | |
| *** liuzz_ has joined #openstack-keystone | 05:45 | |
| *** liuzz has quit IRC | 05:48 | |
| *** Kumar has joined #openstack-keystone | 05:51 | |
| *** pcaruana has joined #openstack-keystone | 06:06 | |
| *** lifeless has quit IRC | 06:26 | |
| *** lifeless has joined #openstack-keystone | 06:26 | |
| *** liuzz has joined #openstack-keystone | 06:30 | |
| *** liuzz_ has quit IRC | 06:30 | |
| *** masber has joined #openstack-keystone | 06:35 | |
| *** Kumar_ has joined #openstack-keystone | 06:38 | |
| *** masuberu has quit IRC | 06:38 | |
| *** martinus__ has joined #openstack-keystone | 06:39 | |
| *** Kumar has quit IRC | 06:39 | |
| *** masuberu has joined #openstack-keystone | 06:41 | |
| *** masber has quit IRC | 06:45 | |
| *** lifeless_ has joined #openstack-keystone | 06:48 | |
| *** lifeless has quit IRC | 06:48 | |
| *** masuberu has quit IRC | 06:54 | |
| *** masuberu has joined #openstack-keystone | 06:54 | |
| *** AlexeyAbashkin has joined #openstack-keystone | 06:54 | |
| *** masuberu has quit IRC | 06:55 | |
| *** masuberu has joined #openstack-keystone | 06:55 | |
| *** masuberu has quit IRC | 06:57 | |
| *** masuberu has joined #openstack-keystone | 06:57 | |
| *** masuberu has quit IRC | 06:58 | |
| *** masuberu has joined #openstack-keystone | 06:59 | |
| *** rcernin has quit IRC | 07:00 | |
| *** masuberu has quit IRC | 07:00 | |
| *** masuberu has joined #openstack-keystone | 07:00 | |
| *** masuberu has quit IRC | 07:01 | |
| *** masuberu has joined #openstack-keystone | 07:01 | |
| *** masuberu has quit IRC | 07:02 | |
| *** masuberu has joined #openstack-keystone | 07:03 | |
| *** tesseract has joined #openstack-keystone | 07:07 | |
| *** Kumar_ has quit IRC | 07:12 | |
| *** threestrands has quit IRC | 07:21 | |
| *** lifeless has joined #openstack-keystone | 07:52 | |
| *** lifeless_ has quit IRC | 07:52 | |
| *** srihas has left #openstack-keystone | 08:02 | |
| openstackgerrit | wangxiyuan proposed openstack/keystone master: Delete project limits when deleting project https://review.openstack.org/538371 | 08:05 |
| openstackgerrit | wangxiyuan proposed openstack/keystone master: Remove project_id foreign key for limit https://review.openstack.org/575016 | 08:05 |
| *** dineshbhor__ has joined #openstack-keystone | 08:05 | |
| *** Dinesh__Bhor has quit IRC | 08:06 | |
| *** s10 has joined #openstack-keystone | 08:22 | |
| *** s10 has quit IRC | 08:26 | |
| *** s10 has joined #openstack-keystone | 08:27 | |
| s10 | Hello. I have a question about the bug in keystoneauth, described in http://lists.openstack.org/pipermail/openstack-dev/2018-May/130415.html Hello. I have a question about the bug in keystoneauth, described in http://lists.openstack.org/pipermail/openstack-dev/2018-May/130415.html Hello. I have a question about the bug in the keystoneauth, described in http://lists.openstack.org/pipermail/openstack-dev/2018-May/130415.html | 08:29 |
| s10 | Will this problem be fixed in Rocky release of the keystoneauth library? | 08:29 |
| s10 | We currently have to revert commit https://github.com/openstack/keystoneauth/commit/8b8ff830e89923ca6862362a5d16e496a0c0093c in our openstack deployments, because it breaks a lot of things. | 08:30 |
| *** AlexeyAbashkin has quit IRC | 08:31 | |
| *** ykarel is now known as ykarel|lunch | 08:31 | |
| *** AlexeyAbashkin has joined #openstack-keystone | 08:40 | |
| cmurphy | mordred: are you working on that fix ^ ? | 08:45 |
| cmurphy | s10: I don't see any indication that that has been fixed yet or any patches in flight but I'm sure we can fix it in rocky | 08:47 |
| cmurphy | s10: if you haven't already, could you file a bug for it in https://bugs.launchpad.net/keystoneauth so we can track it? | 08:47 |
| s10 | There is filed bug, that is caused by this issue https://bugs.launchpad.net/keystoneauth/+bug/1733052 | 08:51 |
| openstack | Launchpad bug 1733052 in keystoneauth "Usage of internal URL in clouds.yaml causes a 404" [Undecided,Confirmed] | 08:51 |
| *** nicolasbock has joined #openstack-keystone | 08:57 | |
| *** m3m0 has joined #openstack-keystone | 09:05 | |
| m3m0 | Hello, is there any way to query all the users for a given project? | 09:06 |
| *** links has quit IRC | 09:08 | |
| *** nicolasbock has quit IRC | 09:12 | |
| cmurphy | m3m0: you can use `openstack role assignment list --project <project id>` | 09:13 |
| m3m0 | cmurphy: thank you, I was using this but the users and domain (coming from ldap) appear as empty | 09:14 |
| m3m0 | http://paste.openstack.org/show/723372/ | 09:15 |
| m3m0 | same goes for `openstack user list --project <project_id>` | 09:15 |
| cmurphy | m3m0: did you make a role assignment for each ldap user with `openstack role add --user <userid> --project <projectid> <roleid>` ? if you're expecting there to be a default project that might be a little wonky | 09:21 |
| s10 | Should I fill another more specified bug, or this one would be enough? | 09:22 |
| cmurphy | s10: that one is great, just need mordred to see it when he wakes up | 09:22 |
| s10 | Ok, thank you. | 09:23 |
| *** links has joined #openstack-keystone | 09:25 | |
| *** ykarel|lunch is now known as ykarel | 09:26 | |
| m3m0 | cmurphy: yes I did, it seems to be an issue with my ldap conf, I'll debug that | 09:29 |
| m3m0 | thanks a lot | 09:29 |
| *** lifeless_ has joined #openstack-keystone | 09:34 | |
| *** lifeless has quit IRC | 09:34 | |
| *** lifeless has joined #openstack-keystone | 09:44 | |
| *** lifeless_ has quit IRC | 09:46 | |
| *** dineshbhor__ has quit IRC | 09:57 | |
| *** m3m0 has quit IRC | 10:03 | |
| *** AlexeyAbashkin has quit IRC | 10:06 | |
| *** AlexeyAbashkin has joined #openstack-keystone | 10:06 | |
| *** masuberu has quit IRC | 10:10 | |
| *** AlexeyAbashkin has quit IRC | 10:11 | |
| *** links has quit IRC | 10:12 | |
| *** d0ugal has quit IRC | 10:17 | |
| *** lifeless has quit IRC | 10:23 | |
| *** lifeless has joined #openstack-keystone | 10:24 | |
| *** links has joined #openstack-keystone | 10:25 | |
| *** lifeless_ has joined #openstack-keystone | 10:32 | |
| *** lifeless has quit IRC | 10:32 | |
| *** d0ugal has joined #openstack-keystone | 10:36 | |
| *** nicolasbock has joined #openstack-keystone | 10:46 | |
| jaosorior | cmurphy: hey, could you check this out if you have some time? https://review.openstack.org/#/c/572243 | 10:51 |
| *** AlexeyAbashkin has joined #openstack-keystone | 11:05 | |
| cmurphy | jaosorior: commented | 11:06 |
| jaosorior | thanks | 11:07 |
| *** liuzz has quit IRC | 11:41 | |
| *** lifeless_ has quit IRC | 11:42 | |
| *** lifeless has joined #openstack-keystone | 11:42 | |
| *** annp has quit IRC | 11:45 | |
| *** edmondsw has joined #openstack-keystone | 12:07 | |
| *** Alexey_Abashkin has joined #openstack-keystone | 12:24 | |
| *** AlexeyAbashkin has quit IRC | 12:26 | |
| *** AlexeyAbashkin has joined #openstack-keystone | 12:27 | |
| *** Alexey_Abashkin has quit IRC | 12:29 | |
| *** larsks has joined #openstack-keystone | 12:31 | |
| *** larsks has left #openstack-keystone | 12:31 | |
| *** aojea_ has joined #openstack-keystone | 12:36 | |
| *** hoonetorg has quit IRC | 12:37 | |
| *** dave-mccowan has joined #openstack-keystone | 12:42 | |
| hrybacki | cmurphy: hmm so I do believe that the role implication will be created even if an existing 'reader' or 'member' role is in place | 12:44 |
| hrybacki | we talked about how no new role will be created in the spec but didn't htink about role implications | 12:44 |
| *** hoonetorg has joined #openstack-keystone | 12:47 | |
| jaosorior | hrybacki, cmurphy: perhaps the best way to address this is to enable a flag to the bootstrap command that will skip the creation of these roles if enabled. And the only thing we can actually do is document it. | 12:48 |
| hrybacki | based on what kmalloc was saying yesterday, we don't want to make the bootstrap process configureable | 12:50 |
| hrybacki | this bit might need some more discussion | 12:50 |
| cmurphy | yeah i'm not sure what the answer is here | 12:50 |
| mordred | cmurphy: what did I do? | 12:50 |
| cmurphy | mordred: broke the world | 12:51 |
| cmurphy | https://bugs.launchpad.net/keystoneauth/+bug/1733052 | 12:51 |
| openstack | Launchpad bug 1733052 in keystoneauth "Usage of internal URL in clouds.yaml causes a 404" [Undecided,Confirmed] | 12:51 |
| cmurphy | maybe just a very small number of clouds in the world | 12:52 |
| mordred | cmurphy: oh! yeah - that | 12:52 |
| *** AlexeyAbashkin has quit IRC | 12:54 | |
| jaosorior | hrybacki: right... but we also don't want to block keystone from having sane bootstrap values. Either we make it configurable, or we document the implications of this change thoroughly | 12:54 |
| jaosorior | (it should be documented thoroughly anyway) | 12:55 |
| *** bhagyashri_s is now known as bhagyashris | 12:56 | |
| hrybacki | agreed | 12:58 |
| hrybacki | I'm just not sure what behavior we want (forcing implications or not) | 12:58 |
| *** AlexeyAbashkin has joined #openstack-keystone | 13:04 | |
| lbragstad | jaosorior: hrybacki we can technically get the same behavior and sane values without doing any of the role implication stuff | 13:18 |
| lbragstad | it's how we originally wrote the specification | 13:19 |
| kmalloc | thats fine, i just don;'t want wildly different results (role name changes) etc | 13:19 |
| kmalloc | bootstrap is not meant to be "make my cloud how i want it" it is meant to be "build me a basic set of things for interfacing with the api, that most people would want" | 13:20 |
| jaosorior | lbragstad: we sure can, that just means longer policies. Would have sure been nice to have the implications | 13:20 |
| lbragstad | right | 13:20 |
| lbragstad | that was the trade off | 13:20 |
| jaosorior | what about writing up a mail in the operators list? | 13:21 |
| jaosorior | get some feedback there about what folks are doing | 13:21 |
| *** dave-mccowan has quit IRC | 13:21 | |
| lbragstad | ++ | 13:21 |
| kmalloc | an alternative is we accept a yaml file that defines the whole cloud setup [operator uses it, it is on them] otherwise we do the basic stuff with implications. | 13:22 |
| kmalloc | i worry that making bootstrap smart will cause us to do it badly though. | 13:22 |
| jaosorior | kmalloc: I didn't understand that, could you rephrase? | 13:22 |
| lbragstad | what's in the yaml file? | 13:22 |
| lbragstad | policies? | 13:22 |
| *** felipemonteiro has joined #openstack-keystone | 13:22 | |
| kmalloc | lbragstad: domains, projects, roles, users, assigned roles, etc | 13:22 |
| kmalloc | jaosorior: we *could* allow someone to provide a template for building up their cloud during bootstrap | 13:23 |
| *** felipemonteiro has quit IRC | 13:23 | |
| lbragstad | would that just be a yaml version of the command line arguments? | 13:23 |
| kmalloc | jaosorior: so keystone-manage bootstrap --template mycloud.yaml | 13:24 |
| kmalloc | lbragstad: ^ | 13:24 |
| kmalloc | lbragstad: no, much more involved. | 13:24 |
| kmalloc | lbragstad: i am of the opinion this is a bad idea | 13:24 |
| jaosorior | still unsure what mycloud.yaml contains; if it contains user and role assignments to users, I'm not too keen on that. | 13:24 |
| kmalloc | i'm not a fan. i also am not really a fan of bootstrap creating something remarkably different based on flags | 13:25 |
| kmalloc | jaosorior: it would be a template for bootstraping the cloud to the form an operator would want instead of the very basic setup we have now which may not match policies. | 13:25 |
| kmalloc | lbragstad: that said i wont hold up much of anything on this front because i don't like it. | 13:26 |
| lbragstad | does that address the implied roles bit? | 13:26 |
| kmalloc | it would, as you'd define a set of implied roles or not implied roles in the yaml. | 13:26 |
| cmurphy | kmalloc: yeah i don't like that, i was never trying to imply that bootstrap should be bringing up a fully configured keystone, it's just that it's supposed to be idempotent and if it has this behavior change when it's run after it's already deployed that's not great | 13:26 |
| kmalloc | wait... hold on | 13:27 |
| kmalloc | if someone has already deployed a cloud and re-runs bootstrap with an upgraded bootstrap | 13:27 |
| jaosorior | I would much rather just ask around what folks are doing, bring up what we intend to do, and if it's not too much inpact, then lets just provide the default roles with implications | 13:28 |
| kmalloc | no, we don't special case that | 13:28 |
| kmalloc | that is dumb | 13:28 |
| kmalloc | maybe we make bootstrap say "uh, looks like you ran bootstrap with a previous verison, are you REALLY SURE YOU WANT THIS?!" | 13:28 |
| cmurphy | what if we just say if role reader already exists and role member already exists then don't create an implication rule between them | 13:28 |
| jaosorior | kmalloc: I like that option better. a Warning and a confirmation | 13:29 |
| kmalloc | cmurphy: i think we're solving a people problem with tech here | 13:29 |
| hrybacki | cmurphy so the first part of that already happens | 13:29 |
| cmurphy | kmalloc: no i don't think so | 13:29 |
| cmurphy | it's an automation problem | 13:29 |
| kmalloc | if you are re-running bootstrap on an openstack that you already deployed you're doing it wrong | 13:29 |
| lbragstad | it's a common thing though | 13:29 |
| lbragstad | some deployment projects do that | 13:29 |
| kmalloc | the only case this is an issue: deployed openstack, upgraded, re-run bootstrap | 13:30 |
| kmalloc | this is bad behavior | 13:30 |
| cmurphy | if a config management tool runs bootstrap the only way to note "DON'T RUN THIS AGAIN" is to write it down somewhere | 13:30 |
| cmurphy | which is weird and awkward | 13:30 |
| cmurphy | and it would be better to just make it safe to run again | 13:30 |
| lbragstad | which is what we've been doing for a while, we've fixed bugs to make it idempotent | 13:31 |
| hrybacki | we'll have to re-work the patch but I think that's doable. I'd like to keep the role implications if possible | 13:31 |
| kmalloc | idempotent is fine, idempotent across versions of keystone is absurd | 13:31 |
| cmurphy | i disagree | 13:31 |
| kmalloc | so, here is my solution: encode bootstrap was run with version X in the db | 13:31 |
| *** hrybacki is now known as hrybacki|mtg | 13:31 | |
| kmalloc | if you're running it with a new version, it needs explicit confirmation or it is noop | 13:31 |
| cmurphy | okay i'm fine with that | 13:32 |
| kmalloc | bootstrap was never meant to be used on every single upgrade. | 13:32 |
| cmurphy | that would actually be great for cfg mgmt tools regardless of this | 13:32 |
| cmurphy | esp puppet | 13:32 |
| kmalloc | s/new version/new OR old version/ | 13:32 |
| kmalloc | cmurphy: i'm happy to make it easier to not run bootstrap in silly ways ;) | 13:33 |
| *** AlexeyAbashkin has quit IRC | 13:33 | |
| kmalloc | i'm standing by my statement that it wasn't really intended to be run from different versions of openstack on production/running clouds | 13:34 |
| lbragstad | what about recovering the administrator account? | 13:34 |
| kmalloc | it was intended to be idempoent in the case that there was some initial automation that justified re-running things. | 13:34 |
| kmalloc | lbragstad: i would make that an explicit keystone-manage command | 13:34 |
| kmalloc | or a doctor command? | 13:34 |
| kmalloc | bootstrap is and always was intended to avoid "start keystone, initialize db, stop keystone--change paste.ini or config--, start keystone" | 13:35 |
| kmalloc | getting the db in a usable state of basic user/project/role for further automation work. | 13:35 |
| kmalloc | or non-automated work. | 13:35 |
| kmalloc | i would never, ever, ever, recommend using bootstrap outside of a "initializing keystone for a given deployment" including run it on every upgrade, or similar cases. | 13:37 |
| kmalloc | if we need more manage/doctor/operator commands for administrative things, we should add them not wedge it into bootstrap | 13:37 |
| kmalloc | cmurphy: i'd be happy to review any code that makes bootstrap work like that and avoid re-running on new versions without confirmation. | 13:38 |
| kmalloc | jaosorior: ^ what i said to cmurphy | 13:38 |
| kmalloc | and i 100% support adding that functionality to bootstrap :) | 13:38 |
| jaosorior | kmalloc: I'll read it in a bit (in a meeting right now) | 13:39 |
| kmalloc | jaosorior: np :) | 13:39 |
| cmurphy | i'm still a little unhappy, until now it's been totally safe to rerun bootstrap, either by accident or for recovery, so people are going to have build tooling making those assumptions | 13:40 |
| cmurphy | built* | 13:40 |
| cmurphy | and in fact one of our products does seem to run it unconditionally though the other one doesn't | 13:44 |
| *** felipemonteiro has joined #openstack-keystone | 13:45 | |
| jaosorior | cmurphy: tripleo runs it unconditionally, but I can easily fix that issue | 13:45 |
| jaosorior | for puppet-keystone, it all depends on whether or not you enable bootstrap to run via a flag | 13:45 |
| *** zxy has quit IRC | 13:45 | |
| cmurphy | jaosorior: sure, you can fix tripleo and i can fix suse's thing but the point is it's out in the wild and other people are relying on it | 13:46 |
| *** zxy has joined #openstack-keystone | 13:46 | |
| *** aojea_ has quit IRC | 13:48 | |
| *** sheel has quit IRC | 13:50 | |
| *** aojea_ has joined #openstack-keystone | 13:52 | |
| *** aojea_ has quit IRC | 13:52 | |
| *** aojea_ has joined #openstack-keystone | 13:52 | |
| kmalloc | cmurphy: if i had known that was the plan, i would have advocated to make bootstrap never runable again | 13:54 |
| kmalloc | cmurphy: the idempotent run was strictly a design choice for making it easy for a standup of a cloud for initialization only. | 13:55 |
| kmalloc | we are changing the behavior, it is not purely idempotent | 13:56 |
| kmalloc | it is idempoent in a given release (and even a number of historical releases) | 13:56 |
| kmalloc | if we can never make our bootstrapping tools better because "someone might be using them" we're in a broken state. | 13:57 |
| kmalloc | i am very very very much against making bootstrap super smart unless we go the whole way and just say "fine, provide a template" and we define a couple templates with/without the implications but default to implications. | 13:58 |
| kmalloc | so. if we make bootstrap know it has been run [or the cloud is in production] and require confirmation to re-run, with changed behavior (version-dependant, idempotent within a given version) | 13:59 |
| kmalloc | it seems to make it "safe" again. | 13:59 |
| *** dave-mccowan has joined #openstack-keystone | 13:59 | |
| kmalloc | also - if people are really using it for recovery, we should figure out if it makes sense to offer another command specifically tailored for that | 14:00 |
| *** jmlowe has quit IRC | 14:02 | |
| cmurphy | i am not saying it has to be super smart and i'm not saying we have to treat it as a stable api and never change it | 14:03 |
| kmalloc | i think we miscommunicated what it was for and that is a problem. | 14:03 |
| kmalloc | and we should rectify it in two ways: 1) if we change it make it safe -- so at least people aren't getting something "new" added that they were not expecting | 14:04 |
| cmurphy | i think it is great at what it is, a create-if-not-exists utility, i don't think it needs to be smarter than that | 14:05 |
| kmalloc | 2) add additional support for the things folks were using it for that doesn't meet with the defined purpose of the tool. | 14:05 |
| cmurphy | i added a comment to the review that i just think we should document the new behavior better | 14:05 |
| kmalloc | thats fine. | 14:05 |
| kmalloc | and i don't disagree | 14:05 |
| kmalloc | s/don't disagree/totally agree | 14:05 |
| cmurphy | okay cool | 14:05 |
| kmalloc | i also think we should make sure we're clear on what it's intended to do and i don't want a ton more options "--create-implication" "--dont-create-implications" "--dumb-default-roles", "--super-smart-cool-new-hotness-default-roles" | 14:06 |
| kmalloc | :) | 14:06 |
| cmurphy | fine with me | 14:06 |
| kmalloc | ++ | 14:07 |
| cmurphy | i am 100% on board with keeping it as dumb as possible | 14:07 |
| kmalloc | i do really think we should make it possible to know if bootstrap has been run | 14:07 |
| kmalloc | maybe invert the option(s) like mysql im-a-dummy (prevents delete without a where clause) | 14:08 |
| kmalloc | so bootstrap --only-run-once and it never runs if it's been run before | 14:08 |
| cmurphy | tools like puppet could really benefit from a keystone-manage do-i-need-to-run-bootstrap command | 14:08 |
| kmalloc | ++ | 14:08 |
| cmurphy | because they then report on whether they did the action | 14:08 |
| kmalloc | and i like knowing what version of keystone or more specifically of bootstrap we ran | 14:09 |
| kmalloc | though i'd like to figure out a way of being clever to ensure it requires a version change if new feature is added/functionality is changed. | 14:09 |
| kmalloc | cmurphy: would you like me to take on adding the migration and bootstrap changes for knowing that? | 14:11 |
| kmalloc | [if we have a bug/bp/spec i can target it to, i'll hack that code up quickly, stalled on the flask stuff because @protected and mulling over how to approach] | 14:11 |
| *** spilla has joined #openstack-keystone | 14:12 | |
| cmurphy | kmalloc: well i worry about the "being clever" part | 14:13 |
| lbragstad | fwiw - i'd be inclined to expose a "do i need to run bootstrap" command versus "run bootstrap but fail if it's already been done" permutation | 14:13 |
| * lbragstad leaves his $0.02 on the counter | 14:13 | |
| cmurphy | lbragstad: ++ | 14:13 |
| cmurphy | that is exactly what i'd want | 14:13 |
| cmurphy | i don't really want the bootstrap command itself trying to be smart | 14:13 |
| kmalloc | cmurphy: clever in the code "if we change bootstrap make sure we can detect it automatically and we increase the version" | 14:14 |
| kmalloc | not anything more than for testing | 14:14 |
| kmalloc | so we can catch and say "uh, changed bootstrap version didn't change" | 14:14 |
| lbragstad | cc cloudnull ^ | 14:15 |
| *** aojea_ has quit IRC | 14:15 | |
| kmalloc | lbragstad, cmurphy: and do you want it to be a separate command or do you want "i-am-a-dummy" flag (opt in) | 14:16 |
| kmalloc | (i do like mysql's form of that, it is a nice opt-in protection) | 14:16 |
| cmurphy | kmalloc: either works, i was thinking separate command but actually a --noop might be nice | 14:17 |
| lbragstad | ++ | 14:17 |
| kmalloc | lbragstad: in this weeks "why did i ever start programming": func = lambda r: [r.__setitem__('new_dict_key', 'new_dict_value'), r][1] | 14:18 |
| kmalloc | lbragstad: how many ways can i write bad python code ;) | 14:18 |
| * cmurphy takes the computer away from kmalloc | 14:18 | |
| * lbragstad gets the bottle of vinegar/water out | 14:18 | |
| kmalloc | cmurphy: ^_^ not that i ran into a case where that would work last night or anything... | 14:18 |
| cmurphy | :P | 14:19 |
| kmalloc | because i needed to work around a decorator without using it as a decorator and needed to pass a func that changed a dict but returned the surrounding object | 14:19 |
| kmalloc | (wsgi response object) | 14:19 |
| lbragstad | ok - so does this mean we are ok with the implications/ | 14:19 |
| lbragstad | role implications* | 14:19 |
| kmalloc | lbragstad: we add them to bootstrap, document heavily the changed functionality | 14:19 |
| cmurphy | i'm okay with it | 14:20 |
| cmurphy | just needs to be highlighted better in the release note | 14:20 |
| kmalloc | and give bootstrap a "hey don't run me more than once" mechanism | 14:20 |
| lbragstad | and document the usage of the --noop and why it makes that whole situation better for people who've rolled their own stuff | 14:20 |
| kmalloc | also...because cmurphy said she's good with it :) | 14:20 |
| kmalloc | lbragstad: ++ | 14:20 |
| lbragstad | ok - cool | 14:20 |
| kmalloc | lbragstad: though i'm probably not calling it --noop :P | 14:20 |
| lbragstad | cc hrybacki|mtg jaosorior ^ | 14:20 |
| hrybacki|mtg | we are reviewing barbican APIs atm, I'll read up and review after we finish this | 14:21 |
| kmalloc | sure. | 14:22 |
| cmurphy | to be clear the --noop part doesn't need to block hrybacki|mtg 's patch imo | 14:22 |
| cmurphy | just a nice-to-have | 14:22 |
| lbragstad | true | 14:22 |
| *** felipemonteiro has quit IRC | 14:27 | |
| kmalloc | correct | 14:30 |
| kmalloc | the --noop part will be in addition to anything else and can be done in paralle | 14:30 |
| kmalloc | l | 14:30 |
| *** itlinux has quit IRC | 14:34 | |
| *** hoonetorg has quit IRC | 14:35 | |
| *** larsks has joined #openstack-keystone | 14:51 | |
| larsks | Hey folks. What is the purpose of the public_endpoint and admin_endpoint settings in keystone.conf? | 14:54 |
| kmalloc | larsks: well, 2 things | 14:55 |
| kmalloc | historically for long ago functionality | 14:55 |
| kmalloc | and 2: allows for override in case you'r ebehind say a loadbalancer that doesn't send x-forwarded-for etc, so you can set the endpoint that shows up in the rel links in the json responses | 14:56 |
| kmalloc | etc. | 14:56 |
| larsks | kmalloc: Thanks. For context, I'm trying to get the openidc federation support in puppet-keystone, and it seems to want to use the value of those settings to create a URL, and I am trying to figure out if I can replace that with another puppet variable. | 14:56 |
| kmalloc | admin_endpoint applied only to keystone v2.0 when you were using the admin vs public thing | 14:56 |
| kmalloc | larsks: i recommend not using those values if you can replace it with something else. | 14:57 |
| kmalloc | larsks: fwiw, in rocky admin_endpoint is not used, and public_endpoint is used only in special circumstances | 14:57 |
| kmalloc | so, substituting for something else if possible (var wise) is good | 14:57 |
| kmalloc | unless you need those set for your deployment, then keeping them tied together is a nice thing to do. | 14:57 |
| kmalloc | most dpeloyments don't need them set. | 14:57 |
| larsks | Got it. The trick I'm running into is finding someone who is familiar with both keystone *and* the puppet-keystone module :). You've given me some ideas, though. | 14:58 |
| lbragstad | cmurphy: at some point - we should revisit what we want to do about patches like this - https://review.openstack.org/#/c/575016/1 | 15:04 |
| *** hrybacki|mtg is now known as hrybacki | 15:04 | |
| * hrybacki is more confused now than he was before after reading up | 15:04 | |
| *** r-daneel has quit IRC | 15:05 | |
| lbragstad | the TL;DR as i understood it | 15:05 |
| lbragstad | - we can make the role implication happen in bootstrap, but we need to telegraph it in the upgrade section of a release note (to make operators aware if they have their own custom policies that rely on those role names) | 15:06 |
| cmurphy | hrybacki: the tldr is i left a -1 with actionable feedback on the review | 15:06 |
| hrybacki | ack. I'll also update the patch for the section covering this to note as much | 15:07 |
| hrybacki | the spec* | 15:07 |
| hrybacki | thanks all | 15:07 |
| cmurphy | lbragstad: ooh you know how much i want to drop that fk ;) | 15:07 |
| lbragstad | yeah - we've had a slew of patches come up recently doing the same thing | 15:08 |
| lbragstad | but i'm not sure i remember the conclusion of the discussions we had around it? | 15:08 |
| cmurphy | there wasn't a solid conclusion | 15:09 |
| lbragstad | so i'm not in left field then | 15:10 |
| cmurphy | i think the most actionable part was we need better rolling upgrade testing so we can evaluate how things like that will play out in upgrade scenarios | 15:10 |
| cmurphy | i think that was what kmalloc was worried about | 15:11 |
| lbragstad | ah | 15:11 |
| lbragstad | i was thinking it felt weird to have a relational database at out disposal, but we can't really use any fk to our advantage | 15:12 |
| lbragstad | our* | 15:12 |
| *** jmlowe has joined #openstack-keystone | 15:12 | |
| cmurphy | we can use them, just not in a plugin-style architecture | 15:13 |
| kmalloc | cmurphy: ++ | 15:13 |
| openstackgerrit | Harry Rybacki proposed openstack/keystone-specs master: Add role implication note to basic-default-roles https://review.openstack.org/575144 | 15:14 |
| kmalloc | so, we can't leverage FKs across backends if we support loading them from different data sources | 15:14 |
| *** AlexeyAbashkin has joined #openstack-keystone | 15:18 | |
| *** efried has quit IRC | 15:20 | |
| *** itlinux has joined #openstack-keystone | 15:23 | |
| *** AlexeyAbashkin has quit IRC | 15:30 | |
| *** lifeless has quit IRC | 15:31 | |
| *** lifeless has joined #openstack-keystone | 15:31 | |
| *** ykarel is now known as ykarel|away | 15:33 | |
| kmalloc | IF we want to leaverage FKs we need to re-tie what the backends are and how they work | 15:36 |
| *** links has quit IRC | 15:36 | |
| kmalloc | FKs across different data stores (or in the case a data store is overriden and a FK is required) might break things horribly | 15:36 |
| *** AlexeyAbashkin has joined #openstack-keystone | 15:42 | |
| *** r-daneel has joined #openstack-keystone | 15:46 | |
| *** r-daneel_ has joined #openstack-keystone | 15:49 | |
| *** s10 has quit IRC | 15:50 | |
| *** r-daneel has quit IRC | 15:51 | |
| *** r-daneel_ is now known as r-daneel | 15:51 | |
| *** aojea has joined #openstack-keystone | 15:51 | |
| *** gyee has joined #openstack-keystone | 15:51 | |
| *** ykarel|away has quit IRC | 16:12 | |
| *** r-daneel_ has joined #openstack-keystone | 16:17 | |
| *** r-daneel has quit IRC | 16:18 | |
| *** r-daneel_ is now known as r-daneel | 16:18 | |
| *** ykarel|away has joined #openstack-keystone | 16:25 | |
| *** r-daneel has quit IRC | 16:31 | |
| *** r-daneel has joined #openstack-keystone | 16:31 | |
| *** tesseract has quit IRC | 16:33 | |
| *** ykarel|away has quit IRC | 16:37 | |
| hrybacki | lbragstad: ayoung do we really not have implied roles documented? https://bugs.launchpad.net/keystone/+bug/1609164 | 16:40 |
| openstack | Launchpad bug 1609164 in OpenStack Identity (keystone) "[api] Document implied roles" [Wishlist,Fix released] - Assigned to Tin Lam (lamt) | 16:40 |
| ayoung | hrybacki, I thought I wrote something for them way back when | 16:40 |
| hrybacki | ayoung: lost patch perhaps? | 16:40 |
| lbragstad | we lack documentation for other role things, too | 16:40 |
| lbragstad | https://bugs.launchpad.net/keystone/+bug/1737863 | 16:41 |
| openstack | Launchpad bug 1737863 in OpenStack Identity (keystone) "Lack of documentation for role inheritance" [Medium,Confirmed] | 16:41 |
| hrybacki | oh boy | 16:41 |
| lbragstad | and https://bugs.launchpad.net/keystone/+bug/1775094 | 16:41 |
| openstack | Launchpad bug 1775094 in OpenStack Identity (keystone) "Lack of documentation for role permutations and possibilities" [Medium,Triaged] | 16:41 |
| ayoung | it was part of the original patch...was a requirement I thought | 16:41 |
| lbragstad | documentation has also shuffled various places since then... so maybe it accidentally got lost somewhere? | 16:42 |
| ayoung | commit 3b86db443cc7f4b360e434a6a804df20d1756425 | 16:42 |
| ayoung | Author: Tin Lam <tinlam@gmail.com> | 16:42 |
| ayoung | Date: Sat Aug 13 20:41:07 2016 -0500 | 16:42 |
| ayoung | api-ref: Document implied roles API | 16:42 |
| ayoung | 16:42 | |
| ayoung | Add documentation for implied roles. | 16:42 |
| hrybacki | I'm really bad at reading -- fix released | 16:42 |
| ayoung | api-ref/source/v3/roles.inc | 16:43 |
| lbragstad | oh - nvm | 16:43 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/api-ref/source/v3/roles.inc#n1042 | 16:43 |
| ayoung | all good? | 16:44 |
| *** ykarel|away has joined #openstack-keystone | 16:52 | |
| hrybacki | ayoung: gerrit question for you | 16:57 |
| *** Alexey_Abashkin has joined #openstack-keystone | 16:58 | |
| *** AlexeyAbashkin has quit IRC | 16:58 | |
| *** Alexey_Abashkin is now known as AlexeyAbashkin | 16:58 | |
| hrybacki | ayoung: there was a dependency on openstack/tempest but some of those patches have merged. So I removed the 'depends-on' from my commit msg and now I'm seeing: https://paste.fedoraproject.org/paste/QS7i387kYQKxSPL4gS4O8w | 16:59 |
| hrybacki | sorry, left out some lines: https://paste.fedoraproject.org/paste/OvZPRvhYLbxIQ8qLAZYrxw | 17:02 |
| openstackgerrit | Harry Rybacki proposed openstack/keystone master: Ensure default roles created during bootstrap https://review.openstack.org/572243 | 17:05 |
| hrybacki | must be tainted local thing. Submitted it through gerrit directly \_0_/ | 17:05 |
| *** aojea has quit IRC | 17:07 | |
| *** aojea has joined #openstack-keystone | 17:07 | |
| *** AlexeyAbashkin has quit IRC | 17:10 | |
| lbragstad | hrybacki: i think you just need to rebase your work on master and resubmit | 17:21 |
| lbragstad | the change it is complaining about already merged | 17:21 |
| hrybacki | lbragstad: I thought so but that didn't work either | 17:21 |
| lbragstad | mm | 17:22 |
| lbragstad | which change is it? | 17:22 |
| lbragstad | this one? https://review.openstack.org/#/c/572243/ | 17:22 |
| hrybacki | lbragstad: https://review.openstack.org/572243 | 17:22 |
| hrybacki | aye | 17:22 |
| hrybacki | I got it through -- just had to use the GUI (yuck, I know) | 17:22 |
| hrybacki | I'll wipe my local keystone repo and re-clone if I need another patchset | 17:23 |
| lbragstad | cool | 17:23 |
| hrybacki | but that seems in order | 17:23 |
| lbragstad | fwiw - leaving the depends-on in the commit message shouldn't matter | 17:23 |
| hrybacki | kmalloc: did you take the action item for the --noop bits ? | 17:23 |
| kmalloc | yeah | 17:23 |
| hrybacki | ack thanks kmalloc | 17:23 |
| lbragstad | it just prevents someone from +A'ing the change before the dependency in the other repository merges | 17:23 |
| hrybacki | lbragstad: hmm. Why was it griping about the depends-on already having merged? | 17:23 |
| lbragstad | (and it's nice for auditing purposes) | 17:23 |
| lbragstad | it looks like your error message was griping about something else | 17:24 |
| lbragstad | https://review.openstack.org/571913 | 17:25 |
| lbragstad | not https://review.openstack.org/#/c/574149/ | 17:25 |
| lbragstad | which is the dependency listed it the commit message of https://review.openstack.org/#/c/572243/11 | 17:25 |
| hrybacki | oh god, gj fat fingers | 17:26 |
| *** AlexeyAbashkin has joined #openstack-keystone | 17:28 | |
| lbragstad | stepping away for lunch quick, but i'm going to get a couple patches up for unified limit support in osc afterwords (in case anyone's burning to test that manually) | 17:34 |
| *** AlexeyAbashkin has quit IRC | 17:36 | |
| *** ykarel|away has quit IRC | 17:37 | |
| *** aojea has quit IRC | 17:42 | |
| *** germs has joined #openstack-keystone | 17:47 | |
| *** germs has quit IRC | 17:47 | |
| *** germs has joined #openstack-keystone | 17:47 | |
| *** simondodsley_ has quit IRC | 18:03 | |
| *** simondodsley has joined #openstack-keystone | 18:03 | |
| *** simondodsley has left #openstack-keystone | 18:04 | |
| *** openstackgerrit has quit IRC | 18:04 | |
| *** openstackgerrit has joined #openstack-keystone | 18:09 | |
| openstackgerrit | Harry Rybacki proposed openstack/keystone master: Ensure default roles created during bootstrap https://review.openstack.org/572243 | 18:09 |
| hrybacki | lbragstad: re-added the missing dependency | 18:10 |
| hrybacki | should be ready for reviews | 18:10 |
| *** harlowja has joined #openstack-keystone | 18:10 | |
| *** r-daneel_ has joined #openstack-keystone | 18:11 | |
| *** r-daneel has quit IRC | 18:11 | |
| *** r-daneel_ is now known as r-daneel | 18:11 | |
| knikolla | o/ | 18:13 |
| *** dave-mccowan has quit IRC | 18:15 | |
| *** zxy has quit IRC | 18:16 | |
| *** zxy has joined #openstack-keystone | 18:16 | |
| hrybacki | lbragstad: is it possible to assign scope to an action in policy.json files? | 18:27 |
| hrybacki | That is a request from Barbican during the audit (thinking about Cu. uses) | 18:28 |
| lbragstad | there is the ability to match project ids through policy | 18:29 |
| hrybacki | s/assign scope/specify required scope type/ | 18:30 |
| hrybacki | akin to: | 18:30 |
| lbragstad | scope_types are immutable from policy.json files | 18:30 |
| hrybacki | https://github.com/openstack/keystone/blob/master/keystone/common/policies/role.py#L26 | 18:30 |
| lbragstad | it was meant to be set in code and not overridden | 18:31 |
| hrybacki | ack. I need to refresh myself on how the toggle for scope types works again | 18:31 |
| lbragstad | if keystone.conf [oslo_policy] enforce_scope = True then oslo.policy will raise an exception if a token of the wrong scope is used to access a policy of a different scope type | 18:32 |
| hrybacki | solid, thanks lbragstad | 18:33 |
| *** Exhar_ has quit IRC | 18:33 | |
| lbragstad | np | 18:33 |
| *** felipemonteiro has joined #openstack-keystone | 18:43 | |
| *** boris_42_ has joined #openstack-keystone | 18:45 | |
| ayoung | You never have to reclone | 18:48 |
| ayoung | hrybacki, the magic to git is this: | 18:48 |
| ayoung | git fetch origin | 18:48 |
| ayoung | git checkout master | 18:48 |
| ayoung | git reset --hard origin/master | 18:48 |
| ayoung | hrybacki, are we making a rule that admin implies member? | 18:50 |
| ayoung | Why so we are...very nice | 18:50 |
| ayoung | I'm sure that will annoy someone out there, but it makes me pleases as Punch | 18:50 |
| hrybacki | ayoung: yeah. we'll see how that is received. The implication will happen regardless of whether or not they want it of they re-run the bootstrap process (for now -- kmalloc is working on a noop for that) | 18:51 |
| ayoung | opt out? | 18:57 |
| ayoung | hrybacki, we already have the opt out of the implications happening in token section of the config file | 18:58 |
| hrybacki | ayoung: that would break any existing implications they had though | 18:58 |
| ayoung | so it really would only be a problem for that one person out there that is using implied roles, but does not want member to imply reader or admin to imply member. I'll be happy to rewrite that one persons rules myself | 18:58 |
| hrybacki | ayoung: noted :) | 18:59 |
| hrybacki | but the default behavior will be to create them regardless so your wishes are coming true | 18:59 |
| ayoung | steepled hands "all my plans are coming together" | 19:03 |
| *** hoonetorg has joined #openstack-keystone | 19:04 | |
| kmalloc | ayoung: the plan is "if you don't want implications created, don't run bootstrap" | 19:11 |
| kmalloc | ayoung: and if you REALLY want to not run bootstrap and are using automation there is an option to only run it once | 19:12 |
| ayoung | kmalloc, so, I finally have a reason to do RBAC later than the middleware time. I mean, at middleware works still for the use cases, but I had an interesting talk with a customer for also doing it after fetching the object from the database | 19:13 |
| ayoung | they want to be able to label an object and do RBAC matching against it | 19:14 |
| kmalloc | ah | 19:14 |
| ayoung | like, a specific object, | 19:14 |
| ayoung | mostly for stuff in swift and so one | 19:14 |
| kmalloc | hm. i think that falls into the grey area we deal with now, | 19:14 |
| kmalloc | so basically, the delay_auth_decision stuff | 19:15 |
| ayoung | I think we could actually do it now, assuming the remote system supported a way to get the object tags into the policy check | 19:15 |
| kmalloc | and let the underlying app do the thing | 19:15 |
| ayoung | wel... I think it would be more of an "And rule applied later" | 19:15 |
| kmalloc | we'd need a hook for <check_policy_with_new_thing> | 19:15 |
| ayoung | so, even if you get in, the policy check in the code might say "ah, not THIS object" | 19:15 |
| kmalloc | i think i can hook something into oslo_context for that. | 19:15 |
| ayoung | current policy would be sufficient, but way too static for most uses | 19:15 |
| kmalloc | so RBAC basic edge check, then in code you can do context.enforce() | 19:16 |
| kmalloc | or with context(): context.enforce() | 19:16 |
| ayoung | because the members of the project would want to be able to say "here is the role that needs to match this object property" | 19:16 |
| ayoung | otherwise, it would be a global rule, and that would be tough | 19:16 |
| kmalloc | right | 19:16 |
| ayoung | I did write up a simple scheme where you matched the role | 19:16 |
| ayoung | like, you had a object_access tag that got one of the roles from the end user that created it | 19:17 |
| ayoung | and, you needed to have that same role to perform other operations | 19:17 |
| ayoung | but I don't think it is sufficient | 19:17 |
| ayoung | I wrote it up here. https://etherpad.openstack.org/p/access-tags-planning | 19:18 |
| kmalloc | rigth | 19:20 |
| ayoung | kmalloc, I could see and argument for adding the domain specific roles into the token to support cases like that, or even coming up with project specific roles | 19:21 |
| ayoung | but I suspect that having a wider set of global roles would support most people's needs | 19:22 |
| kmalloc | agree with the wider set of roles | 19:29 |
| kmalloc | in keystone we have a super easy way to manage that with flask | 19:29 |
| kmalloc | the post "get item" bit | 19:30 |
| kmalloc | but in non-flask things [though i could fix oslo-service to do the same things] | 19:30 |
| kmalloc | in flask we have a .before_request and a .after_request set of functions that can modify the flow/responses | 19:31 |
| kmalloc | hmm. | 19:35 |
| kmalloc | this doesn't make sense. | 19:35 |
| * kmalloc goes diving through git blame... | 19:35 | |
| lbragstad | https://review.openstack.org/#/q/topic:bp/unified-limits+status:open+project:openstack/python-openstackclient still needs work, but i'd appreciate early feedback if folks have any | 19:37 |
| hrybacki | this is interesting. Barbican overloads their rule names: https://github.com/openstack/barbican/blob/master/barbican/common/policies/acls.py#L17-L20 | 19:39 |
| kmalloc | that... | 19:39 |
| kmalloc | wow | 19:39 |
| hrybacki | kmalloc: prepare yourself. all these services probably have super interesting ways of doing things | 19:40 |
| openstackgerrit | Lance Bragstad proposed openstack/python-keystoneclient master: Add support for registered limits https://review.openstack.org/537668 | 19:41 |
| openstackgerrit | Lance Bragstad proposed openstack/python-keystoneclient master: Add support for project-specific limits https://review.openstack.org/574391 | 19:41 |
| hrybacki | kmalloc: these could be collapsed. I'm not sure where we are setting the check strings in keystone though: https://github.com/openstack/keystone/blob/master/keystone/common/policies/auth.py | 19:42 |
| hrybacki | ah, I see. Many use defaults | 19:43 |
| kmalloc | yep | 19:43 |
| *** lifeless_ has joined #openstack-keystone | 19:49 | |
| *** lifeless has quit IRC | 19:49 | |
| hrybacki | kmalloc: I believe it's because they have pretty different rule checks for most methods | 19:52 |
| openstackgerrit | Tim Burke proposed openstack/keystonemiddleware master: Handle DiscoveryFailure errors https://review.openstack.org/575214 | 19:53 |
| *** aojea has joined #openstack-keystone | 20:01 | |
| *** dave-mccowan has joined #openstack-keystone | 20:05 | |
| *** AlexeyAbashkin has joined #openstack-keystone | 20:11 | |
| *** spilla has quit IRC | 20:15 | |
| *** AlexeyAbashkin has quit IRC | 20:16 | |
| *** spilla has joined #openstack-keystone | 20:16 | |
| *** spilla has quit IRC | 20:16 | |
| *** vegarl has quit IRC | 20:19 | |
| *** vegarl has joined #openstack-keystone | 20:20 | |
| *** blake has joined #openstack-keystone | 20:22 | |
| *** martinus__ has quit IRC | 20:30 | |
| *** s10 has joined #openstack-keystone | 20:41 | |
| *** s10 has quit IRC | 21:00 | |
| *** openstackgerrit has quit IRC | 21:04 | |
| *** openstackgerrit has joined #openstack-keystone | 21:05 | |
| openstackgerrit | Joshua Harlow proposed openstack/python-keystoneclient master: Need to pass through domain_id when domain is provided https://review.openstack.org/575234 | 21:05 |
| *** fiddletwix has joined #openstack-keystone | 21:06 | |
| *** jmlowe has quit IRC | 21:11 | |
| *** lifeless_ has quit IRC | 21:23 | |
| *** lifeless has joined #openstack-keystone | 21:24 | |
| *** nicolasbock has quit IRC | 21:27 | |
| *** edmondsw has quit IRC | 21:33 | |
| *** edmondsw has joined #openstack-keystone | 21:35 | |
| *** felipemonteiro has quit IRC | 21:36 | |
| *** felipemonteiro has joined #openstack-keystone | 21:36 | |
| *** lifeless_ has joined #openstack-keystone | 21:36 | |
| *** lifeless has quit IRC | 21:37 | |
| *** edmondsw has quit IRC | 21:40 | |
| *** dave-mccowan has quit IRC | 21:43 | |
| *** jmlowe has joined #openstack-keystone | 21:50 | |
| *** itlinux has quit IRC | 21:52 | |
| *** jmlowe has quit IRC | 22:07 | |
| *** harlowja has quit IRC | 22:11 | |
| *** harlowja has joined #openstack-keystone | 22:12 | |
| *** jmlowe has joined #openstack-keystone | 22:20 | |
| *** harlowja has quit IRC | 22:21 | |
| *** aojea has quit IRC | 22:21 | |
| *** rcernin has joined #openstack-keystone | 22:26 | |
| *** rcernin is now known as rcernin|brekkie | 22:27 | |
| *** rcernin|brekkie is now known as rcernin | 22:27 | |
| *** felipemonteiro has quit IRC | 22:44 | |
| *** threestrands has joined #openstack-keystone | 22:47 | |
| *** jmlowe has quit IRC | 23:13 | |
| *** jmlowe has joined #openstack-keystone | 23:15 | |
| *** dave-mccowan has joined #openstack-keystone | 23:22 | |
| *** blake has quit IRC | 23:22 | |
| *** blake has joined #openstack-keystone | 23:23 | |
| *** blake has quit IRC | 23:30 | |
| *** blake has joined #openstack-keystone | 23:31 | |
| *** jmlowe has quit IRC | 23:51 | |
| *** jmlowe has joined #openstack-keystone | 23:55 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!