| *** diazjf has joined #openstack-keystone | 00:03 | |
| *** thorst_ has joined #openstack-keystone | 00:03 | |
| *** jamielennox|away is now known as jamielennox | 00:05 | |
| *** voelzmo has joined #openstack-keystone | 00:06 | |
| *** thorst_ has quit IRC | 00:08 | |
| *** voelzmo has quit IRC | 00:11 | |
| *** stingaci has joined #openstack-keystone | 00:16 | |
| *** stingaci has quit IRC | 00:21 | |
| *** edmondsw has joined #openstack-keystone | 00:43 | |
| *** edmondsw has quit IRC | 00:48 | |
| *** stingaci has joined #openstack-keystone | 00:48 | |
| *** thorst_ has joined #openstack-keystone | 00:50 | |
| *** stingaci has quit IRC | 00:52 | |
| *** thorst_ has quit IRC | 00:53 | |
| *** hoangcx has joined #openstack-keystone | 00:54 | |
| *** diazjf has quit IRC | 00:55 | |
| *** nkinder has joined #openstack-keystone | 00:59 | |
| *** stingaci has joined #openstack-keystone | 01:05 | |
| *** stingaci has quit IRC | 01:09 | |
| *** liujiong has joined #openstack-keystone | 01:19 | |
| *** liujiong has quit IRC | 01:32 | |
| *** liujiong has joined #openstack-keystone | 01:33 | |
| *** g2[ATL] is now known as g2 | 01:36 | |
| *** stingaci has joined #openstack-keystone | 01:37 | |
| *** dikonoor has quit IRC | 01:39 | |
| *** stingaci has quit IRC | 01:41 | |
| *** thorst_ has joined #openstack-keystone | 01:55 | |
| *** thorst_ has quit IRC | 01:56 | |
| *** voelzmo has joined #openstack-keystone | 02:07 | |
| *** stingaci has joined #openstack-keystone | 02:09 | |
| *** voelzmo has quit IRC | 02:12 | |
| *** stingaci has quit IRC | 02:14 | |
| *** agrebennikov__ has joined #openstack-keystone | 02:18 | |
| *** agrebennikov_ has quit IRC | 02:20 | |
| *** jefrite has quit IRC | 02:20 | |
| *** jdennis has quit IRC | 02:24 | |
| *** stingaci has joined #openstack-keystone | 02:25 | |
| *** jdennis has joined #openstack-keystone | 02:25 | |
| *** jefrite has joined #openstack-keystone | 02:27 | |
| *** stingaci has quit IRC | 02:29 | |
| *** dave-mccowan has joined #openstack-keystone | 02:38 | |
| *** thorst_ has joined #openstack-keystone | 02:48 | |
| *** thorst_ has quit IRC | 02:48 | |
| *** jerrygb has joined #openstack-keystone | 02:55 | |
| *** stingaci has joined #openstack-keystone | 02:57 | |
| *** stingaci has quit IRC | 03:01 | |
| *** david-lyle has joined #openstack-keystone | 03:15 | |
| *** david-lyle has quit IRC | 03:21 | |
| *** stingaci has joined #openstack-keystone | 03:30 | |
| *** stingaci has quit IRC | 03:34 | |
| *** jefrite has quit IRC | 03:43 | |
| *** richm has quit IRC | 03:44 | |
| *** jefrite has joined #openstack-keystone | 03:49 | |
| *** dave-mccowan has quit IRC | 03:53 | |
| *** jefrite has quit IRC | 03:54 | |
| *** dikonoor has joined #openstack-keystone | 03:54 | |
| *** jerrygb has quit IRC | 04:03 | |
| *** dave-mccowan has joined #openstack-keystone | 04:04 | |
| *** stingaci has joined #openstack-keystone | 04:06 | |
| *** stingaci has quit IRC | 04:10 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 04:13 | |
| *** nicolasbock has quit IRC | 04:14 | |
| *** stingaci has joined #openstack-keystone | 04:23 | |
| *** furface has quit IRC | 04:23 | |
| *** dikonoor has quit IRC | 04:26 | |
| *** stingaci has quit IRC | 04:27 | |
| *** dave-mccowan has quit IRC | 04:35 | |
| *** lamt has joined #openstack-keystone | 04:36 | |
| *** v1k0d3n has quit IRC | 04:44 | |
| *** v1k0d3n has joined #openstack-keystone | 04:44 | |
| *** thorst_ has joined #openstack-keystone | 04:49 | |
| *** agrebennikov__ has quit IRC | 04:53 | |
| *** thorst_ has quit IRC | 04:54 | |
| *** stingaci has joined #openstack-keystone | 04:55 | |
| *** stingaci has quit IRC | 04:59 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users https://review.openstack.org/414720 | 05:01 |
|---|---|---|
| *** voelzmo has joined #openstack-keystone | 05:09 | |
| *** voelzmo has quit IRC | 05:14 | |
| *** furface has joined #openstack-keystone | 05:17 | |
| *** lamt has quit IRC | 05:24 | |
| *** stingaci has joined #openstack-keystone | 05:27 | |
| *** stingaci has quit IRC | 05:31 | |
| *** furface has quit IRC | 05:31 | |
| *** lamt has joined #openstack-keystone | 05:36 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone: Deprecate `ignore_password_expire_user_ids` conf option https://review.openstack.org/423909 | 05:37 |
| morgan | rderose: ^ see this patch. I'll correct any issues in CI tomorrow and will duplicate the patch for the lockout option as well (should be much quicker since I know all the places needing to be updated) | 05:38 |
| morgan | rderose: if you'r enot opposed i'll rebase your change onto them (once you look them over) | 05:39 |
| morgan | stevemar: ^ cc | 05:39 |
| *** furface has joined #openstack-keystone | 05:47 | |
| *** v1k0d3n has quit IRC | 05:56 | |
| *** v1k0d3n has joined #openstack-keystone | 06:02 | |
| *** furface has quit IRC | 06:03 | |
| *** jerrygb has joined #openstack-keystone | 06:04 | |
| *** jerrygb has quit IRC | 06:08 | |
| openstackgerrit | zhangyanxian proposed openstack/oslo.policy: Delete the unnecessary word in policy.py https://review.openstack.org/423920 | 06:13 |
| *** edmondsw has joined #openstack-keystone | 06:13 | |
| openstackgerrit | zhangyanxian proposed openstack/oslo.policy: Delete the unnecessary word in policy.py https://review.openstack.org/423920 | 06:13 |
| *** furface has joined #openstack-keystone | 06:13 | |
| *** edmondsw has quit IRC | 06:17 | |
| *** Jack_I has joined #openstack-keystone | 06:20 | |
| openstackgerrit | Anh Tran proposed openstack/keystone-specs: Typo fix: foriegn => foreign https://review.openstack.org/423937 | 06:26 |
| breton | saw a link on openstack@ and saw there how repose configures rbac: https://repose.atlassian.net/wiki/display/REPOSE/Role-based+access+control+(RBAC)+with+Repose | 06:30 |
| *** dikonoor has joined #openstack-keystone | 06:31 | |
| *** lamt has quit IRC | 06:40 | |
| *** thorst_ has joined #openstack-keystone | 06:50 | |
| *** furface has quit IRC | 06:52 | |
| *** thorst_ has quit IRC | 06:55 | |
| *** dikonoor has quit IRC | 07:09 | |
| *** dikonoor has joined #openstack-keystone | 07:11 | |
| *** voelzmo has joined #openstack-keystone | 07:18 | |
| *** tesseract has joined #openstack-keystone | 07:31 | |
| openstackgerrit | Merged openstack/keystone-specs: Typo fix: foriegn => foreign https://review.openstack.org/423937 | 07:35 |
| *** pnavarro has joined #openstack-keystone | 07:40 | |
| *** dikonoor has quit IRC | 08:17 | |
| *** pcaruana has joined #openstack-keystone | 08:17 | |
| *** dikonoor has joined #openstack-keystone | 08:18 | |
| *** stingaci has joined #openstack-keystone | 08:34 | |
| *** thorst_ has joined #openstack-keystone | 08:51 | |
| *** thorst_ has quit IRC | 08:56 | |
| openstackgerrit | Merged openstack/oslo.policy: Delete the unnecessary word in policy.py https://review.openstack.org/423920 | 08:59 |
| *** zzzeek has quit IRC | 09:00 | |
| *** zzzeek has joined #openstack-keystone | 09:01 | |
| *** n1b has joined #openstack-keystone | 09:13 | |
| *** yarkot has quit IRC | 09:29 | |
| *** edmondsw has joined #openstack-keystone | 09:50 | |
| *** edmondsw has quit IRC | 09:54 | |
| *** liujiong has quit IRC | 10:01 | |
| *** mvk has quit IRC | 10:12 | |
| *** hoangcx has quit IRC | 10:27 | |
| *** dikonoor has quit IRC | 10:28 | |
| *** zhugaoxiao has quit IRC | 10:34 | |
| *** mvk has joined #openstack-keystone | 10:46 | |
| *** sm1235 has joined #openstack-keystone | 10:48 | |
| *** dikonoor has joined #openstack-keystone | 10:51 | |
| *** thorst_ has joined #openstack-keystone | 10:52 | |
| *** thorst_ has quit IRC | 10:57 | |
| *** portdirect_away is now known as portdirect | 10:59 | |
| *** thiagolib has joined #openstack-keystone | 11:07 | |
| *** dikonoor has quit IRC | 11:11 | |
| dims | stevemar : whatever is baked into the infra images i think | 11:11 |
| *** ayoung has joined #openstack-keystone | 11:12 | |
| *** ChanServ sets mode: +v ayoung | 11:12 | |
| *** dikonoor has joined #openstack-keystone | 11:12 | |
| *** dikonoor has quit IRC | 11:31 | |
| *** nicolasbock has joined #openstack-keystone | 11:43 | |
| *** haplo37_ has quit IRC | 11:44 | |
| *** dikonoor has joined #openstack-keystone | 11:45 | |
| *** erlon has joined #openstack-keystone | 11:49 | |
| *** haplo37_ has joined #openstack-keystone | 11:56 | |
| samueldmq | hey keystoners, I am back from LCA! | 11:58 |
| samueldmq | hope you all had a great weekend | 11:58 |
| *** thorst_ has joined #openstack-keystone | 12:03 | |
| *** thorst_ has quit IRC | 12:04 | |
| *** stingaci has quit IRC | 12:04 | |
| *** dave-mccowan has joined #openstack-keystone | 12:05 | |
| *** eftepede has joined #openstack-keystone | 12:11 | |
| eftepede | Hi all. I've trying to auth against keystone by designate. I'm passing correct token, but keystone middleware always tries to auth via adminURL, not public. | 12:12 |
| eftepede | Is there any way to force using of publicURL? | 12:12 |
| ayoung | eftepede, yeah....there was a config setting in Keystone that tells it to rewrite requests | 12:17 |
| ayoung | eftepede, its not super intuitive, something with admin_ulr in the name | 12:17 |
| ayoung | eftepede, if you don't explicitly set that value, everything works. If you set it, Keystone makes everything go admin | 12:18 |
| ayoung | eftepede, http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone.conf.sample#n27 Maybe? | 12:19 |
| *** dave-mccowan has quit IRC | 12:25 | |
| eftepede | I have auth_url pointed to public url. | 12:43 |
| *** dave-mccowan has joined #openstack-keystone | 12:45 | |
| *** catintheroof has joined #openstack-keystone | 12:45 | |
| *** catintheroof has quit IRC | 12:50 | |
| asettle | Hey guys - I have a bug in manuals requesting for information about configuring RabbitMQ. It appears we don't document a lot of rabbitmq config, and it appears to be deprecated in newton - the last reference I can see is Kilo. Am I correct in assuming so? | 12:57 |
| *** catintheroof has joined #openstack-keystone | 12:58 | |
| asettle | lbragstad stevemar or dolphm ^^ | 12:59 |
| *** _sigmavirus24 is now known as sigmavirus | 13:02 | |
| *** sigmavirus has joined #openstack-keystone | 13:02 | |
| *** hrybacki|sick is now known as hrybacki | 13:04 | |
| *** lamt has joined #openstack-keystone | 13:12 | |
| *** raildo has joined #openstack-keystone | 13:13 | |
| *** lamt has quit IRC | 13:16 | |
| *** edmondsw has joined #openstack-keystone | 13:19 | |
| *** jaugustine has joined #openstack-keystone | 13:22 | |
| *** pnavarro has quit IRC | 13:23 | |
| *** v1k0d3n has quit IRC | 13:28 | |
| *** v1k0d3n has joined #openstack-keystone | 13:29 | |
| *** pnavarro has joined #openstack-keystone | 13:36 | |
| *** nicolasbock has quit IRC | 13:46 | |
| *** nicolasbock has joined #openstack-keystone | 13:51 | |
| frickler | asettle: are you sure that this is the right channel? I don't think I've seen keystone talk to rabbitmq. a lot of other services do, though, and most of the options used for configuring that have been deprecated indeed and replaced by transport_url | 13:54 |
| asettle | frickler: yeah, the bug specifically called out keystone integration with rabbitmq :) after a bit of digging, turns out it was most likely deprecated after Kilo in favor of transport_url :) | 13:55 |
| asettle | I believe the reporter had seen it previously, and wanted to use with newton, which he/she was unable to do. | 13:55 |
| *** nicolasbock has quit IRC | 13:58 | |
| *** richm has joined #openstack-keystone | 14:05 | |
| *** stingaci has joined #openstack-keystone | 14:06 | |
| *** nicolasbock has joined #openstack-keystone | 14:06 | |
| *** thorst_ has joined #openstack-keystone | 14:08 | |
| *** stingaci has quit IRC | 14:10 | |
| *** jerrygb has joined #openstack-keystone | 14:14 | |
| *** jerrygb_ has joined #openstack-keystone | 14:15 | |
| *** jerrygb__ has joined #openstack-keystone | 14:18 | |
| *** thiagolib has quit IRC | 14:18 | |
| *** jerrygb has quit IRC | 14:19 | |
| *** jerrygb_ has quit IRC | 14:20 | |
| lbragstad | asettle do you have a link? | 14:22 |
| asettle | lbragstad: ahhhh you know, I did | 14:22 |
| *** v1k0d3n has quit IRC | 14:23 | |
| *** v1k0d3n has joined #openstack-keystone | 14:24 | |
| asettle | lbragstad: that took a little finding: https://bugs.launchpad.net/openstack-manuals/+bug/1658396 | 14:25 |
| openstack | Launchpad bug 1658396 in openstack-manuals "What's the transport_url for keystone service?" [Undecided,Won't fix] | 14:25 |
| asettle | please correct me if I'm wrong, but that's what I found after my digging | 14:25 |
| lbragstad | asettle checking | 14:26 |
| asettle | Thanks lbragstad | 14:26 |
| *** catinthe_ has joined #openstack-keystone | 14:29 | |
| andreykurilin | stevemar: ping | 14:31 |
| *** voelzmo has quit IRC | 14:32 | |
| *** catintheroof has quit IRC | 14:32 | |
| *** dikonoor has quit IRC | 14:32 | |
| *** eftepede has left #openstack-keystone | 14:35 | |
| *** voelzmo has joined #openstack-keystone | 14:36 | |
| *** voelzmo has quit IRC | 14:38 | |
| lbragstad | asettle aha - ok that makes sense | 14:40 |
| lbragstad | asettle responding now | 14:40 |
| asettle | lbragstad: thank you :) | 14:40 |
| asettle | Appreciate that lbragstad | 14:40 |
| *** n1b has left #openstack-keystone | 14:51 | |
| lbragstad | asettle https://bugs.launchpad.net/openstack-manuals/+bug/1658396 | 14:52 |
| lbragstad | ^ hopefully that makes sense? | 14:52 |
| openstack | Launchpad bug 1658396 in openstack-manuals "What's the transport_url for keystone service?" [Undecided,Won't fix] | 14:52 |
| *** stingaci has joined #openstack-keystone | 14:52 | |
| asettle | lbragstad: yes :) a much better explanation than my "I think this is the thing, thank you kbye" | 14:53 |
| lbragstad | asettle i don't think we have any place that explains that clearly though | 14:54 |
| *** stingaci has quit IRC | 14:54 | |
| *** stingaci has joined #openstack-keystone | 14:54 | |
| asettle | lbragstad: to be honest, not really. I haven't seen anyone raise the issue before. To be honest, it might be worth having clearer docs about that. | 14:55 |
| asettle | Doc the non-doc issue. COurse that would be my solution. | 14:55 |
| lbragstad | asettle we could also amend the deprecation in config to be a little more clear, too | 14:56 |
| asettle | lbragstad: I think that's probably the better option of the two. Most deployers will go looking in the conf second to the docs | 14:56 |
| *** jaosorior has joined #openstack-keystone | 14:56 | |
| *** agrebennikov__ has joined #openstack-keystone | 14:58 | |
| lbragstad | asettle actually - it looks like that configuration option is owned by oslo.low | 14:58 |
| lbragstad | oslo.log* | 14:58 |
| asettle | lbragstad: rehhhhhh | 14:58 |
| asettle | lbragstad: rehhhhhh | 14:58 |
| asettle | Damnit | 14:58 |
| asettle | Stupid up key | 14:58 |
| asettle | What's next steps? | 14:58 |
| lbragstad | there is also a oslo_messaging_notifications transport_url section | 14:59 |
| *** stingaci has quit IRC | 15:00 | |
| morgan | o/ | 15:03 |
| lbragstad | asettle so - i think keystone could be clear about *why* we use rabbit, but we could try and talk to the oslo team about the different uses for transport_url across the various libraries | 15:05 |
| asettle | Oh man, this is going down the rabbit hole quickly. | 15:07 |
| *** edtubill has joined #openstack-keystone | 15:07 | |
| * lbragstad heads to the oslo channel | 15:08 | |
| *** voelzmo has joined #openstack-keystone | 15:13 | |
| morgan | lbragstad: man do i need to join over there too? | 15:13 |
| lbragstad | morgan you probably should ;) | 15:13 |
| morgan | lbragstad: wait what is going on | 15:13 |
| morgan | i might have the historical context for you | 15:13 |
| morgan | oh | 15:14 |
| lbragstad | morgan do you know why we have several places in our configuration that define transport_url for different sections? | 15:14 |
| lbragstad | (transport_url isn't used or tested by keystone anywhere - it is all specific to oslo code) | 15:14 |
| morgan | deprectated settings | 15:14 |
| morgan | and new code | 15:14 |
| morgan | basically you outlined it perfectly in your comment | 15:15 |
| morgan | testing might be light but afaik nothing really consumes/tests the consuming of kyesotne notifications | 15:15 |
| morgan | also all the audit trail is sent on the message bus | 15:15 |
| *** jamespage has joined #openstack-keystone | 15:15 | |
| morgan | and since oslo supplies the message bus connections | 15:16 |
| morgan | we don't do direct testing of it (dsvm might test it) | 15:16 |
| morgan | in fact, unit tests should NOT test that | 15:16 |
| *** stingaci has joined #openstack-keystone | 15:16 | |
| lbragstad | right | 15:16 |
| morgan | because we'd need rabbit... or a lot of mocking | 15:16 |
| morgan | tl;dr - your comment on the bug is 100% spot on | 15:16 |
| lbragstad | so we have https://github.com/openstack/keystone/blob/fa63f893d487d54fe932e42ad9b53eea7a24932f/etc/keystone.conf.sample#L411 and https://github.com/openstack/keystone/blob/fa63f893d487d54fe932e42ad9b53eea7a24932f/etc/keystone.conf.sample#L1795 ? | 15:17 |
| *** voelzmo has quit IRC | 15:19 | |
| *** knikolla has quit IRC | 15:20 | |
| *** knikolla has joined #openstack-keystone | 15:20 | |
| *** stingaci has quit IRC | 15:20 | |
| knikolla | o/ morning | 15:21 |
| *** spotz_zzz is now known as spotz | 15:21 | |
| lbragstad | knikolla o/ | 15:22 |
| *** nicodemus_ has joined #openstack-keystone | 15:30 | |
| nicodemus_ | hello | 15:31 |
| nicodemus_ | I'm having a little trouble trying to use 'loading' from keystoneauth1, but can't understand what I'm doing wrong... | 15:32 |
| *** ravelar has joined #openstack-keystone | 15:34 | |
| nicodemus_ | with "auth_plugin = loading.load_auth_from_conf_options(cfg.CONF, CFG_GROUP)", the code fails saying "no such option auth_section in group [service_credentials]" even if I configure that option | 15:34 |
| nicodemus_ | CFG_GROUP = service_credentials in this case | 15:35 |
| *** lamt has joined #openstack-keystone | 15:35 | |
| *** voelzmo has joined #openstack-keystone | 15:37 | |
| morgan | lbragstad, rderose: about to push ignore_lockout fix code | 15:38 |
| morgan | i need to add 2 more tests to each of the lockout/password-expiry code changes | 15:39 |
| morgan | and they should be ready to go | 15:39 |
| lbragstad | morgan cool | 15:40 |
| morgan | and then we can rebase rderose's change on top of it | 15:41 |
| morgan | in Pike i think we need to re-structure how we handle user options such as these | 15:41 |
| morgan | lbragstad: since you're running as PTL here is my rundown | 15:41 |
| morgan | lbragstad: new table, user-options. | 15:41 |
| morgan | lbragstad: options such as "ignore-password-expiry' are defined in code | 15:42 |
| morgan | lbragstad: user table then does a one[user] => many[options] relationship | 15:42 |
| morgan | options defined for the user are [option_id][user_id/PK][option_value] | 15:42 |
| morgan | this can then encompass multiple cases such as defining what options can be set by the user and what can be set by an admin only | 15:43 |
| morgan | user could set, say "default_project_id" | 15:43 |
| morgan | and we could drop the stupid column | 15:43 |
| morgan | but admin can only set "ignore password expiry" | 15:43 |
| morgan | it also allows us to mostly drop the "extras" column need [i know we 'cant | 15:44 |
| morgan | '] | 15:44 |
| morgan | but it shifts keystone's internal use to real options we control | 15:44 |
| morgan | and validate | 15:44 |
| morgan | lbragstad: thankfully it should be a small amount of code | 15:45 |
| *** jerrygb has joined #openstack-keystone | 15:45 | |
| rderose | morgan: nice | 15:45 |
| morgan | rderose: told you i'd have the code ready for you ;) | 15:45 |
| morgan | rderose: please revew the current one posted | 15:45 |
| lbragstad | morgan can anything be stored there? | 15:45 |
| morgan | lbragstad: no, just the ones we specifically define, hence the 'extra' column would stick around | 15:46 |
| rderose | morgan: will do, and yes you did ;) | 15:46 |
| morgan | lbragstad: but anything internal to keystone could be ecivted from extras | 15:46 |
| lbragstad | morgan ok - so this option_value column is going to have some sort of whitelist that we maintain? | 15:46 |
| morgan | lbragstad: not a "white list" a specific definition in code of "options" keystone cares about | 15:46 |
| rderose | morgan: what about the lockout_ignore_user_ids? | 15:46 |
| morgan | rderose: running unit tests now | 15:47 |
| rderose | morgan: shall we kill 2 birds with 1 stone? | 15:47 |
| rderose | morgan: cool | 15:47 |
| morgan | rderose: as soon as those pass, next review being pushed | 15:47 |
| *** jerrygb__ has quit IRC | 15:47 | |
| morgan | rderose: i did it as 2 reviews because it was different concerns | 15:47 |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS https://review.openstack.org/403898 | 15:47 |
| morgan | lbragstad: if it is something like ignore_password_expiry or ignore_password_lockout or default_project_id, etc | 15:47 |
| morgan | lbragstad: we have an option for it. | 15:48 |
| morgan | lbragstad: if it is some random value the deployer sets... we let it fall into extras | 15:48 |
| lbragstad | ah | 15:48 |
| morgan | lbragstad: last of all, we can also start a list on the user object, owner_can_set or some such | 15:48 |
| morgan | that lets the user set some values | 15:48 |
| morgan | aka, with update_user. vs locked to admin only | 15:48 |
| morgan | or via another API | 15:49 |
| morgan | default_project_id being a classic example | 15:49 |
| morgan | lbragstad: we could replicate the pattern for domains, projects, etc (as we would need to) for things like per-domain-PCI-DSS-enforcement | 15:50 |
| *** chris_hultin|AWA is now known as chris_hultin | 15:50 | |
| lbragstad | morgan would the list of things a user can set change across deployments? | 15:51 |
| lbragstad | would that be something a deployer sets somehow? | 15:51 |
| morgan | lbragstad: no. these would be options *we* have defined. | 15:51 |
| morgan | as safe, if the deployer wants to block users from updating these items, they would block access to the API | 15:51 |
| lbragstad | that feels policy related | 15:52 |
| morgan | exactly | 15:52 |
| morgan | policy not config | 15:52 |
| morgan | but it would be specifically defined things we have outlined | 15:52 |
| morgan | it would be either "you can set these" or "403" | 15:52 |
| * morgan pushes for opinionated things | 15:52 | |
| morgan | so deployments are more consistent | 15:52 |
| lbragstad | yeah - i agree with the consistency part | 15:53 |
| morgan | not removing "options" from deployers, but being less "you can tweak every possible little thing" | 15:53 |
| lbragstad | just thinking that the real thing we enabling here is to achieve better policy | 15:54 |
| lbragstad | and we'll be doing that in code | 15:54 |
| morgan | :) | 15:54 |
| morgan | lbragstad: it's two-fold | 15:55 |
| morgan | lbragstad: it's to make sure our options are more flexible. we don't need a DB Schema change every new option for user(s) or other things | 15:55 |
| *** jose-phillips has joined #openstack-keystone | 15:55 | |
| morgan | when it's legitimately an "option" | 15:55 |
| morgan | and 2) better policy | 15:55 |
| morgan | if it's legitimately a per-user/per-project/per-domain config | 15:55 |
| lbragstad | are we going to run into problems with policy here and policy there? | 15:56 |
| morgan | and it's not going to be used for *every* thing | 15:56 |
| morgan | like enabled | 15:56 |
| morgan | doubtful | 15:56 |
| morgan | i think it'll just be a "user-options" api | 15:56 |
| morgan | either set via update_user or via user-options | 15:56 |
| morgan | (ideally the latter) | 15:57 |
| morgan | should be super straightforward policy wise. | 15:57 |
| morgan | rderose: doh, had a typo, starting run again for tests. | 15:57 |
| rderose | :) | 15:57 |
| morgan | rderose: have two bugs to toss on the pile to fix if we can | 15:58 |
| morgan | so many warnings when running tests | 15:58 |
| morgan | in pycadf and... oslo-something | 15:58 |
| morgan | see if we can smash those quickly | 15:58 |
| rderose | nice | 15:58 |
| morgan | then back to trying to get MFA rules API built | 15:58 |
| morgan | since the rest of the code is proposed, just not the API / controller bits | 15:58 |
| morgan | rderose: i had to do a little magic on the User object with @property to make the not-null boolean happy | 15:59 |
| morgan | rderose: and it worked well since i wanted to loop in security_compliance in the user property (on the model) as well | 15:59 |
| rderose | morgan: okay (magic makes me nervous) | 15:59 |
| morgan | rderose: it just forces bool() | 15:59 |
| rderose | okay | 16:00 |
| morgan | instead of allowing None in .settr and such | 16:00 |
| rderose | I see | 16:00 |
| morgan | for some reason SQLite3 was ignoring server_default | 16:00 |
| morgan | so every update was failing | 16:00 |
| morgan | solution: force bool on get/set with @property | 16:00 |
| morgan | bonus, if conf.security_compliance.... is set,and the user_id is in the list | 16:00 |
| rderose | you are defaulting to false right? | 16:00 |
| morgan | override to true | 16:01 |
| morgan | yes, defualt to false | 16:01 |
| rderose | cool | 16:01 |
| morgan | for both | 16:01 |
| morgan | https://www.irccloud.com/pastebin/uMmf07Ra/ | 16:01 |
| morgan | https://www.irccloud.com/pastebin/FAou2rW4/ | 16:01 |
| morgan | ^ as examples | 16:01 |
| *** nklenke has joined #openstack-keystone | 16:02 | |
| morgan | so the tests that need to be added: 1) did the conf. migration to the db work | 16:02 |
| morgan | and 2) a test to explicitly set those values | 16:02 |
| morgan | pretty straight forward | 16:03 |
| morgan | and that will cover the new code | 16:03 |
| rderose | morgan: gotcha | 16:04 |
| rderose | morgan: so when you return ignore_password_lockout it calls the setter lockout_ignore() | 16:05 |
| morgan | it's a typo | 16:05 |
| morgan | i just fixed that | 16:05 |
| morgan | ;) | 16:05 |
| *** adrian_otto has joined #openstack-keystone | 16:05 | |
| rderose | :) | 16:05 |
| morgan | that was the typo (the copy/paste) was before i fixed those | 16:05 |
| *** voelzmo has quit IRC | 16:07 | |
| *** spotz is now known as spotz_zzz | 16:08 | |
| *** jperry has joined #openstack-keystone | 16:09 | |
| *** spotz_zzz is now known as spotz | 16:09 | |
| morgan | lbragstad: our unit tests have gotten slow again =/ | 16:10 |
| morgan | lbragstad: 800-1200sec to run | 16:10 |
| * lbragstad pages dstanek | 16:10 | |
| *** pcaruana has quit IRC | 16:13 | |
| dstanek | yo | 16:17 |
| *** mvk has quit IRC | 16:18 | |
| *** jose-phillips has quit IRC | 16:18 | |
| morgan | dstanek: just unit tests have gotten slow again | 16:19 |
| dstanek | morgan: ah | 16:19 |
| morgan | i think we'r eupwards of 800s in gate and locally also sloooow | 16:19 |
| dstanek | i'll go ahead and fix that :-) | 16:19 |
| morgan | haha | 16:19 |
| morgan | that was lbragstad pinging you, i was just commenting :P | 16:20 |
| lbragstad | dstanek our unit tests need more go-go | 16:20 |
| lbragstad | :) | 16:21 |
| *** nklenke has quit IRC | 16:21 | |
| *** diazjf has joined #openstack-keystone | 16:25 | |
| dstanek | lbragstad: i'll add a pomodoro or two tomorrow to start to fix | 16:26 |
| lbragstad | morgan did you have another patch set coming for https://review.openstack.org/#/c/403916/31 ? | 16:26 |
| lbragstad | dstanek that'd be a good thing to do as a group, too | 16:27 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone: Deprecate `lockout_ignored_user_ids` conf option https://review.openstack.org/424220 | 16:27 |
| morgan | rderose: ^ | 16:27 |
| morgan | lbragstad: yes it will be rebased on ^ provided no issues with the lockout_ignored patch | 16:28 |
| lbragstad | rderose do you happen to have anything locally for https://bugs.launchpad.net/keystone/+bug/1501032 ? | 16:29 |
| openstack | Launchpad bug 1501032 in OpenStack Identity (keystone) "incorrect method list is returned when scoping tokens with federation" [Low,Triaged] - Assigned to Ron De Rose (ronald-de-rose) | 16:29 |
| lbragstad | dstanek do you happen to have anything locally for https://bugs.launchpad.net/keystone/+bug/1180136 ? | 16:30 |
| openstack | Launchpad bug 1180136 in OpenStack Identity (keystone) "Dependency injection framework is constructing the object first and then injecting the dependency which is incorrect" [Wishlist,Triaged] - Assigned to David Stanek (dstanek) | 16:30 |
| rderose | morgan: on it! | 16:30 |
| rderose | lbragstad: no, I don't | 16:30 |
| morgan | brb | 16:31 |
| lbragstad | rderose do you mind if I unassign in case anyone else wants to pick it up? | 16:31 |
| rderose | lbragstad: I'd prefer to keep that one as it's related to dropping federated tokens; hoping to starting on it this week | 16:32 |
| *** david-lyle has joined #openstack-keystone | 16:32 | |
| lbragstad | rderose ok - sounds good, just double checking | 16:32 |
| dstanek | lbragstad: yeah, i think i still have a handful of patches | 16:32 |
| * morgan is back | 16:32 | |
| lbragstad | dstanek cool - i'll keep that one as is then | 16:32 |
| *** diazjf has quit IRC | 16:33 | |
| dstanek | lbragstad: i just updated it | 16:33 |
| morgan | rderose: easy enough to respin to local-user | 16:33 |
| lbragstad | dstanek sweet - thanks! | 16:34 |
| morgan | rderose: then the user object would return false for any non-local users? | 16:34 |
| rderose | morgan: yep, exactly | 16:34 |
| morgan | fair enough, long term i expect it to just move to the options table | 16:35 |
| rderose | morgan: as PCI is mostly only specific to local users | 16:35 |
| lbragstad | stevemar breton do we still have work to do for this one? https://bugs.launchpad.net/python-keystoneclient/+bug/1520244 | 16:35 |
| openstack | Launchpad bug 1520244 in python-keystoneclient "flag "truncated" in responses to list operations is not supported" [Medium,Triaged] - Assigned to Boris Bobrov (bbobrov) | 16:35 |
| morgan | which wont differentiate local vs remote user, but may only be set by the local user | 16:35 |
| *** Jack_V has joined #openstack-keystone | 16:35 | |
| morgan | ok i can respin the two patches for that | 16:36 |
| *** nklenke has joined #openstack-keystone | 16:36 | |
| rderose | morgan: cool | 16:36 |
| morgan | and .settr will just drop the value if not user.localuser | 16:36 |
| morgan | right? | 16:36 |
| rderose | morgan: yeah, and in an options table that would totally make sense | 16:36 |
| rderose | morgan: yes | 16:36 |
| *** Jack_I has quit IRC | 16:38 | |
| morgan | hmm | 16:39 |
| morgan | so. | 16:39 |
| morgan | this seems broken | 16:39 |
| rderose | morgan: how so? | 16:39 |
| morgan | rderose: the settr for both domain_id and now password_expiry will cause issues for non-local users | 16:39 |
| morgan | if you call .settr it will create the localuser entry | 16:40 |
| morgan | which is... broken? | 16:40 |
| rderose | if not self.local_user: | 16:40 |
| rderose | check first | 16:40 |
| morgan | right. | 16:40 |
| morgan | so if not locla user | 16:40 |
| morgan | aka non-local user | 16:40 |
| morgan | create it | 16:40 |
| morgan | non-locla user shouldn't have localuser() ? | 16:40 |
| morgan | right? | 16:40 |
| morgan | or should we have both elements? | 16:41 |
| rderose | correct | 16:41 |
| morgan | then we create it and the use rhas both | 16:41 |
| rderose | no, you should have one or the other | 16:41 |
| morgan | yeah this is broken | 16:41 |
| morgan | if you set the ignore_password_expiry, or domain_id. | 16:41 |
| morgan | you create local_user | 16:41 |
| morgan | and you have both | 16:41 |
| rderose | either local or ldap (nonlocal) not both | 16:41 |
| morgan | also domain_id should be immutable attribute* | 16:42 |
| morgan | but that aside | 16:42 |
| morgan | this current code does not enforce what you just asserted | 16:42 |
| *** hoonetorg has joined #openstack-keystone | 16:42 | |
| morgan | it is possible (esp. with cases like ignore_password_expiry, which should be settable at any point) | 16:42 |
| morgan | to end up with both local and non-local user objects | 16:43 |
| morgan | for a given user | 16:43 |
| morgan | domian_id shouldn't ever be set outside of creation | 16:43 |
| morgan | so it should be "ok" | 16:43 |
| morgan | also... we shouldn't allow domain_id to be set if it is already set | 16:43 |
| rderose | hmm... right, that's true | 16:43 |
| morgan | we need more code in here | 16:43 |
| rderose | morgan: domain_id is changing | 16:43 |
| morgan | god no. | 16:43 |
| morgan | do not *ever* allow someone to set domain_id | 16:44 |
| rderose | morgan: https://review.openstack.org/#/c/409874/46/keystone/identity/backends/sql_model.py | 16:44 |
| morgan | that is a massive security risk | 16:44 |
| rderose | morgan: moving domain_id up to the user table | 16:44 |
| rderose | morgan: not changing the value | 16:44 |
| morgan | thats fine | 16:44 |
| morgan | we still need to make it read-only | 16:44 |
| morgan | as it sits... crap this is a security bug =/ | 16:44 |
| morgan | sigh | 16:44 |
| rderose | morgan: currently, you can change it via the API | 16:44 |
| rderose | (I think) | 16:44 |
| rderose | pretty sure | 16:44 |
| *** diazjf has joined #openstack-keystone | 16:44 | |
| morgan | previously we made that impossible | 16:44 |
| morgan | that is a massive regression if we can now | 16:45 |
| rderose | morgan: really? | 16:45 |
| dstanek | rderose: that's what i was saying last week. i don't think you can | 16:45 |
| morgan | and... an OSSA | 16:45 |
| *** hoonetorg has quit IRC | 16:45 | |
| dstanek | i shouldn't be able to put myself of anyone else in a domain that i don't own | 16:45 |
| rderose | morgan dstanek: json schema validation | 16:45 |
| morgan | domain needs to be immutable | 16:45 |
| rderose | dstanek: where is that enforced? | 16:45 |
| morgan | not in json schema, but the whole way down | 16:45 |
| morgan | it used to be enforced either in the manager or the controller | 16:46 |
| morgan | but it really should be in the manager | 16:46 |
| dstanek | rderose: i'm going to guess in the update_* methods in the manager or controller | 16:46 |
| dstanek | morgan: ++ to manager | 16:46 |
| rderose | dstanek: I'm pretty sure not, but I'll check | 16:46 |
| morgan | https://www.irccloud.com/pastebin/hO4nrdVA/ | 16:47 |
| morgan | we need to remove that code now | 16:47 |
| morgan | since Ocata | 16:47 |
| rderose | morgan: dstanek: https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L979 | 16:47 |
| rderose | found it | 16:47 |
| *** hoonetorg has joined #openstack-keystone | 16:47 | |
| morgan | so in short, manager will (in a few minutes) assert [i'll propose the fix] that you can't change domain_ids | 16:47 |
| morgan | that is a *huge* security issue we've been fighting these for a while | 16:48 |
| rderose | looks like is allowed, but tagged to be removed in O | 16:48 |
| *** adrian_otto has quit IRC | 16:48 | |
| rderose | morgan: ++ | 16:49 |
| morgan | anyway... so | 16:50 |
| morgan | the domain_id being on localuser with the hybrid property was a newton code thing? | 16:50 |
| morgan | if so, we need a backport to fix it so we don't create localuser where it's not expected | 16:50 |
| *** stingaci has joined #openstack-keystone | 16:50 | |
| morgan | i'm going to say lets not shove these options on the local user for headache reasons | 16:51 |
| morgan | i don't think i can easily control creation of local vs nonlocal here | 16:51 |
| *** phalmos has joined #openstack-keystone | 16:51 | |
| morgan | how am i supposed to know if local user should be created or not... | 16:51 |
| morgan | similar for domain_id. | 16:51 |
| morgan | how do we know what item should be created when the user object is created? | 16:52 |
| rderose | morgan: domain_id was a newton thing, but a local_user wouldn't be created for a nonlocal_user here: | 16:52 |
| rderose | https://github.com/openstack/keystone/blob/master/keystone/identity/shadow_backends/sql.py#L94 | 16:52 |
| morgan | rderose: hmm. | 16:53 |
| rderose | morgan: shadow users creates nonlocal and federated users | 16:53 |
| morgan | rderose: maybe i should just create an option(s) table now like the MFA table... | 16:53 |
| morgan | =ugh i hate that even more | 16:54 |
| rderose | morgan: :) | 16:54 |
| morgan | too much moving bits for this late | 16:54 |
| rderose | morgan: options table would be great, but yeah, late in the hour for that kind of change | 16:54 |
| *** stingaci has quit IRC | 16:55 | |
| morgan | so issue is | 16:55 |
| morgan | i need to strip the values in the non-locla user code path as well? | 16:55 |
| morgan | oooor.... | 16:55 |
| morgan | but... i can't control update in the model | 16:55 |
| morgan | i don't think we can move this to non-local user atm =/ | 16:56 |
| morgan | erm... localuser | 16:56 |
| rderose | morgan: rather than deprecate ignore users now, why not just wait for the options table? | 16:56 |
| morgan | w/e | 16:56 |
| morgan | i worry about lumping this functionality into the config and encoding the behavior more | 16:56 |
| morgan | 1 cycle, not a lot of use | 16:56 |
| morgan | 2 cycles, things tend to get used | 16:56 |
| *** adrian_otto has joined #openstack-keystone | 16:57 | |
| morgan | and people start leaning on it | 16:57 |
| rderose | morgan: true, it's not going to be hard to deprecate and migrate | 16:57 |
| *** david-lyle_ has joined #openstack-keystone | 16:57 | |
| rderose | morgan: and the reality of many operators implementing this early is low | 16:57 |
| rderose | morgan: especially change password on first use | 16:57 |
| rderose | morgan: the options table is by far the better option | 16:58 |
| rderose | if you move to local_user, then we'll have to migrate | 16:58 |
| rderose | to the options table later | 16:58 |
| rderose | anyway... | 16:59 |
| rderose | be back shortly | 16:59 |
| *** ayoung is now known as ayoung-food | 16:59 | |
| morgan | rderose: it's about the same regardless. | 17:00 |
| morgan | rderose: but more important is when all the tools out there start using the options (puppet, ansible, etc) | 17:01 |
| morgan | the longer it is around the harder it is to say "no don't do that" | 17:01 |
| morgan | (likewise I could argue we could hold the change-on-first-use code until Pilke) =) | 17:01 |
| *** david-lyle_ has quit IRC | 17:03 | |
| *** jose-phillips has joined #openstack-keystone | 17:07 | |
| *** tesseract has quit IRC | 17:15 | |
| *** nicolasbock has quit IRC | 17:19 | |
| *** mvk has joined #openstack-keystone | 17:26 | |
| *** nicolasbock has joined #openstack-keystone | 17:27 | |
| *** nicolasbock has quit IRC | 17:40 | |
| * morgan pokes stevemar | 17:41 | |
| *** thiagolib has joined #openstack-keystone | 17:46 | |
| nicodemus_ | I'm having trouble with the following code snippet: http://paste.openstack.org/show/596106/ | 17:49 |
| morgan | nicodemus_: it grabs the config object from keystone, then it forces config to load (import) the auth method handlers | 17:50 |
| nicodemus_ | auth_plugin is empty, and I can't create a session. Any pointers / suggestions ? I'm stuck :( | 17:50 |
| morgan | however... | 17:50 |
| morgan | oh ait | 17:50 |
| morgan | wait* | 17:50 |
| morgan | sorry that is for keystonemiddleware | 17:51 |
| morgan | you need to provide the auth plugin information in your [keystone_authtoken] config group | 17:51 |
| morgan | in the config file | 17:51 |
| morgan | if you look, in say, nova, that is what that is for | 17:51 |
| morgan | if you're trying to create a session for your own application to use | 17:51 |
| morgan | this wont work for you since this is the mechanism used for the middleware in front of nova/neutron/etc | 17:52 |
| nicodemus_ | I do have the required parameters in the config file, and on keystone logs I see that it grants access... | 17:52 |
| nicodemus_ | oooh... it won't work? | 17:52 |
| nicodemus_ | is there an example somewhere on how to implement keystone_client? I need to ask keystone for a certain project details (project_id comes in the headers) | 17:54 |
| *** browne has joined #openstack-keystone | 17:54 | |
| *** nicolasbock has joined #openstack-keystone | 17:55 | |
| morgan | hold on there is a good "how to use sessions": doc jamielennox wrote | 17:56 |
| *** david-lyle_ has joined #openstack-keystone | 17:56 | |
| knikolla | nicodemus_: http://docs.openstack.org/developer/keystoneauth/using-sessions.html#sessions-for-users | 17:56 |
| *** david-lyle_ has quit IRC | 17:56 | |
| *** david-lyle_ has joined #openstack-keystone | 17:57 | |
| knikolla | there's a keystoneclient call called validate_token, that will give you everything about the token you query | 17:57 |
| morgan | nicodemus_: http://docs.openstack.org/developer/keystoneauth/using-sessions.html | 17:57 |
| morgan | knikolla: we need to do a 301 for ksc to http://docs.openstack.org/developer/keystoneauth/using-sessions.html now. | 17:57 |
| nicodemus_ | knikolla, morgan, wonderful! I'll give that a try | 17:57 |
| nicodemus_ | thanks a lot! | 17:57 |
| morgan | nicodemus_: :) | 17:57 |
| * morgan lays a PTL trap for stevemar and hides waiting for it to spring. | 17:58 | |
| knikolla | morgan: there's a similar page on ksc, but yeah, a redirect would be better. | 17:59 |
| morgan | well ksc hasn't dropped session yt | 17:59 |
| morgan | yet* | 17:59 |
| morgan | soooooo | 17:59 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users https://review.openstack.org/414720 | 18:01 |
| *** diazjf has quit IRC | 18:04 | |
| *** david-lyle has quit IRC | 18:05 | |
| *** david-lyle_ is now known as david-lyle | 18:05 | |
| nicodemus_ | morgan, knikolla, the example worked. Thanks again! | 18:10 |
| morgan | nicodemus_: :) | 18:10 |
| *** ravelar has quit IRC | 18:10 | |
| *** ravelar has joined #openstack-keystone | 18:11 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users https://review.openstack.org/414720 | 18:12 |
| *** pnavarro has quit IRC | 18:15 | |
| *** spotz is now known as spotz_zzz | 18:22 | |
| *** spotz_zzz is now known as spotz | 18:26 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone: Add domain_id to the user table https://review.openstack.org/409874 | 18:36 |
| *** ravelar has quit IRC | 18:39 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone: Add domain_id to the user table https://review.openstack.org/409874 | 18:40 |
| *** ayoung-food is now known as ayoung | 18:45 | |
| *** catintheroof has joined #openstack-keystone | 18:45 | |
| *** catinthe_ has quit IRC | 18:47 | |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS https://review.openstack.org/403898 | 18:50 |
| *** kukacz has quit IRC | 19:03 | |
| *** catinthe_ has joined #openstack-keystone | 19:03 | |
| *** catintheroof has quit IRC | 19:06 | |
| *** voelzmo has joined #openstack-keystone | 19:15 | |
| *** ravelar1 has joined #openstack-keystone | 19:22 | |
| *** knikolla has quit IRC | 19:23 | |
| *** knikolla has joined #openstack-keystone | 19:23 | |
| *** knikolla has quit IRC | 19:23 | |
| *** ravelar15 has joined #openstack-keystone | 19:23 | |
| lbragstad | do we have any LDAP experts on staff today that would be interested in looking at https://bugs.launchpad.net/keystone/+bug/1658641 ? | 19:24 |
| openstack | Launchpad bug 1658641 in OpenStack Identity (keystone) "Moving/disabling LDAP users break Keystone queries depending on role ID" [Undecided,New] | 19:24 |
| *** knikolla has joined #openstack-keystone | 19:24 | |
| *** knikolla has quit IRC | 19:24 | |
| *** knikolla has joined #openstack-keystone | 19:24 | |
| *** knikolla has joined #openstack-keystone | 19:25 | |
| *** knikolla has quit IRC | 19:25 | |
| *** knikolla has joined #openstack-keystone | 19:25 | |
| *** knikolla has quit IRC | 19:25 | |
| *** ravelar1 has quit IRC | 19:27 | |
| *** ravelar15 is now known as ravelar1 | 19:27 | |
| *** Marcellin__ has joined #openstack-keystone | 19:32 | |
| *** diazjf has joined #openstack-keystone | 19:39 | |
| *** knikolla_ has joined #openstack-keystone | 19:45 | |
| knikolla_ | irc bouncers are great, until they stop working | 19:45 |
| gagehugo | ^ | 19:46 |
| *** jaosorior has quit IRC | 19:50 | |
| *** voelzmo has quit IRC | 19:51 | |
| *** jose-phillips has quit IRC | 20:10 | |
| openstackgerrit | Samuel Pilla proposed openstack/python-keystoneclient: Allow Multiple Filters of the Same Key https://review.openstack.org/423339 | 20:13 |
| *** MasterOfBugs has joined #openstack-keystone | 20:16 | |
| *** stingaci has joined #openstack-keystone | 20:20 | |
| morgan | lbragstad: don't move users and expect it to work in LDAP | 20:20 |
| morgan | lbragstad: moving a user in the Ldap tree breaks the DN | 20:21 |
| morgan | keystone cannot know about this | 20:21 |
| morgan | since keystone is unable to understand that the DN it's aware of suddenly changed | 20:21 |
| morgan | the user will be broekn | 20:21 |
| morgan | full stop | 20:21 |
| morgan | if you are using a system keystone is not managing (aka LDAP) and you can't access the user'd DN/object, keystone wont know what to do anymore | 20:22 |
| morgan | this is expected | 20:23 |
| lbragstad | morgan ok - that's kinda what I figured | 20:23 |
| morgan | so, the simple answer is "no" | 20:23 |
| lbragstad | morgan do you know if we document that anywhere? | 20:23 |
| morgan | the long answer is "noooooooooooooooooooooooooooooooooooo | 20:23 |
| morgan | the really long answer is: In theory you could make keystone look in both places for the user object | 20:23 |
| morgan | but we don't really test that. it's getting into complex filters and multiple tree lookups and/or referral chasing | 20:24 |
| morgan | no, not explicitly documented | 20:24 |
| morgan | but any application that uses LDAP as a source of Identity (or anything) would break in a similar | 20:24 |
| morgan | way | 20:24 |
| lbragstad | morgan I can update the bug report and link to this conversation | 20:25 |
| morgan | the same question is similar to: So I moved the row for <user> into another table in the database, why are my role assignments broken | 20:25 |
| openstackgerrit | Samuel Pilla proposed openstack/python-keystoneclient: Allow Multiple Filters of the Same Key https://review.openstack.org/423339 | 20:25 |
| morgan | there is no strict FK-like enforcement between subsystems in keystone. because keystone may not manage things. | 20:26 |
| morgan | zzzeek: ping - have a SQL-A question for you | 20:26 |
| morgan | zzzeek: if you are around. I just don't know the answer i can bug other folks if you're not here | 20:26 |
| morgan | zzzeek: but in short - i have a list of items that need to be correlated to a one-to-many (user->soft options defined in code, values stored in a new table) relationship. How would I store the options programatically in the table assuming a unique constraint of (User_id, Option_id)? | 20:27 |
| morgan | based upon how keystone is using the User object now? | 20:28 |
| morgan | rderose: ^ cc (i almost have the option table code done, if we care to examine it as an option to go forward) | 20:28 |
| *** stingaci has quit IRC | 20:45 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users https://review.openstack.org/414720 | 20:47 |
| *** nklenke has quit IRC | 20:50 | |
| *** esp_ has joined #openstack-keystone | 21:02 | |
| *** stingaci has joined #openstack-keystone | 21:04 | |
| *** adriant has joined #openstack-keystone | 21:06 | |
| *** raildo has quit IRC | 21:07 | |
| *** stingaci has quit IRC | 21:08 | |
| rderose | morgan: cool | 21:11 |
| *** jerrygb has quit IRC | 21:12 | |
| morgan | rderose: just treying to figure out how to modify .from_dict | 21:13 |
| morgan | to work w/ the options | 21:13 |
| rderose | morgan: btw, I'm not following your questions to zzzeek, do you simply want to create a 1-to-many relationship with that table? | 21:13 |
| rderose | morgan: and I assume get_user API would return the option list, correct? | 21:14 |
| rderose | morgan: whereas list_user api, would not return the option list | 21:15 |
| morgan | basically, i am trying to load the options into the user_ref | 21:16 |
| morgan | when loaded from the db | 21:16 |
| rderose | morgan: federated_users is an example of 1-to-many with User: | 21:16 |
| rderose | https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql_model.py#L40 | 21:16 |
| morgan | and extract the values form the ref and store into the new table when the name/key matches | 21:16 |
| rderose | morgan: np, create the relationship and it will automatically get loaded | 21:17 |
| morgan | so the idea is you'd have user_ref['ignore_password_expiry'] and that would map over to [user_options_table][user_id=user_id][option_id=1][option_value=True] | 21:17 |
| morgan | the concern i have is how to add it to the user_options_table | 21:17 |
| rderose | morgan: oh | 21:17 |
| morgan | yeah. see, more complex. | 21:18 |
| rderose | hmm... | 21:18 |
| morgan | and how to cover deletion of the options, and finally how to ensure it is an insert or update | 21:18 |
| rderose | ug | 21:18 |
| rderose | :) | 21:18 |
| rderose | well, you could keep it as a list and forget about this craziness :) | 21:19 |
| morgan | because we don't want to create wonky-new-api thing for storing these options. i want user updates to be atomic still | 21:19 |
| rderose | and it would just be an array passed back in json | 21:19 |
| rderose | hmm... | 21:19 |
| morgan | i could make it json in the table like the MFA rules | 21:19 |
| morgan | but it feels weird to do so. | 21:19 |
| morgan | the plan is to make it so explicitly setting the option to None deletes the option from the db | 21:20 |
| morgan | or the plan was | 21:20 |
| rderose | morgan: it doesn't feel so weird to me, as these are optional values (I think) | 21:20 |
| morgan | as a json blob, deleting it is near impossible | 21:20 |
| morgan | i guess we could use the same mechanism | 21:20 |
| morgan | option: None -> delete | 21:21 |
| morgan | trying to use relational dbs as relational things vs. just a way to store values elsewhere | 21:21 |
| morgan | if that is the case, we might as well just wedge the options in a column on user | 21:21 |
| morgan | a separate table is kind of... overkill | 21:21 |
| rderose | right | 21:21 |
| morgan | the MFA rules are different because they have additional metadata | 21:22 |
| morgan | such as "disable all MFA rules" | 21:22 |
| morgan | etc | 21:22 |
| morgan | which is tied to those rules | 21:22 |
| morgan | vs say an option on the user | 21:22 |
| morgan | i guess i could revisit and just make MFA disabled a new option class thing | 21:22 |
| zzzeek | morgan: sup | 21:22 |
| morgan | and then store all the options on the main user table | 21:22 |
| morgan | zzzeek: hey man | 21:22 |
| morgan | zzzeek: so... trying to work through a design where we define options for resources in code, aka options like "ignore pci-dss things" | 21:23 |
| morgan | so a user can optionally be removed from the enforcement (vs. encoding that into the keystone config... which is wrong to list uuids there) | 21:23 |
| morgan | the thought i had was for each of these elements, if they are set, they are added as a row with a unique constraint of "option_id/name" and "user_id" | 21:24 |
| morgan | in a table, and use nice RDBMS models to load the list of options set | 21:24 |
| rderose | hmm... I still sort of like the user => user_option => option tables. and we could dynamically create the user attributes in the options. | 21:24 |
| morgan | the only issue i'm running into is how to do so cleanly with the from_dict/to_dict magic in keystone | 21:24 |
| rderose | but the backend would hold the data in a new table | 21:25 |
| morgan | rderose: if it ends up being a single row and column per user... does it belong in another table? | 21:25 |
| morgan | zzzeek: am i crazy? | 21:25 |
| morgan | zzzeek: should i just conceed and do the json-blob store in a column and load the options that way | 21:26 |
| zzzeek | morgan: where is the crazy part here, i dont think i know all the pieces to this. store key/value in a table and represent as dict in python? that's not a big dea | 21:26 |
| zzzeek | deal | 21:26 |
| zzzeek | if those rows somehow interact with some other query then that may or may not be difficult | 21:26 |
| *** ravelar1 is now known as ravelar | 21:26 | |
| *** jose-phillips has joined #openstack-keystone | 21:27 | |
| morgan | the only issue i'm running into is how to store it where we do like an insert-or-update | 21:27 |
| morgan | if the option is already set for the user | 21:27 |
| rderose | option (id:1, name:ignore_password_expiry, default:false) | 21:27 |
| rderose | user_option (user_id: 1, option_id: 1, value: true) | 21:27 |
| morgan | here let me push the example code to gerrit so you can see what i've done so far. | 21:27 |
| morgan | and tell me how crazy/not crazy i am. | 21:27 |
| zzzeek | morgan: ok....are you referring to concurrent requests all trying to add the same user? unique constraint? | 21:27 |
| morgan | should be atomic to store the data for a user | 21:28 |
| morgan | but in theory you could have multiple requests (it is keystone) to update the values at the same time | 21:28 |
| morgan | that change different opts | 21:28 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone: WIP - SoftOptions Table UserOpts https://review.openstack.org/424334 | 21:28 |
| zzzeek | ok, so one user has multiple rows in this table ? | 21:28 |
| morgan | that would be the idea | 21:28 |
| morgan | each option is a row, if it is set | 21:29 |
| zzzeek | and..you want serilizable update to all the rows at once? | 21:29 |
| morgan | (user_id)(option_id)(option_value) | 21:29 |
| morgan | i'm looking at loading/saving the values from the user_ref dict | 21:29 |
| morgan | it doesn't have to be "all at once" | 21:29 |
| morgan | ^ that wont pass CI, at all | 21:29 |
| morgan | but it is the basic "idea" I was working from | 21:29 |
| zzzeek | morgan: ok. so, in a usual ORM model, like User, you can refer to such a table with relationship, and map to a dicionary, this is ver common | 21:30 |
| zzzeek | there is then the association proxy that can pull in some related object | 21:30 |
| zzzeek | that pattern isn't hard | 21:30 |
| morgan | so where i am stumbling is extracting the option from the user_ref and shoving it into the new table | 21:30 |
| morgan | not all things are being extracted | 21:30 |
| morgan | if the option is not explicitly defined it still just falls into the horrible ."extras" json blob | 21:30 |
| zzzeek | morgan: "extracting" meaning.... migrating from an old schema to new ? | 21:31 |
| *** jerrygb has joined #openstack-keystone | 21:31 | |
| morgan | user_ref is a dict | 21:31 |
| *** diazjf has quit IRC | 21:31 | |
| morgan | and we do user.from_dicT(user_ref) | 21:31 |
| zzzeek | oh | 21:31 |
| morgan | when we store which makes SQL-A objects to shove into the DB backend | 21:31 |
| zzzeek | OK if you have pyhton dictionary, and you use the normal SQLAlchemy ORM dictionary pattern, you say, user.my_stuff = the_dict | 21:31 |
| *** jerrygb_ has joined #openstack-keystone | 21:32 | |
| zzzeek | morgan: the feature I'm referring to is here: https://docs.sqlalchemy.org/en/latest/orm/extensions/associationproxy.html#proxying-to-dictionary-based-collections | 21:33 |
| zzzeek | morgan: if you can see if that maps to your concept | 21:33 |
| morgan | one extra layer of abstraction | 21:34 |
| morgan | but yes | 21:34 |
| morgan | now i just need to do a little extra work to make sure we don't delete options not set | 21:35 |
| *** thorst_ has quit IRC | 21:35 | |
| morgan | because any option not explicitly passed has to remain the smae value (any option with a value explicitly set as None should be dropped/deleted from the backend) | 21:35 |
| *** thorst_ has joined #openstack-keystone | 21:35 | |
| *** jerrygb has quit IRC | 21:36 | |
| morgan | yep. i will just need to do an explicit load/reconciliation on the_dict before saving in an update case | 21:37 |
| *** jose-phillips has quit IRC | 21:39 | |
| *** thorst_ has quit IRC | 21:40 | |
| *** diazjf has joined #openstack-keystone | 21:41 | |
| *** jose-phillips has joined #openstack-keystone | 21:41 | |
| *** stingaci has joined #openstack-keystone | 21:42 | |
| *** Jack_V has quit IRC | 21:42 | |
| morgan | ahh this looks more like the Unqiue object recipe i need | 21:42 |
| *** nicodemus_ has quit IRC | 21:44 | |
| *** adrian_otto has quit IRC | 21:45 | |
| morgan | zzzeek: ok now i am confused... | 21:45 |
| morgan | zzzeek: what exactly is being said here: | 21:45 |
| morgan | One caveat with our example above is that because Keyword objects are created for each dictionary set operation, the example fails to maintain uniqueness for the Keyword objects on their string name, which is a typical requirement for a tagging scenario such as this one. For this use case the recipe UniqueObject, or a comparable creational strategy, is | 21:45 |
| morgan | recommended, which will apply a “lookup first, then create” strategy to the constructor of the Keyword class, so that an already existing Keyword is returned if the given name is already present. | 21:45 |
| *** adrian_otto has joined #openstack-keystone | 21:45 | |
| zzzeek | morgan: oh right. so, you are doing User -> Option ? | 21:46 |
| *** stingaci has quit IRC | 21:46 | |
| *** markvoelker has quit IRC | 21:47 | |
| morgan | yeah | 21:47 |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: Update endpoint api for optional region_id https://review.openstack.org/420085 | 21:47 |
| morgan | i mean, i can figure out how to muck with things to make it into a dict representation | 21:48 |
| zzzeek | morgan: OK are all the possible "options" in the database already ? | 21:48 |
| morgan | after the fact, but i also need to make sure all options that are currently set continue to exist | 21:48 |
| morgan | no | 21:48 |
| morgan | they wont be in the db | 21:48 |
| morgan | only in code | 21:48 |
| zzzeek | morgan: so if a user refers to option "foo" what is physically in the database that links to "foo" ? | 21:48 |
| zzzeek | integer id? GUID ? string ? | 21:48 |
| morgan | user_id and a option_id (defined in code) | 21:49 |
| morgan | if someone fubars/changes option_ids, the values are lost | 21:49 |
| morgan | i am trying my damnest to avoid needing to change the db schema or insert control rows for each option | 21:49 |
| morgan | so we can define an option for a resource without needing migrations each and every time | 21:50 |
| openstackgerrit | Kristi Nikolla proposed openstack/keystone: WIP: Remove LDAP delete logic and associated tests https://review.openstack.org/424344 | 21:50 |
| openstackgerrit | Samuel Pilla proposed openstack/python-keystoneclient: Allow Multiple Filters of the Same Key https://review.openstack.org/423339 | 21:50 |
| morgan | the FK to the User table in this case, will cascade delete if the user is deleted (sufficient) | 21:50 |
| zzzeek | morgan: option_id is a...string ? | 21:50 |
| morgan | was going to do it as an int | 21:51 |
| morgan | i could also do it as a String. | 21:51 |
| zzzeek | morgan: you're going to hardcode ints in the python ? | 21:51 |
| morgan | (for the option name) | 21:51 |
| morgan | basically, yes, the options will be set in python | 21:51 |
| zzzeek | morgan: usually an enumerated character thing is best for this kind of thing. say you make it a 2-character code. thats half the length of an integer | 21:51 |
| morgan | yeah i used to do it as a 4-character code | 21:52 |
| morgan | but same concept | 21:52 |
| morgan | 4cc (4-character-code) | 21:52 |
| zzzeek | morgan: also you wouldnt need the association proxy here since you are using a lookup | 21:52 |
| morgan | right. the only direct association is the user_id | 21:52 |
| morgan | and the uniqueness constraint is (user_id, 4cc) | 21:53 |
| morgan | or (2cc) | 21:53 |
| morgan | whatever length is used | 21:53 |
| morgan | i'll have a little extra logic to ensure user-options are only for user, eventually we will have domain options, project options, etc | 21:53 |
| morgan | each with their own table | 21:53 |
| morgan | because the options will be fundamentally different for each resource type | 21:54 |
| morgan | exAMPLE: a user may be opted out of passwor dexpiration | 21:54 |
| morgan | a domain may require all users not opted out to use password expiration | 21:54 |
| morgan | instead of the global options we have right now | 21:55 |
| morgan | where it is "everything is X" | 21:55 |
| zzzeek | morgan: so each option has a value also right? | 21:55 |
| morgan | across all of keystone (and thus, uuids of users are encoded in the keystone.config) | 21:55 |
| morgan | yes | 21:55 |
| zzzeek | morgan: ok so the rationale for a separate table vs. json string is...searching on them and/or joining in queries ? | 21:55 |
| morgan | to begin with options are mostly true/false | 21:55 |
| morgan | that was my thought, allowing a search for all users that do not have passwords that expire | 21:56 |
| zzzeek | yup | 21:56 |
| morgan | or all users in domain X that don't have password expire | 21:56 |
| morgan | not part of the implementation right now | 21:56 |
| morgan | but future proofing | 21:56 |
| morgan | because the json extra blob is just ugly/terrible/unfortunate | 21:56 |
| morgan | and i don't wnat to continue with that kind of "well you don't know unless you look at every user" pattern | 21:56 |
| morgan | esp. for options that affect the PCI-DSS compliance code | 21:56 |
| * morgan is trying for real(ish) architecture here. | 21:57 | |
| zzzeek | morgan: in the key/value area all the options are crappy | 21:58 |
| morgan | so the way i saw the table initially was: [auto_inc_pk][user_id (fk to user.id)][option_id/code/whatever for lookup][option value] | 21:58 |
| *** thorst_ has joined #openstack-keystone | 21:58 | |
| morgan | i could prob. drop the auto_inc_pk and just make the pk(user.id, code) | 21:59 |
| zzzeek | morgan: yeah that is mostly it, although you can make the PK the combination of (user_id, option_id) also | 21:59 |
| zzzeek | yep | 21:59 |
| morgan | yeah | 21:59 |
| morgan | that is prob. best bet | 21:59 |
| morgan | then the automagic mapping should just work | 21:59 |
| zzzeek | morgan: it's just....if you want other places to have FKs to that table, now they'd have (user_id, option_id) as the FK value too | 21:59 |
| morgan | nope | 21:59 |
| morgan | these tables should not ever need to be the FKs to that table | 22:00 |
| morgan | erm.. other tables should never need to FK to that table | 22:00 |
| morgan | if you're not looking it up via (in this case) User | 22:00 |
| morgan | you're doing it wrong | 22:00 |
| zzzeek | morgan: so...yeah, this is User.options = relationship(Option, collection_class=attribute_mapped_collection('option_id')) | 22:00 |
| morgan | ok cool | 22:00 |
| morgan | and then that just looks like a dict on user.options | 22:01 |
| morgan | when accessing/mucking with it | 22:01 |
| morgan | i'll work on some logic to make sure we don't do a whole-sale replace with each updat eon that | 22:01 |
| morgan | becuase if someone does update_user(user_id=blah, user_ref={'ignore_password': True}) it should only change the ignore_password option | 22:02 |
| morgan | not replace all options and now the user only has ignore_password | 22:02 |
| morgan | some options may be (long term) admin-only settable, so need to be careful on replacements. but i think i know how to approach that | 22:02 |
| *** thorst_ has quit IRC | 22:03 | |
| *** harlowja has quit IRC | 22:03 | |
| *** chris_hultin is now known as chris_hultin|AWA | 22:05 | |
| *** kukacz has joined #openstack-keystone | 22:05 | |
| *** jaugustine has quit IRC | 22:12 | |
| *** browne has quit IRC | 22:12 | |
| *** thorst_ has joined #openstack-keystone | 22:13 | |
| *** knikolla_ has quit IRC | 22:13 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users https://review.openstack.org/414720 | 22:15 |
| *** diazjf has quit IRC | 22:16 | |
| *** thorst_ has quit IRC | 22:22 | |
| morgan | zzzeek: so would i need a custom collection to ensure not replacing options that are not present in the dict (and/or deleting them)? | 22:23 |
| zzzeek | morgan: the dictionary implementation should handle that. e.g. if you set the dict to hvae keys a, b, c, that also means key 'd' was remoevd if it was there before | 22:24 |
| morgan | right i am looking for the opposite | 22:24 |
| morgan | if you set a, b, c, but not D, D is not removed | 22:24 |
| zzzeek | morgan: if you say, a.options['a'] = a, a.options['b'] = b, a.options['c'] = c, other keys are not removed | 22:25 |
| morgan | ahhh ok | 22:25 |
| zzzeek | morgan: if you OTOH say, a.options = {'a':a, 'b':b, 'c':c}, then that deletes any other keys | 22:25 |
| morgan | i'll be sure to do the former | 22:25 |
| zzzeek | so! you might say, a.options.update({'a': a, 'b':b, 'c':c}) | 22:25 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users https://review.openstack.org/414720 | 22:26 |
| morgan | hmm. erg. not sure if this is going to work "right".. but we'll try it :) | 22:26 |
| morgan | yeah, i will def. be doing the options['key'] = value model | 22:27 |
| morgan | in all cases. | 22:27 |
| morgan | and a option['a'] = None should null the option_value, right? | 22:27 |
| morgan | in the table | 22:27 |
| SamYaple | is there a way to know which series keystone is via an API call? as in, am i talking to keystone newton/10.y.z or ocata/11.y.z | 22:27 |
| morgan | or a .pop/explicit del should remove the option i take it then | 22:28 |
| *** edtubill has quit IRC | 22:35 | |
| morgan | SamYaple: you could look at the root /, we should give the version(s) there | 22:36 |
| lbragstad | sorrison o/ i'm attempting to put two and two together here and wonder if you're the author of this http://lists.openstack.org/pipermail/openstack-operators/2017-January/012470.html ? | 22:40 |
| SamYaple | morgan: thanks, will check | 22:43 |
| *** browne has joined #openstack-keystone | 22:48 | |
| *** thiagolib has quit IRC | 22:48 | |
| SamYaple | awesome morgan! i think thats perfect for what im looking for | 22:49 |
| *** chris_hultin|AWA is now known as chris_hultin | 22:52 | |
| *** spotz is now known as spotz_zzz | 22:54 | |
| zzzeek | morgan: that would make it NULL, yes | 22:55 |
| zzzeek | morgan: but leave it present | 22:55 |
| *** spotz_zzz is now known as spotz | 22:57 | |
| morgan | ok and a .pop/del should remove it | 22:57 |
| morgan | ? | 22:57 |
| morgan | or would that likewise NULL it? | 22:57 |
| zzzeek | morgan: removing the item means remove from the list, so if you have set up the "delete" cascade that would remove it | 22:58 |
| zzzeek | morgan: you'd want delete, delete-orphan on this one | 22:58 |
| morgan | yep | 22:59 |
| morgan | https://www.irccloud.com/pastebin/NvAAD97D/ | 22:59 |
| zzzeek | otherwise it owudl try to null out user_id and you'd get a constraint violation | 22:59 |
| morgan | ^ | 22:59 |
| morgan | or all,delete-orphan,delete ? | 22:59 |
| morgan | or just delete,delete-orphan | 23:00 |
| *** furface has joined #openstack-keystone | 23:00 | |
| *** adrian_otto has quit IRC | 23:00 | |
| *** jperry has quit IRC | 23:01 | |
| *** spotz is now known as spotz_zzz | 23:06 | |
| zzzeek | morgan: all, delete, delete-orphan usually | 23:08 |
| morgan | cool done thnx! | 23:10 |
| *** chris_hultin is now known as chris_hultin|AWA | 23:18 | |
| *** catinthe_ has quit IRC | 23:23 | |
| *** phalmos has quit IRC | 23:23 | |
| *** ravelar has quit IRC | 23:26 | |
| *** ravelar has joined #openstack-keystone | 23:27 | |
| *** harlowja has joined #openstack-keystone | 23:34 | |
| *** harlowja has quit IRC | 23:35 | |
| *** jose-phillips has quit IRC | 23:35 | |
| *** jose-phillips has joined #openstack-keystone | 23:37 | |
| *** dave-mccowan has quit IRC | 23:38 | |
| *** stingaci has joined #openstack-keystone | 23:40 | |
| morgan | uh.. | 23:44 |
| morgan | what the hell is up with D400 REQUIRING the first line of a file (comment) to end with a . | 23:44 |
| morgan | ?! | 23:44 |
| morgan | https://www.irccloud.com/pastebin/6P1lsdmY/ | 23:44 |
| morgan | ^^ REALLY?! | 23:45 |
| *** stingaci has quit IRC | 23:45 | |
| morgan | oh... nvm | 23:45 |
| morgan | wow that error is awful. | 23:45 |
| morgan | totally wrong error | 23:46 |
| *** harlowja has joined #openstack-keystone | 23:48 | |
| *** lamt has quit IRC | 23:56 | |
| *** edmondsw has quit IRC | 23:57 | |
| *** edmondsw has joined #openstack-keystone | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!