| *** rcernin has joined #openstack-keystone | 00:22 | |
| *** mchlumsky_ has joined #openstack-keystone | 00:30 | |
| *** mchlumsky has quit IRC | 00:32 | |
| *** kukacz_ has quit IRC | 00:32 | |
| *** timburke has quit IRC | 00:32 | |
| *** kukacz has joined #openstack-keystone | 00:33 | |
| *** timburke has joined #openstack-keystone | 00:34 | |
| *** rcernin has quit IRC | 00:59 | |
| *** sapd1 has quit IRC | 00:59 | |
| *** sapd1 has joined #openstack-keystone | 00:59 | |
| *** rcernin has joined #openstack-keystone | 01:09 | |
| *** gyee has quit IRC | 01:10 | |
| *** sapd1 has quit IRC | 01:13 | |
| *** sapd1 has joined #openstack-keystone | 01:14 | |
| *** jamesmcarthur has joined #openstack-keystone | 01:34 | |
| *** lbragstad has quit IRC | 01:37 | |
| *** jamesmcarthur has quit IRC | 01:48 | |
| *** jamesmcarthur has joined #openstack-keystone | 01:49 | |
| *** jamesmcarthur has quit IRC | 02:25 | |
| *** markvoelker has joined #openstack-keystone | 02:31 | |
| *** erus has joined #openstack-keystone | 02:38 | |
| *** erus has quit IRC | 02:51 | |
| *** markvoelker has quit IRC | 03:05 | |
| *** sapd1 has quit IRC | 03:25 | |
| *** jamesmcarthur has joined #openstack-keystone | 03:25 | |
| *** sapd1 has joined #openstack-keystone | 03:26 | |
| *** jamesmcarthur has quit IRC | 03:41 | |
| *** whoami-rajat has joined #openstack-keystone | 03:54 | |
| *** jamesmcarthur has joined #openstack-keystone | 04:01 | |
| *** markvoelker has joined #openstack-keystone | 04:02 | |
| *** sapd1 has quit IRC | 04:07 | |
| *** sapd1 has joined #openstack-keystone | 04:08 | |
| *** jamesmcarthur has quit IRC | 04:19 | |
| *** sapd1 has quit IRC | 04:28 | |
| *** sapd1 has joined #openstack-keystone | 04:29 | |
| *** markvoelker has quit IRC | 04:36 | |
| *** sapd1 has quit IRC | 04:37 | |
| *** sapd1 has joined #openstack-keystone | 04:44 | |
| *** sapd1 has quit IRC | 05:11 | |
| *** sapd1 has joined #openstack-keystone | 05:25 | |
| *** sapd1 has quit IRC | 05:29 | |
| *** sapd1 has joined #openstack-keystone | 05:29 | |
| *** markvoelker has joined #openstack-keystone | 05:33 | |
| *** sapd1 has quit IRC | 05:36 | |
| *** sapd1 has joined #openstack-keystone | 05:37 | |
| *** sapd1 has quit IRC | 05:46 | |
| *** sapd1 has joined #openstack-keystone | 05:47 | |
| *** awalende has joined #openstack-keystone | 05:48 | |
| *** awalende has quit IRC | 05:53 | |
| *** awalende has joined #openstack-keystone | 05:54 | |
| *** sapd1 has quit IRC | 05:57 | |
| *** sapd1 has joined #openstack-keystone | 05:58 | |
| *** markvoelker has quit IRC | 06:06 | |
| *** sapd1 has quit IRC | 06:07 | |
| *** whoami-rajat has quit IRC | 06:13 | |
| *** awalende has quit IRC | 06:24 | |
| *** whoami-rajat has joined #openstack-keystone | 06:25 | |
| *** awalende has joined #openstack-keystone | 06:33 | |
| *** phasespace has quit IRC | 06:40 | |
| *** obre has quit IRC | 06:52 | |
| *** obre has joined #openstack-keystone | 06:52 | |
| *** sapd1 has joined #openstack-keystone | 06:52 | |
| *** markvoelker has joined #openstack-keystone | 07:03 | |
| *** awalende has quit IRC | 07:13 | |
| *** mvkr has quit IRC | 07:27 | |
| *** markvoelker has quit IRC | 07:36 | |
| *** phasespace has joined #openstack-keystone | 07:56 | |
| openstackgerrit | Rico Lin proposed openstack/keystoneauth master: Update auth plugin name list in document https://review.openstack.org/648920 | 08:06 |
|---|---|---|
| *** markvoelker has joined #openstack-keystone | 08:34 | |
| *** tkajinam has quit IRC | 08:58 | |
| *** markvoelker has quit IRC | 09:07 | |
| *** mvkr has joined #openstack-keystone | 09:30 | |
| *** markvoelker has joined #openstack-keystone | 10:04 | |
| *** mvkr has quit IRC | 10:34 | |
| *** markvoelker has quit IRC | 10:36 | |
| *** mvkr has joined #openstack-keystone | 10:48 | |
| *** mvkr has quit IRC | 11:04 | |
| *** mvkr has joined #openstack-keystone | 11:05 | |
| *** dave-mccowan has joined #openstack-keystone | 11:38 | |
| *** yan0s has joined #openstack-keystone | 11:42 | |
| *** mvkr has quit IRC | 11:44 | |
| *** mvkr has joined #openstack-keystone | 11:56 | |
| *** jamesmcarthur has joined #openstack-keystone | 12:13 | |
| *** starborn has joined #openstack-keystone | 12:20 | |
| *** jamesmcarthur has quit IRC | 12:34 | |
| *** lbragstad has joined #openstack-keystone | 12:36 | |
| *** ChanServ sets mode: +o lbragstad | 12:36 | |
| *** raildo has joined #openstack-keystone | 12:39 | |
| *** jamesmcarthur has joined #openstack-keystone | 12:47 | |
| *** jamesmcarthur has quit IRC | 13:04 | |
| *** ybunker has joined #openstack-keystone | 13:05 | |
| *** jmlowe has quit IRC | 13:08 | |
| *** rcernin has quit IRC | 13:18 | |
| *** pcaruana has quit IRC | 13:20 | |
| *** jmlowe has joined #openstack-keystone | 13:37 | |
| *** phasespace has quit IRC | 13:37 | |
| *** pcaruana has joined #openstack-keystone | 13:42 | |
| openstackgerrit | Jens Harbott (frickler) proposed openstack/keystonemiddleware master: DNM: Test running without identity admin endpoint https://review.openstack.org/651790 | 14:02 |
| *** erus has joined #openstack-keystone | 14:02 | |
| erus | o/ | 14:02 |
| *** awalende has joined #openstack-keystone | 14:22 | |
| openstackgerrit | Jens Harbott (frickler) proposed openstack/keystonemiddleware master: DNM: Test running without identity admin endpoint https://review.openstack.org/651790 | 14:26 |
| *** awalende has quit IRC | 14:26 | |
| cmurphy | o/ | 14:30 |
| gagehugo | o/ | 14:31 |
| knikolla | o/ | 14:39 |
| ayoung | Predictable role ids: If we do https://review.openstack.org/#/c/651655/ we can have a later database migration that makes use of it, right? | 14:48 |
| ayoung | I was thinking something like: take all the existing roles, give them a new name like -migrating-Member. Then recreate the roles with the new id, convert all the role assignments to use the new IDs, and finally drop the old roles. Make sense? | 14:50 |
| *** dklyle has joined #openstack-keystone | 14:51 | |
| cmurphy | ayoung: what if some external tool is depending on the original role IDs? | 14:53 |
| ayoung | It will break | 14:54 |
| ayoung | We need to be able to do that, though. Perhaps at a major release | 14:54 |
| ayoung | If we can't, OpenStack can't scale. | 14:55 |
| cmurphy | what if we added a keystone-manage command so people could opt-in to breaking their role IDs? | 14:55 |
| ayoung | Yes, that would work | 14:55 |
| ayoung | That makes more sense, as it would be on their cadence, not ours | 14:56 |
| ayoung | OK, I can spec that out. Could we do the same thing for Project IDs? | 14:56 |
| ayoung | I think in order to do that, we'd need project names to be immutable. | 14:56 |
| ayoung | same with roles, actually. I see lbragstad has a spec on that | 14:57 |
| cmurphy | do you mean https://review.openstack.org/624692 ? | 14:58 |
| *** gyee has joined #openstack-keystone | 15:12 | |
| *** mvkr has quit IRC | 15:27 | |
| kmalloc | why would you need to change project_ids? | 15:38 |
| kmalloc | oh you mean use the actual id generator bit | 15:39 |
| kmalloc | ? | 15:39 |
| kmalloc | ayoung: the immutable-ness was a flag (resource option) not an inherent property iirc | 15:39 |
| kmalloc | so roles, etc could be marked as immutable | 15:40 |
| kmalloc | some issues have come up with "oops i deleted the wrong, very important thing" | 15:40 |
| cmurphy | he wants to migrate old projects to the newly-generated IDs so that the deployment could be expanded | 15:40 |
| kmalloc | I think that will never be a good idea, even as an opt in | 15:41 |
| kmalloc | notably, it will break some stuff really badly. | 15:41 |
| kmalloc | and part of that is the hassle/issues of uuid as PK for some of the columns/tables | 15:42 |
| *** pcaruana has quit IRC | 15:42 | |
| kmalloc | now... if we had a DB layer that could use the old ID and the new id (projects, roles are... something different) | 15:44 |
| kmalloc | for compat, and we re-structure for the new-id to be canonical. I could see that working. | 15:44 |
| kmalloc | e.g. legacy_id we carried in the past for some thing | 15:45 |
| cmurphy | that might work | 15:45 |
| kmalloc | this however would never be removable. | 15:45 |
| kmalloc | as long as the new IDs can be distinguished, e.g. more bytes, it is simple to say "oh ID is clearly not 32bytes hex? great, use non-legacy" | 15:46 |
| kmalloc | i would also move to an autoinc PK on projects/anything else getting this treatment, and isolate the public ID like we do on the more modern additions to keystone | 15:46 |
| kmalloc | if you're already adding deep data changing migrations | 15:46 |
| kmalloc | ayoung: ^ cc | 15:47 |
| *** jamesmcarthur has joined #openstack-keystone | 15:49 | |
| *** jamesmcarthur_ has joined #openstack-keystone | 15:50 | |
| *** jamesmcarthur has quit IRC | 15:50 | |
| *** yan0s has quit IRC | 15:58 | |
| *** ybunker has quit IRC | 16:01 | |
| *** ybunker has joined #openstack-keystone | 16:02 | |
| *** ybunker has quit IRC | 16:05 | |
| *** ybunker has joined #openstack-keystone | 16:05 | |
| ayoung | cmurphy, sorry, pullled away. Yeah, that is the spec. | 16:28 |
| *** erus has quit IRC | 16:28 | |
| *** erus has joined #openstack-keystone | 16:29 | |
| ayoung | kmalloc, processing what you are saying. I think we are converging on a solution....ok let me lay out what I am looking for | 16:29 |
| ayoung | in the hub and spoke model, I want to be able to do something at the hub and see it at the spoke. ROle assignment is the big one | 16:29 |
| ayoung | right now, the only way we have to do that is Federated mapping, and I am toying with the idea of doing something based on that, but the current impl is too monolithic for my tastes. PLus, LDAP is still king for multisite | 16:30 |
| kmalloc | and since roles are almost 100% referenced by name in policy/etc i see zero issue with an opt-in "fix role IDs" | 16:30 |
| ayoung | I'd rather have a single mechanism for both | 16:30 |
| kmalloc | project_ids and other resources not so much | 16:30 |
| ayoung | kmalloc, yeah, I'm with you on that | 16:30 |
| kmalloc | the ids for those must remain forever unless the project is deleted. | 16:31 |
| ayoung | to do a role assignment you need userid, projectid, roleid | 16:31 |
| kmalloc | because project ids / domain ids, user ids are used in the auth flow, user facing | 16:31 |
| ayoung | again, it could be opt in | 16:31 |
| kmalloc | it's not something you can "look up" | 16:31 |
| kmalloc | role ids you can, once you've authed | 16:31 |
| ayoung | The norm is OS_USER_DOMAIN_NAME nad OS_PROJECT_DOMAIN_NAME plus username and project name | 16:32 |
| kmalloc | not in all cases. | 16:32 |
| ayoung | I know | 16:32 |
| ayoung | I said norm | 16:32 |
| kmalloc | ID is used frequently | 16:32 |
| kmalloc | i'd argue id is used as much as name | 16:32 |
| ayoung | so...something like this | 16:32 |
| ayoung | 1. specify immutable project names | 16:32 |
| kmalloc | that is an API break. need microversions | 16:32 |
| kmalloc | (sorry) | 16:33 |
| ayoung | 2. run keystone-manange --normalize-project-ids | 16:33 |
| ayoung | not if it is a config option | 16:33 |
| ayoung | it can be opt in | 16:33 |
| kmalloc | god, no. | 16:33 |
| ayoung | this is only for multisite | 16:33 |
| kmalloc | don't do that. | 16:33 |
| ayoung | you always react this way | 16:33 |
| kmalloc | create a legacy_id. | 16:33 |
| kmalloc | carry either/or lookup | 16:33 |
| ayoung | ok...talk me through that | 16:33 |
| kmalloc | legacy id, either column or new mapping table | 16:34 |
| ayoung | back up | 16:34 |
| ayoung | immutable is kindof necessary | 16:34 |
| kmalloc | legacy id is the old ID before predictible ids. | 16:34 |
| ayoung | otherwise we have no way to do predictability | 16:34 |
| ayoung | I think I'm ok with a duplicate ID approach, but suspect it won't really be necessary. What is wrong with making immutable IDs a config option | 16:35 |
| kmalloc | changing the whole functionality of the system and making it so you have no idea without trying to utilize the API how it's configured makes openstack suck as a user | 16:35 |
| kmalloc | this is a huge problem with openstack in general | 16:36 |
| kmalloc | depending on config etc the API acts massively different | 16:36 |
| kmalloc | deployment to deployment | 16:36 |
| kmalloc | it's poor design. | 16:37 |
| kmalloc | it also is not really testable without adding a distinct testing suite. | 16:38 |
| kmalloc | it would not pass tempest. | 16:38 |
| ayoung | I won't argue on poor desing, but termie has long since left the project | 16:38 |
| ayoung | design | 16:38 |
| ayoung | design | 16:38 |
| ayoung | ha | 16:38 |
| ayoung | I can't spell, even when I spell it right | 16:39 |
| kmalloc | these permutations on deployment make for consistent testing/not-so-edge-case testing really tough | 16:39 |
| *** dave-mccowan has quit IRC | 16:39 | |
| kmalloc | and likely to break things in weird ways | 16:39 |
| ayoung | I'd argue that project renames are done like 0% of thetime | 16:40 |
| kmalloc | it's, from my discussions, about 5-10% | 16:40 |
| kmalloc | because the name is used to encode purpose | 16:40 |
| kmalloc | or other relevant things. | 16:40 |
| ayoung | ok, most resources are tagged by proejct ID, so changing project IDs really is not an option anyway | 16:40 |
| ayoung | roles and assignments, sure | 16:41 |
| kmalloc | and that ^ | 16:41 |
| ayoung | how would we roll in a multisite approach? | 16:41 |
| kmalloc | so, unless you're maintaining a new column and a legacy column it doesn't work. | 16:41 |
| kmalloc | really, the best option is centralizing project information in a tool like athenz | 16:41 |
| kmalloc | and auto-provision | 16:41 |
| kmalloc | with a side-band cleanup. | 16:41 |
| ayoung | I'm not pushing for an external tool | 16:42 |
| kmalloc | and policy off "project-update" outside of the provision/external work-flow tool | 16:42 |
| ayoung | that just punts on the problem, not solves it | 16:42 |
| kmalloc | either replicate the database or don't | 16:42 |
| kmalloc | in the don't case, provision on demand | 16:42 |
| ayoung | so, we had a customer propose async db replication | 16:43 |
| ayoung | I think we could get away with that if TripleO supported an option to do so | 16:43 |
| ayoung | like "here is the sql load script for the Keystone database" | 16:43 |
| kmalloc | you should chat with eandersson, there are some serious issues with it in how keystone is built | 16:43 |
| kmalloc | it's not really doable above a small number of sites because we have autoinc PKs in the shadow table (if ldap/fed is used) | 16:44 |
| kmalloc | and we didn't cleanly address async repl | 16:44 |
| ayoung | but there are still day 2 ops that we'd want to make sure worked with local calls. Like, Heat etc need to create app creds. Are those going to only be local? | 16:44 |
| kmalloc | so maybe we need to back away from auto-inc PKs? | 16:44 |
| ayoung | ++ | 16:44 |
| kmalloc | it's terrible for performance and mem utilization | 16:44 |
| kmalloc | FTR | 16:44 |
| kmalloc | it is a bad choice to mix exposed/API IDs and internal record keeping IDs. | 16:45 |
| ayoung | and with predictable IDs there is less reason to have them | 16:45 |
| kmalloc | except that it will bite us in large environments. | 16:45 |
| ayoung | I'm really only concerned about large environs. Go on | 16:46 |
| kmalloc | it's an issue with how (assuming mysql/mariadb) works with the PK and indexing on the uuid. | 16:46 |
| kmalloc | ints are more efficient/performant on these fronts | 16:46 |
| ayoung | how large of an int do we need? | 16:46 |
| kmalloc | it's fundamentally the bytes in the column | 16:47 |
| kmalloc | a hugeint is less than a varchar255 | 16:47 |
| ayoung | so, we do either 32 or 64 char fields for ids. A uuid is 32 chars. That fits in hugeint, if converted, right? | 16:48 |
| kmalloc | and it is unlikely we will need uint64 space | 16:48 |
| kmalloc | 64char does not fit | 16:49 |
| ayoung | 898ed3bdcb749c665866ee2750ab50d7ac5da6b666546fcd952cfc4cbc0c33b4 | 16:49 |
| kmalloc | it is likely we need a uint32 at most | 16:49 |
| kmalloc | ~4bn project records. somehow i don't think we'll get there. | 16:49 |
| ayoung | that is, what, 64 hex chars | 16:49 |
| kmalloc | without hitting a LOT more issues | 16:49 |
| kmalloc | anyway. it's mechanisms for how the rdbms works. | 16:50 |
| ayoung | 80 bits, right? | 16:50 |
| kmalloc | uhm... | 16:50 |
| ayoung | so a 128 bit number should store any of our current ids in a compact format. | 16:51 |
| kmalloc | mysql: bigint is 8 bytes | 16:52 |
| kmalloc | a uuid hex (32) compresses to ~16bytes in bin format in python | 16:52 |
| ayoung | heh | 16:52 |
| *** jamesmcarthur has joined #openstack-keystone | 16:52 | |
| kmalloc | and bigint is int(64), so -2^63 - 2^63-1 or 2^64-1 [unsigned] | 16:53 |
| ayoung | so it won't work | 16:53 |
| kmalloc | right. | 16:53 |
| kmalloc | uuids have a LOT of extra content. | 16:53 |
| kmalloc | compared to ints. | 16:53 |
| kmalloc | now, if we decide it is super important to be non-auto-inc and PK specified (generated as uuid or etc in the app), we take the hit in mem and performance | 16:54 |
| ayoung | I'll have to convince myself of the math, but I'll accept it for now to move things along | 16:54 |
| kmalloc | and we explicitly outline it. | 16:54 |
| kmalloc | >>> sys.getsizeof(uuid.uuid4().bytes) | 16:55 |
| kmalloc | 49 | 16:55 |
| kmalloc | >>> sys.getsizeof(uuid.uuid4().hex) | 16:55 |
| kmalloc | 81 | 16:55 |
| *** erus has quit IRC | 16:55 | |
| kmalloc | that is including overhead. | 16:55 |
| kmalloc | >>> len(uuid.uuid4().bytes) | 16:55 |
| kmalloc | 16 | 16:55 |
| *** jamesmcarthur_ has quit IRC | 16:56 | |
| kmalloc | >>> len(uuid.uuid4().hex) | 16:56 |
| kmalloc | 32 | 16:56 |
| *** erus has joined #openstack-keystone | 16:56 | |
| kmalloc | so, issue 1) predictable ID, not so predictable because we can't change them. | 16:56 |
| ayoung | and we do sha256 in a few places now which is double that | 16:57 |
| kmalloc | (e.g. can't make them conforming with manage, it'll break nova and everything else) | 16:57 |
| kmalloc | yeah we do. | 16:57 |
| kmalloc | 2) int vs uuid PK performance in MySQL/MariaDB | 16:57 |
| kmalloc | 2 is "make the choice and outline why the choice is made" | 16:57 |
| kmalloc | but we have things we need to fix / migrate away from due to choice made when we weren't dealing with async replication | 16:58 |
| ayoung | Performance is less of an issue if we get scale out right | 16:58 |
| kmalloc | issue 1 is much harder to work around. | 16:58 |
| kmalloc | the performance hit is DB operation related | 16:58 |
| kmalloc | so it's not so much "many keystones" solve it | 16:58 |
| kmalloc | it's going to be how much crunch the DB can handle | 16:58 |
| ayoung | Can we add an immutable field to a project object now? | 16:59 |
| kmalloc | we can. i argue it should be a resource-option and be an option for ALL resources | 16:59 |
| ayoung | I'd be OK with it for only stuff moving forward | 16:59 |
| ayoung | OK, I like that idea | 16:59 |
| kmalloc | :) | 16:59 |
| ayoung | we do it for users, roles, and projects | 16:59 |
| kmalloc | i envision it being like chattr +i | 16:59 |
| ayoung | ++ | 16:59 |
| kmalloc | roles, projects, users, domains, federation protocols, etc | 17:00 |
| ayoung | what would the default be? | 17:00 |
| kmalloc | default would be "off" unless we add a template set of options for a given resource | 17:00 |
| kmalloc | and that is for api compatibility | 17:00 |
| ayoung | not federation protocols, and not mapping. We want to be able to manipulate those, I think | 17:00 |
| kmalloc | nah, it's an opt in | 17:00 |
| kmalloc | you can always chattr -i a resource | 17:01 |
| ayoung | hmmm | 17:01 |
| kmalloc | it's the same deal here, un-set immutable (if you are allowed) | 17:01 |
| kmalloc | and change it | 17:01 |
| kmalloc | i also see resource options as having their own policy entries | 17:01 |
| ayoung | mapping is too monolithic as is | 17:01 |
| kmalloc | a "generic" for the resource and an override. | 17:01 |
| ayoung | ok, so for a multisite, we would want all new resources to be immutable | 17:02 |
| kmalloc | so you can say an system-user can always set immutable (for example) [or unset], but an owner can set other flags. | 17:02 |
| ayoung | i.e. only sync down from the center | 17:02 |
| kmalloc | in policy, since resource_option:immutable is system(writer) only | 17:02 |
| ayoung | ok, you've obviously thought this through. Can you write up your thoughts? | 17:03 |
| kmalloc | i think i wrote a spec already.... | 17:03 |
| kmalloc | let me check | 17:03 |
| kmalloc | or adriant did | 17:03 |
| ayoung | ++ | 17:03 |
| kmalloc | https://review.openstack.org/#/c/624162/ is the resource-options-for-all spec | 17:03 |
| kmalloc | https://review.openstack.org/#/c/624692/ that is the core of it | 17:04 |
| *** erus has quit IRC | 17:04 | |
| kmalloc | and there is a spec missing that is "add policy for resource-options" | 17:05 |
| *** erus has joined #openstack-keystone | 17:05 | |
| ayoung | Oh, he's targetting something else with that. You just weant to piggyback...interensting | 17:05 |
| *** pcaruana has joined #openstack-keystone | 17:05 | |
| kmalloc | the concept is super useful outside of your usecase | 17:06 |
| kmalloc | and it lines up really nicely to solve the problem | 17:06 |
| kmalloc | this is exactly one of the cases i saw immutable as solving | 17:06 |
| kmalloc | and i was wrong, cmurphy was the person writing up the immutable resource-options | 17:08 |
| kmalloc | adriant had another use case where resource-option(s) were relevant | 17:08 |
| ayoung | She had immutable roles....are there others? | 17:08 |
| kmalloc | i figured if we add immutable to roles we should add it to most resources | 17:09 |
| kmalloc | it prevents accidental updates/deletions. | 17:09 |
| kmalloc | once we have the template for it to work in one place, it's super easy to add it elsewhere | 17:09 |
| ayoung | Need a way to make it the default for things, tho | 17:12 |
| ayoung | Is that on a per user basis? Something that is inherited? | 17:12 |
| cmurphy | in the spec it's the roles that are created by bootstrap that become immutable by default | 17:15 |
| ayoung | cmurphy, are you OK with morphing https://review.openstack.org/#/c/624692/ into a general immutable spec, or would you prefer to keep the role specific stuff there and creata new one for all resources | 17:15 |
| kmalloc | the way i'd roll it is keep that role-immutable and then propose an additional spec to replicate that to other resources | 17:16 |
| cmurphy | ayoung: i should fix the commit message but it already is generic, it just has a special case for roles since the idea is to change the default behavior for them | 17:17 |
| *** erus has quit IRC | 17:17 | |
| *** erus has joined #openstack-keystone | 17:18 | |
| ayoung | Cool. But those really are two distinct things | 17:23 |
| ayoung | But I am 100% on board | 17:23 |
| *** gyee has quit IRC | 17:29 | |
| *** jamesmcarthur has quit IRC | 17:35 | |
| *** jamesmcarthur has joined #openstack-keystone | 17:47 | |
| *** jamesmcarthur has quit IRC | 17:54 | |
| *** jamesmcarthur has joined #openstack-keystone | 17:56 | |
| *** jamesmcarthur has quit IRC | 17:58 | |
| *** jamesmcarthur has joined #openstack-keystone | 17:59 | |
| *** jamesmcarthur has quit IRC | 18:01 | |
| *** jamesmcarthur has joined #openstack-keystone | 18:02 | |
| *** gmann is now known as gmann_afk | 18:15 | |
| *** ybunker has quit IRC | 18:23 | |
| *** jamesmcarthur has quit IRC | 18:26 | |
| *** jamesmcarthur has joined #openstack-keystone | 18:28 | |
| *** jmlowe has quit IRC | 18:32 | |
| *** pcaruana has quit IRC | 19:02 | |
| openstackgerrit | Merged openstack/keystoneauth master: Update auth plugin name list in document https://review.openstack.org/648920 | 19:09 |
| *** erus has quit IRC | 19:09 | |
| *** erus has joined #openstack-keystone | 19:10 | |
| *** jmlowe has joined #openstack-keystone | 19:15 | |
| *** gmann_afk is now known as gmann | 19:27 | |
| *** zaneb has quit IRC | 19:53 | |
| *** erus has quit IRC | 19:53 | |
| *** erus has joined #openstack-keystone | 19:53 | |
| *** starborn has quit IRC | 20:04 | |
| *** jamesmcarthur has quit IRC | 20:10 | |
| openstackgerrit | Merged openstack/keystonemiddleware master: Fix string format error https://review.openstack.org/651399 | 21:01 |
| *** whoami-rajat has quit IRC | 21:03 | |
| *** gyee has joined #openstack-keystone | 21:49 | |
| *** jamesmcarthur has joined #openstack-keystone | 22:01 | |
| *** jamesmcarthur has quit IRC | 22:14 | |
| *** rcernin has joined #openstack-keystone | 22:26 | |
| *** tkajinam has joined #openstack-keystone | 23:00 | |
| *** kukacz has quit IRC | 23:21 | |
| *** prometheanfire has quit IRC | 23:21 | |
| *** bbobrov has quit IRC | 23:21 | |
| *** irclogbot_1 has quit IRC | 23:24 | |
| *** kukacz has joined #openstack-keystone | 23:27 | |
| *** prometheanfire has joined #openstack-keystone | 23:27 | |
| *** bbobrov has joined #openstack-keystone | 23:27 | |
| *** raildo has quit IRC | 23:29 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!