Monday, 2017-01-23

*** diazjf has joined #openstack-keystone00:03
*** thorst_ has joined #openstack-keystone00:03
*** jamielennox|away is now known as jamielennox00:05
*** voelzmo has joined #openstack-keystone00:06
*** thorst_ has quit IRC00:08
*** voelzmo has quit IRC00:11
*** stingaci has joined #openstack-keystone00:16
*** stingaci has quit IRC00:21
*** edmondsw has joined #openstack-keystone00:43
*** edmondsw has quit IRC00:48
*** stingaci has joined #openstack-keystone00:48
*** thorst_ has joined #openstack-keystone00:50
*** stingaci has quit IRC00:52
*** thorst_ has quit IRC00:53
*** hoangcx has joined #openstack-keystone00:54
*** diazjf has quit IRC00:55
*** nkinder has joined #openstack-keystone00:59
*** stingaci has joined #openstack-keystone01:05
*** stingaci has quit IRC01:09
*** liujiong has joined #openstack-keystone01:19
*** liujiong has quit IRC01:32
*** liujiong has joined #openstack-keystone01:33
*** g2[ATL] is now known as g201:36
*** stingaci has joined #openstack-keystone01:37
*** dikonoor has quit IRC01:39
*** stingaci has quit IRC01:41
*** thorst_ has joined #openstack-keystone01:55
*** thorst_ has quit IRC01:56
*** voelzmo has joined #openstack-keystone02:07
*** stingaci has joined #openstack-keystone02:09
*** voelzmo has quit IRC02:12
*** stingaci has quit IRC02:14
*** agrebennikov__ has joined #openstack-keystone02:18
*** agrebennikov_ has quit IRC02:20
*** jefrite has quit IRC02:20
*** jdennis has quit IRC02:24
*** stingaci has joined #openstack-keystone02:25
*** jdennis has joined #openstack-keystone02:25
*** jefrite has joined #openstack-keystone02:27
*** stingaci has quit IRC02:29
*** dave-mccowan has joined #openstack-keystone02:38
*** thorst_ has joined #openstack-keystone02:48
*** thorst_ has quit IRC02:48
*** jerrygb has joined #openstack-keystone02:55
*** stingaci has joined #openstack-keystone02:57
*** stingaci has quit IRC03:01
*** david-lyle has joined #openstack-keystone03:15
*** david-lyle has quit IRC03:21
*** stingaci has joined #openstack-keystone03:30
*** stingaci has quit IRC03:34
*** jefrite has quit IRC03:43
*** richm has quit IRC03:44
*** jefrite has joined #openstack-keystone03:49
*** dave-mccowan has quit IRC03:53
*** jefrite has quit IRC03:54
*** dikonoor has joined #openstack-keystone03:54
*** jerrygb has quit IRC04:03
*** dave-mccowan has joined #openstack-keystone04:04
*** stingaci has joined #openstack-keystone04:06
*** stingaci has quit IRC04:10
*** Dinesh_Bhor has joined #openstack-keystone04:13
*** nicolasbock has quit IRC04:14
*** stingaci has joined #openstack-keystone04:23
*** furface has quit IRC04:23
*** dikonoor has quit IRC04:26
*** stingaci has quit IRC04:27
*** dave-mccowan has quit IRC04:35
*** lamt has joined #openstack-keystone04:36
*** v1k0d3n has quit IRC04:44
*** v1k0d3n has joined #openstack-keystone04:44
*** thorst_ has joined #openstack-keystone04:49
*** agrebennikov__ has quit IRC04:53
*** thorst_ has quit IRC04:54
*** stingaci has joined #openstack-keystone04:55
*** stingaci has quit IRC04:59
openstackgerritRichard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users
*** voelzmo has joined #openstack-keystone05:09
*** voelzmo has quit IRC05:14
*** furface has joined #openstack-keystone05:17
*** lamt has quit IRC05:24
*** stingaci has joined #openstack-keystone05:27
*** stingaci has quit IRC05:31
*** furface has quit IRC05:31
*** lamt has joined #openstack-keystone05:36
openstackgerritMorgan Fainberg proposed openstack/keystone: Deprecate `ignore_password_expire_user_ids` conf option
morganrderose: ^ 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
morganrderose: if you'r enot opposed i'll rebase your change onto them (once you look them over)05:39
morganstevemar: ^ cc05:39
*** furface has joined #openstack-keystone05:47
*** v1k0d3n has quit IRC05:56
*** v1k0d3n has joined #openstack-keystone06:02
*** furface has quit IRC06:03
*** jerrygb has joined #openstack-keystone06:04
*** jerrygb has quit IRC06:08
openstackgerritzhangyanxian proposed openstack/oslo.policy: Delete the unnecessary word in
*** edmondsw has joined #openstack-keystone06:13
openstackgerritzhangyanxian proposed openstack/oslo.policy: Delete the unnecessary word in
*** furface has joined #openstack-keystone06:13
*** edmondsw has quit IRC06:17
*** Jack_I has joined #openstack-keystone06:20
openstackgerritAnh Tran proposed openstack/keystone-specs: Typo fix: foriegn => foreign
bretonsaw a link on openstack@ and saw there how repose configures rbac:
*** dikonoor has joined #openstack-keystone06:31
*** lamt has quit IRC06:40
*** thorst_ has joined #openstack-keystone06:50
*** furface has quit IRC06:52
*** thorst_ has quit IRC06:55
*** dikonoor has quit IRC07:09
*** dikonoor has joined #openstack-keystone07:11
*** voelzmo has joined #openstack-keystone07:18
*** tesseract has joined #openstack-keystone07:31
openstackgerritMerged openstack/keystone-specs: Typo fix: foriegn => foreign
*** pnavarro has joined #openstack-keystone07:40
*** dikonoor has quit IRC08:17
*** pcaruana has joined #openstack-keystone08:17
*** dikonoor has joined #openstack-keystone08:18
*** stingaci has joined #openstack-keystone08:34
*** thorst_ has joined #openstack-keystone08:51
*** thorst_ has quit IRC08:56
openstackgerritMerged openstack/oslo.policy: Delete the unnecessary word in
*** zzzeek has quit IRC09:00
*** zzzeek has joined #openstack-keystone09:01
*** n1b has joined #openstack-keystone09:13
*** yarkot has quit IRC09:29
*** edmondsw has joined #openstack-keystone09:50
*** edmondsw has quit IRC09:54
*** liujiong has quit IRC10:01
*** mvk has quit IRC10:12
*** hoangcx has quit IRC10:27
*** dikonoor has quit IRC10:28
*** zhugaoxiao has quit IRC10:34
*** mvk has joined #openstack-keystone10:46
*** sm1235 has joined #openstack-keystone10:48
*** dikonoor has joined #openstack-keystone10:51
*** thorst_ has joined #openstack-keystone10:52
*** thorst_ has quit IRC10:57
*** portdirect_away is now known as portdirect10:59
*** thiagolib has joined #openstack-keystone11:07
*** dikonoor has quit IRC11:11
dimsstevemar : whatever is baked into the infra images i think11:11
*** ayoung has joined #openstack-keystone11:12
*** ChanServ sets mode: +v ayoung11:12
*** dikonoor has joined #openstack-keystone11:12
*** dikonoor has quit IRC11:31
*** nicolasbock has joined #openstack-keystone11:43
*** haplo37_ has quit IRC11:44
*** dikonoor has joined #openstack-keystone11:45
*** erlon has joined #openstack-keystone11:49
*** haplo37_ has joined #openstack-keystone11:56
samueldmqhey keystoners, I am back from LCA!11:58
samueldmqhope you all had a great weekend11:58
*** thorst_ has joined #openstack-keystone12:03
*** thorst_ has quit IRC12:04
*** stingaci has quit IRC12:04
*** dave-mccowan has joined #openstack-keystone12:05
*** eftepede has joined #openstack-keystone12:11
eftepedeHi 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
eftepedeIs there any way to force using of publicURL?12:12
ayoungeftepede, yeah....there was a config setting in Keystone that tells it to rewrite requests12:17
ayoungeftepede, its not super intuitive, something with admin_ulr in the name12:17
ayoungeftepede, if you don't explicitly set that value, everything works.  If you set it, Keystone makes everything go admin12:18
ayoungeftepede,  Maybe?12:19
*** dave-mccowan has quit IRC12:25
eftepedeI have auth_url pointed to public url.12:43
*** dave-mccowan has joined #openstack-keystone12:45
*** catintheroof has joined #openstack-keystone12:45
*** catintheroof has quit IRC12:50
asettleHey 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-keystone12:58
asettlelbragstad stevemar or dolphm ^^12:59
*** _sigmavirus24 is now known as sigmavirus13:02
*** sigmavirus has joined #openstack-keystone13:02
*** hrybacki|sick is now known as hrybacki13:04
*** lamt has joined #openstack-keystone13:12
*** raildo has joined #openstack-keystone13:13
*** lamt has quit IRC13:16
*** edmondsw has joined #openstack-keystone13:19
*** jaugustine has joined #openstack-keystone13:22
*** pnavarro has quit IRC13:23
*** v1k0d3n has quit IRC13:28
*** v1k0d3n has joined #openstack-keystone13:29
*** pnavarro has joined #openstack-keystone13:36
*** nicolasbock has quit IRC13:46
*** nicolasbock has joined #openstack-keystone13:51
fricklerasettle: 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_url13:54
asettlefrickler: 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
asettleI 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 IRC13:58
*** richm has joined #openstack-keystone14:05
*** stingaci has joined #openstack-keystone14:06
*** nicolasbock has joined #openstack-keystone14:06
*** thorst_ has joined #openstack-keystone14:08
*** stingaci has quit IRC14:10
*** jerrygb has joined #openstack-keystone14:14
*** jerrygb_ has joined #openstack-keystone14:15
*** jerrygb__ has joined #openstack-keystone14:18
*** thiagolib has quit IRC14:18
*** jerrygb has quit IRC14:19
*** jerrygb_ has quit IRC14:20
lbragstadasettle do you have a link?14:22
asettlelbragstad: ahhhh you know, I did14:22
*** v1k0d3n has quit IRC14:23
*** v1k0d3n has joined #openstack-keystone14:24
asettlelbragstad: that took a little finding:
openstackLaunchpad bug 1658396 in openstack-manuals "What's the transport_url for keystone service?" [Undecided,Won't fix]14:25
asettleplease correct me if I'm wrong, but that's what I found after my digging14:25
lbragstadasettle checking14:26
asettleThanks lbragstad14:26
*** catinthe_ has joined #openstack-keystone14:29
andreykurilinstevemar: ping14:31
*** voelzmo has quit IRC14:32
*** catintheroof has quit IRC14:32
*** dikonoor has quit IRC14:32
*** eftepede has left #openstack-keystone14:35
*** voelzmo has joined #openstack-keystone14:36
*** voelzmo has quit IRC14:38
lbragstadasettle aha - ok that makes sense14:40
lbragstadasettle responding now14:40
asettlelbragstad: thank you :)14:40
asettleAppreciate that lbragstad14:40
*** n1b has left #openstack-keystone14:51
lbragstad^ hopefully that makes sense?14:52
openstackLaunchpad bug 1658396 in openstack-manuals "What's the transport_url for keystone service?" [Undecided,Won't fix]14:52
*** stingaci has joined #openstack-keystone14:52
asettlelbragstad: yes :) a much better explanation than my "I think this is the thing, thank you kbye"14:53
lbragstadasettle i don't think we have any place that explains that clearly though14:54
*** stingaci has quit IRC14:54
*** stingaci has joined #openstack-keystone14:54
asettlelbragstad: 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
asettleDoc the non-doc issue. COurse that would be my solution.14:55
lbragstadasettle we could also amend the deprecation in config to be a little more clear, too14:56
asettlelbragstad: I think that's probably the better option of the two. Most deployers will go looking in the conf second to the docs14:56
*** jaosorior has joined #openstack-keystone14:56
*** agrebennikov__ has joined #openstack-keystone14:58
lbragstadasettle actually - it looks like that configuration option is owned by oslo.low14:58
asettlelbragstad: rehhhhhh14:58
asettlelbragstad: rehhhhhh14:58
asettleStupid up key14:58
asettleWhat's next steps?14:58
lbragstadthere is also a oslo_messaging_notifications transport_url section14:59
*** stingaci has quit IRC15:00
lbragstadasettle 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 libraries15:05
asettleOh man, this is going down the rabbit hole quickly.15:07
*** edtubill has joined #openstack-keystone15:07
* lbragstad heads to the oslo channel 15:08
*** voelzmo has joined #openstack-keystone15:13
morganlbragstad: man do i need to join over there too?15:13
lbragstadmorgan you probably should ;)15:13
morganlbragstad: wait what is going on15:13
morgani might have the historical context for you15:13
lbragstadmorgan 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
morgandeprectated settings15:14
morganand new code15:14
morganbasically you outlined it perfectly in your comment15:15
morgantesting might be light but afaik nothing really consumes/tests the consuming of kyesotne notifications15:15
morganalso all the audit trail is sent on the message bus15:15
*** jamespage has joined #openstack-keystone15:15
morganand since oslo supplies the message bus connections15:16
morganwe don't do direct testing of it (dsvm might test it)15:16
morganin fact, unit tests should NOT test that15:16
*** stingaci has joined #openstack-keystone15:16
morganbecause we'd need rabbit... or a lot of mocking15:16
morgantl;dr - your comment on the bug is 100% spot on15:16
lbragstadso we have and ?15:17
*** voelzmo has quit IRC15:19
*** knikolla has quit IRC15:20
*** knikolla has joined #openstack-keystone15:20
*** stingaci has quit IRC15:20
knikollao/ morning15:21
*** spotz_zzz is now known as spotz15:21
lbragstadknikolla o/15:22
*** nicodemus_ has joined #openstack-keystone15:30
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-keystone15: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 option15:34
nicodemus_CFG_GROUP = service_credentials in this case15:35
*** lamt has joined #openstack-keystone15:35
*** voelzmo has joined #openstack-keystone15:37
morganlbragstad, rderose: about to push ignore_lockout fix code15:38
morgani need to add 2 more tests to each of the lockout/password-expiry code changes15:39
morganand they should be ready to go15:39
lbragstadmorgan cool15:40
morganand then we can rebase rderose's change on top of it15:41
morganin Pike i think we need to re-structure how we handle user options such as these15:41
morganlbragstad: since you're running as PTL here is my rundown15:41
morganlbragstad: new table, user-options.15:41
morganlbragstad: options such as "ignore-password-expiry' are defined in code15:42
morganlbragstad: user table then does a one[user] => many[options] relationship15:42
morganoptions defined for the user are [option_id][user_id/PK][option_value]15:42
morganthis can then encompass multiple cases such as defining what options can be set by the user and what can be set by an admin only15:43
morganuser could set, say "default_project_id"15:43
morganand we could drop the stupid column15:43
morganbut admin can only set "ignore password expiry"15:43
morganit also allows us to mostly drop the "extras" column need [i know we 'cant15:44
morganbut it shifts keystone's internal use to real options we control15:44
morganand validate15:44
morganlbragstad: thankfully it should be a small amount of code15:45
*** jerrygb has joined #openstack-keystone15:45
rderosemorgan: nice15:45
morganrderose: told you i'd have the code ready for you ;)15:45
morganrderose: please revew the current one posted15:45
lbragstadmorgan can anything be stored there?15:45
morganlbragstad: no, just the ones we specifically define, hence the 'extra' column would stick around15:46
rderosemorgan: will do, and yes you did ;)15:46
morganlbragstad: but anything internal to keystone could be ecivted from extras15:46
lbragstadmorgan ok - so this option_value column is going to have some sort of whitelist that we maintain?15:46
morganlbragstad: not a "white list" a specific definition in code of "options" keystone cares about15:46
rderosemorgan: what about the lockout_ignore_user_ids?15:46
morganrderose: running unit tests now15:47
rderosemorgan: shall we kill 2 birds with 1 stone?15:47
rderosemorgan: cool15:47
morganrderose: as soon as those pass, next review being pushed15:47
*** jerrygb__ has quit IRC15:47
morganrderose: i did it as 2 reviews because it was different concerns15:47
openstackgerritSamuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS
morganlbragstad: if it is something like ignore_password_expiry or ignore_password_lockout or default_project_id, etc15:47
morganlbragstad: we have an option for it.15:48
morganlbragstad: if it is some random value the deployer sets... we let it fall into extras15:48
morganlbragstad: last of all, we can also start a list on the user object, owner_can_set or some such15:48
morganthat lets the user set some values15:48
morganaka, with update_user. vs locked to admin only15:48
morganor via another API15:49
morgandefault_project_id being a classic example15:49
morganlbragstad: we could replicate the pattern for domains, projects, etc (as we would need to) for things like per-domain-PCI-DSS-enforcement15:50
*** chris_hultin|AWA is now known as chris_hultin15:50
lbragstadmorgan would the list of things a user can set change across deployments?15:51
lbragstadwould that be something a deployer sets somehow?15:51
morganlbragstad: no. these would be options *we* have defined.15:51
morganas safe, if the deployer wants to block users from updating these items,  they would block access to the API15:51
lbragstadthat feels policy related15:52
morganpolicy not config15:52
morganbut it would be specifically defined things we have outlined15:52
morganit would be either "you can set these" or "403"15:52
* morgan pushes for opinionated things15:52
morganso deployments are more consistent15:52
lbragstadyeah - i agree with the consistency part15:53
morgannot removing "options" from deployers, but being less "you can tweak every possible little thing"15:53
lbragstadjust thinking that the real thing we enabling here is to achieve better policy15:54
lbragstadand we'll be doing that in code15:54
morganlbragstad: it's two-fold15:55
morganlbragstad: 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 things15:55
*** jose-phillips has joined #openstack-keystone15:55
morganwhen it's legitimately an "option"15:55
morganand 2) better policy15:55
morganif it's legitimately a per-user/per-project/per-domain config15:55
lbragstadare we going to run into problems with policy here and policy there?15:56
morganand it's not going to be used for *every* thing15:56
morganlike enabled15:56
morgani think it'll just be a "user-options" api15:56
morganeither set via update_user or via user-options15:56
morgan(ideally the latter)15:57
morganshould be super straightforward policy wise.15:57
morganrderose: doh, had a typo, starting run again for tests.15:57
morganrderose: have two bugs to toss on the pile to fix if we can15:58
morganso many warnings when running tests15:58
morganin pycadf and... oslo-something15:58
morgansee if we can smash those quickly15:58
morganthen back to trying to get MFA rules API built15:58
morgansince the rest of the code is proposed, just not the API / controller bits15:58
morganrderose: i had to do a little magic on the User object with @property to make the not-null boolean happy15:59
morganrderose: and it worked well since i wanted to loop in security_compliance in the user property (on the model) as well15:59
rderosemorgan: okay (magic makes me nervous)15:59
morganrderose: it just forces bool()15:59
morganinstead of allowing None in .settr and such16:00
rderoseI see16:00
morganfor some reason SQLite3 was ignoring server_default16:00
morganso every update was failing16:00
morgansolution: force bool on get/set with @property16:00
morganbonus, if conf.security_compliance.... is set,and the user_id is in the list16:00
rderoseyou are defaulting to false right?16:00
morganoverride to true16:01
morganyes, defualt to false16:01
morganfor both16:01
morgan^ as examples16:01
*** nklenke has joined #openstack-keystone16:02
morganso the tests that need to be added: 1) did the conf. migration to the db work16:02
morganand 2) a test to explicitly set those values16:02
morganpretty straight forward16:03
morganand that will cover the new code16:03
rderosemorgan: gotcha16:04
rderosemorgan: so when you return ignore_password_lockout it calls the setter lockout_ignore()16:05
morganit's a typo16:05
morgani just fixed that16:05
*** adrian_otto has joined #openstack-keystone16:05
morganthat was the typo (the copy/paste) was before i fixed those16:05
*** voelzmo has quit IRC16:07
*** spotz is now known as spotz_zzz16:08
*** jperry has joined #openstack-keystone16:09
*** spotz_zzz is now known as spotz16:09
morganlbragstad: our unit tests have gotten slow again =/16:10
morganlbragstad: 800-1200sec to run16:10
* lbragstad pages dstanek 16:10
*** pcaruana has quit IRC16:13
*** mvk has quit IRC16:18
*** jose-phillips has quit IRC16:18
morgandstanek: just unit tests have gotten slow again16:19
dstanekmorgan: ah16:19
morgani think we'r eupwards of 800s in gate and locally also sloooow16:19
dstaneki'll go ahead and fix that :-)16:19
morganthat was lbragstad pinging you, i was just commenting :P16:20
lbragstaddstanek our unit tests need more go-go16:20
*** nklenke has quit IRC16:21
*** diazjf has joined #openstack-keystone16:25
dstaneklbragstad: i'll add a pomodoro or two tomorrow to start to fix16:26
lbragstadmorgan did you have another patch set coming for ?16:26
lbragstaddstanek that'd be a good thing to do as a group, too16:27
openstackgerritMorgan Fainberg proposed openstack/keystone: Deprecate `lockout_ignored_user_ids` conf option
morganrderose: ^16:27
morganlbragstad: yes it will be rebased on ^ provided no issues with the lockout_ignored patch16:28
lbragstadrderose do you happen to have anything locally for ?16:29
openstackLaunchpad 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
lbragstaddstanek do you happen to have anything locally for ?16:30
openstackLaunchpad 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
rderosemorgan: on it!16:30
rderoselbragstad: no, I don't16:30
lbragstadrderose do you mind if I unassign in case anyone else wants to pick it up?16:31
rderoselbragstad: I'd prefer to keep that one as it's related to dropping federated tokens; hoping to starting on it this week16:32
*** david-lyle has joined #openstack-keystone16:32
lbragstadrderose ok - sounds good, just double checking16:32
dstaneklbragstad: yeah, i think i still have a handful of patches16:32
* morgan is back16:32
lbragstaddstanek cool - i'll keep that one as is then16:32
*** diazjf has quit IRC16:33
dstaneklbragstad: i just updated it16:33
morganrderose: easy enough to respin to local-user16:33
lbragstaddstanek sweet - thanks!16:34
morganrderose: then the user object would return false for any non-local users?16:34
rderosemorgan: yep, exactly16:34
morganfair enough, long term i expect it to just move to the options table16:35
rderosemorgan: as PCI is mostly only specific to local users16:35
lbragstadstevemar breton do we still have work to do for this one?
openstackLaunchpad bug 1520244 in python-keystoneclient "flag "truncated" in responses to list operations is not supported" [Medium,Triaged] - Assigned to Boris Bobrov (bbobrov)16:35
morganwhich wont differentiate local vs remote user, but may only be set by the local user16:35
*** Jack_V has joined #openstack-keystone16:35
morganok i can respin the two patches for that16:36
*** nklenke has joined #openstack-keystone16:36
rderosemorgan: cool16:36
morganand .settr will just drop the value if not user.localuser16:36
rderosemorgan: yeah, and in an options table that would totally make sense16:36
rderosemorgan: yes16:36
*** Jack_I has quit IRC16:38
morganthis seems broken16:39
rderosemorgan: how so?16:39
morganrderose: the settr for both domain_id and now password_expiry will cause issues for non-local users16:39
morganif you call .settr it will create the localuser entry16:40
morganwhich is... broken?16:40
rderoseif not self.local_user:16:40
rderosecheck first16:40
morganso if not locla user16:40
morganaka non-local user16:40
morgancreate it16:40
morgannon-locla user shouldn't have localuser() ?16:40
morganor should we have both elements?16:41
morganthen we create it and the use rhas both16:41
rderoseno, you should have one or the other16:41
morganyeah this is broken16:41
morganif you set the ignore_password_expiry, or domain_id.16:41
morganyou create local_user16:41
morganand you have both16:41
rderoseeither local or ldap (nonlocal) not both16:41
morganalso domain_id should be immutable attribute*16:42
morganbut that aside16:42
morganthis current code does not enforce what you just asserted16:42
*** hoonetorg has joined #openstack-keystone16:42
morganit is possible (esp. with cases like ignore_password_expiry, which should be settable at any point)16:42
morganto end up with both local and non-local user objects16:43
morganfor a given user16:43
morgandomian_id shouldn't ever be set outside of creation16:43
morganso it should be "ok"16:43
morganalso... we shouldn't allow domain_id to be set if it is already set16:43
rderosehmm... right, that's true16:43
morganwe need more code in here16:43
rderosemorgan: domain_id is changing16:43
morgangod no.16:43
morgando not *ever* allow someone to set domain_id16:44
morganthat is a massive security risk16:44
rderosemorgan: moving domain_id up to the user table16:44
rderosemorgan: not changing the value16:44
morganthats fine16:44
morganwe still need to make it read-only16:44
morganas it sits... crap this is a security bug =/16:44
rderosemorgan: currently, you can change it via the API16:44
rderose(I think)16:44
rderosepretty sure16:44
*** diazjf has joined #openstack-keystone16:44
morganpreviously we made that impossible16:44
morganthat is a massive regression if we can now16:45
rderosemorgan: really?16:45
dstanekrderose: that's what i was saying last week. i don't think you can16:45
morganand... an OSSA16:45
*** hoonetorg has quit IRC16:45
dstaneki shouldn't be able to put myself of anyone else in a domain that i don't own16:45
rderosemorgan dstanek: json schema validation16:45
morgandomain needs to be immutable16:45
rderosedstanek: where is that enforced?16:45
morgannot in json schema, but the whole way down16:45
morganit used to be enforced either in the manager or the controller16:46
morganbut it really should be in the manager16:46
dstanekrderose: i'm going to guess in the update_* methods in the manager or controller16:46
dstanekmorgan: ++ to manager16:46
rderosedstanek: I'm pretty sure not, but I'll check16:46
morganwe need to remove that code now16:47
morgansince Ocata16:47
rderosemorgan: dstanek:
rderosefound it16:47
*** hoonetorg has joined #openstack-keystone16:47
morganso in short, manager will (in a few minutes) assert [i'll propose the fix] that you can't change domain_ids16:47
morganthat is a *huge* security issue we've been fighting these for a while16:48
rderoselooks like is allowed, but tagged to be removed in O16:48
*** adrian_otto has quit IRC16:48
rderosemorgan: ++16:49
morgananyway... so16:50
morganthe domain_id being on localuser with the hybrid property was a newton code thing?16:50
morganif so, we need a backport to fix it so we don't create localuser where it's not expected16:50
*** stingaci has joined #openstack-keystone16:50
morgani'm going to say lets not shove these options on the local user for headache reasons16:51
morgani don't think i can easily control creation of local vs nonlocal here16:51
*** phalmos has joined #openstack-keystone16:51
morganhow am i supposed to know if local user should be created or not...16:51
morgansimilar for domain_id.16:51
morganhow do we know what item should be created when the user object is created?16:52
rderosemorgan: domain_id was a newton thing, but a local_user wouldn't be created for a nonlocal_user here:16:52
morganrderose: hmm.16:53
rderosemorgan: shadow users creates nonlocal and federated users16:53
morganrderose: maybe i should just create an option(s) table now like the MFA table...16:53
morgan=ugh i hate that even more16:54
rderosemorgan: :)16:54
morgantoo much moving bits for this late16:54
rderosemorgan: options table would be great, but yeah, late in the hour for that kind of change16:54
*** stingaci has quit IRC16:55
morganso issue is16:55
morgani need to strip the values in the non-locla user code path as well?16:55
morganbut... i can't control update in the model16:55
morgani don't think we can move this to non-local user atm =/16:56
morganerm... localuser16:56
rderosemorgan: rather than deprecate ignore users now, why not just wait for the options table?16:56
morgani worry about lumping this functionality into the config and encoding the behavior more16:56
morgan1 cycle, not a lot of use16:56
morgan2 cycles, things tend to get used16:56
*** adrian_otto has joined #openstack-keystone16:57
morganand people start leaning on it16:57
rderosemorgan: true, it's not going to be hard to deprecate and migrate16:57
*** david-lyle_ has joined #openstack-keystone16:57
rderosemorgan: and the reality of many operators implementing this early is low16:57
rderosemorgan: especially change password on first use16:57
rderosemorgan: the options table is by far the better option16:58
rderoseif you move to local_user, then we'll have to migrate16:58
rderoseto the options table later16:58
rderosebe back shortly16:59
*** ayoung is now known as ayoung-food16:59
morganrderose: it's about the same regardless.17:00
morganrderose: but more important is when all the tools out there start using the options (puppet, ansible, etc)17:01
morganthe 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 IRC17:03
*** jose-phillips has joined #openstack-keystone17:07
*** tesseract has quit IRC17:15
*** nicolasbock has quit IRC17:19
*** mvk has joined #openstack-keystone17:26
*** nicolasbock has joined #openstack-keystone17:27
*** nicolasbock has quit IRC17:40
* morgan pokes stevemar17:41
*** thiagolib has joined #openstack-keystone17:46
nicodemus_I'm having trouble with the following code snippet:
morgannicodemus_: it grabs the config object from keystone, then it forces config to load (import) the auth method handlers17:50
nicodemus_auth_plugin is empty, and I can't create a session. Any pointers / suggestions ? I'm stuck :(17:50
morganoh ait17:50
morgansorry that is for keystonemiddleware17:51
morganyou need to provide the auth plugin information in your [keystone_authtoken] config group17:51
morganin the config file17:51
morganif you look, in say, nova, that is what that is for17:51
morganif you're trying to create a session for your own application to use17:51
morganthis wont work for you since this is the mechanism used for the middleware in front of nova/neutron/etc17: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-keystone17:54
*** nicolasbock has joined #openstack-keystone17:55
morganhold on there is a good "how to use sessions": doc jamielennox wrote17:56
*** david-lyle_ has joined #openstack-keystone17:56
*** david-lyle_ has quit IRC17:56
*** david-lyle_ has joined #openstack-keystone17:57
knikollathere's a keystoneclient call called validate_token, that will give you everything about the token you query17:57
morganknikolla: we need to do a 301 for ksc to now.17:57
nicodemus_knikolla, morgan, wonderful! I'll give that a try17:57
nicodemus_thanks a lot!17:57
morgannicodemus_: :)17:57
* morgan lays a PTL trap for stevemar and hides waiting for it to spring.17:58
knikollamorgan: there's a similar page on ksc, but yeah, a redirect would be better.17:59
morganwell ksc hasn't dropped session yt17:59
openstackgerritRichard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users
*** diazjf has quit IRC18:04
*** david-lyle has quit IRC18:05
*** david-lyle_ is now known as david-lyle18:05
nicodemus_morgan, knikolla, the example worked. Thanks again!18:10
morgannicodemus_: :)18:10
*** ravelar has quit IRC18:10
*** ravelar has joined #openstack-keystone18:11
openstackgerritRichard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users
*** pnavarro has quit IRC18:15
*** spotz is now known as spotz_zzz18:22
*** spotz_zzz is now known as spotz18:26
openstackgerritRon De Rose proposed openstack/keystone: Add domain_id to the user table
*** ravelar has quit IRC18:39
openstackgerritRon De Rose proposed openstack/keystone: Add domain_id to the user table
*** ayoung-food is now known as ayoung18:45
*** catintheroof has joined #openstack-keystone18:45
*** catinthe_ has quit IRC18:47
openstackgerritSamuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS
*** kukacz has quit IRC19:03
*** catinthe_ has joined #openstack-keystone19:03
*** catintheroof has quit IRC19:06
*** voelzmo has joined #openstack-keystone19:15
*** ravelar1 has joined #openstack-keystone19:22
*** knikolla has quit IRC19:23
*** knikolla has joined #openstack-keystone19:23
*** knikolla has quit IRC19:23
*** ravelar15 has joined #openstack-keystone19:23
lbragstaddo we have any LDAP experts on staff today that would be interested in looking at ?19:24
openstackLaunchpad 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-keystone19:24
*** knikolla has quit IRC19:24
*** knikolla has joined #openstack-keystone19:24
*** knikolla has joined #openstack-keystone19:25
*** knikolla has quit IRC19:25
*** knikolla has joined #openstack-keystone19:25
*** knikolla has quit IRC19:25
*** ravelar1 has quit IRC19:27
*** ravelar15 is now known as ravelar119:27
*** Marcellin__ has joined #openstack-keystone19:32
*** diazjf has joined #openstack-keystone19:39
*** knikolla_ has joined #openstack-keystone19:45
knikolla_irc bouncers are great, until they stop working19:45
*** jaosorior has quit IRC19:50
*** voelzmo has quit IRC19:51
*** jose-phillips has quit IRC20:10
openstackgerritSamuel Pilla proposed openstack/python-keystoneclient: Allow Multiple Filters of the Same Key
*** MasterOfBugs has joined #openstack-keystone20:16
*** stingaci has joined #openstack-keystone20:20
morganlbragstad: don't move users and expect it to work in LDAP20:20
morganlbragstad: moving a user in the Ldap tree breaks the DN20:21
morgankeystone cannot know about this20:21
morgansince keystone is unable to understand that the DN it's aware of suddenly changed20:21
morganthe user will be broekn20:21
morganfull stop20:21
morganif 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 anymore20:22
morganthis is expected20:23
lbragstadmorgan ok - that's kinda what I figured20:23
morganso, the simple answer is "no"20:23
lbragstadmorgan do you know if we document that anywhere?20:23
morganthe long answer is "noooooooooooooooooooooooooooooooooooo20:23
morganthe really long answer is: In theory you could make keystone look in both places for the user object20:23
morganbut we don't really test that. it's getting into complex filters and multiple tree lookups and/or referral chasing20:24
morganno, not explicitly documented20:24
morganbut any application that uses LDAP as a source of Identity (or anything) would break in a similar20:24
lbragstadmorgan I can update the bug report and link to this conversation20:25
morganthe same question is similar to: So I moved the row for <user> into another table in the database, why are my role assignments broken20:25
openstackgerritSamuel Pilla proposed openstack/python-keystoneclient: Allow Multiple Filters of the Same Key
morganthere is no strict FK-like enforcement between subsystems in keystone. because keystone may not manage things.20:26
morganzzzeek: ping - have a SQL-A question for you20:26
morganzzzeek: if you are around. I just don't know the answer i can bug other folks if you're not here20:26
morganzzzeek: 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
morganbased upon how keystone is using the User object now?20:28
morganrderose: ^ 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 IRC20:45
openstackgerritRichard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users
*** nklenke has quit IRC20:50
*** esp_ has joined #openstack-keystone21:02
*** stingaci has joined #openstack-keystone21:04
*** adriant has joined #openstack-keystone21:06
*** raildo has quit IRC21:07
*** stingaci has quit IRC21:08
rderosemorgan: cool21:11
*** jerrygb has quit IRC21:12
morganrderose: just treying to figure out how to modify .from_dict21:13
morganto work w/ the options21:13
rderosemorgan: 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
rderosemorgan: and I assume get_user API would return the option list, correct?21:14
rderosemorgan: whereas list_user api, would not return the option list21:15
morganbasically, i am trying to load the options into the user_ref21:16
morganwhen loaded from the db21:16
rderosemorgan: federated_users is an example of 1-to-many with User:21:16
morganand extract the values form the ref and store into the new table when the name/key matches21:16
rderosemorgan: np, create the relationship and it will automatically get loaded21:17
morganso 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
morganthe concern i have is how to add it to the user_options_table21:17
rderosemorgan: oh21:17
morganyeah. see, more complex.21:18
morganand how to cover deletion of the options, and finally how to ensure it is an insert or update21:18
rderosewell, you could keep it as a list and forget about this craziness :)21:19
morganbecause we don't want to create wonky-new-api thing for storing these options. i want user updates to be atomic still21:19
rderoseand it would just be an array passed back in json21:19
morgani could make it json in the table like the MFA rules21:19
morganbut it feels weird to do so.21:19
morganthe plan is to make it so explicitly setting the option to None deletes the option from the db21:20
morganor the plan was21:20
rderosemorgan: it doesn't feel so weird to me, as these are optional values (I think)21:20
morganas a json blob, deleting it is near impossible21:20
morgani guess we could use the same mechanism21:20
morganoption: None -> delete21:21
morgantrying to use relational dbs as relational things vs. just a way to store values elsewhere21:21
morganif that is the case, we might as well just wedge the options in a column on user21:21
morgana separate table is kind of... overkill21:21
morganthe MFA rules are different because they have additional metadata21:22
morgansuch as "disable all MFA rules"21:22
morganwhich is tied to those rules21:22
morganvs say an option on the user21:22
morgani guess i could revisit and just make MFA disabled a new option class thing21:22
zzzeekmorgan: sup21:22
morganand then store all the options on the main user table21:22
morganzzzeek: hey man21:22
morganzzzeek: so... trying to work through a design where we define options for resources in code, aka options like "ignore pci-dss things"21:23
morganso 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
morganthe 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
morganin a table, and use nice RDBMS models to load the list of options set21:24
rderosehmm... I still sort of like the user => user_option => option tables. and we could dynamically create the user attributes in the options.21:24
morganthe only issue i'm running into is how to do so cleanly with the from_dict/to_dict magic in keystone21:24
rderosebut the backend would hold the data in a new table21:25
morganrderose: if it ends up being a single row and column per user... does it belong in another table?21:25
morganzzzeek: am i crazy?21:25
morganzzzeek: should i just conceed and do the json-blob store in a column and load the options that way21:26
zzzeekmorgan: 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 dea21:26
zzzeekif those rows somehow interact with some other query then that may or may not be difficult21:26
*** ravelar1 is now known as ravelar21:26
*** jose-phillips has joined #openstack-keystone21:27
morganthe only issue i'm running into is how to store it where we do like an insert-or-update21:27
morganif the option is already set for the user21:27
rderoseoption (id:1, name:ignore_password_expiry, default:false)21:27
rderoseuser_option (user_id: 1, option_id: 1, value: true)21:27
morganhere let me push the example code to gerrit so you can see what i've done so far.21:27
morganand tell me how crazy/not crazy i am.21:27
zzzeekmorgan: ok....are you referring to concurrent requests all trying to add the same user?  unique constraint?21:27
morganshould be atomic to store the data for a user21:28
morganbut in theory you could have multiple requests (it is keystone) to update the values at the same time21:28
morganthat change different opts21:28
openstackgerritMorgan Fainberg proposed openstack/keystone: WIP - SoftOptions Table UserOpts
zzzeekok, so one user has multiple rows in this table ?21:28
morganthat would be the idea21:28
morganeach option is a row, if it is set21:29 want serilizable update to all the rows at once?21:29
morgani'm looking at loading/saving the values from the user_ref dict21:29
morganit doesn't have to be "all at once"21:29
morgan^ that wont pass CI, at all21:29
morganbut it is the basic "idea" I was working from21:29
zzzeekmorgan: 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 common21:30
zzzeekthere is then the association proxy that can pull in some related object21:30
zzzeekthat pattern isn't hard21:30
morganso where i am stumbling is extracting the option from the user_ref and shoving it into the new table21:30
morgannot all things are being extracted21:30
morganif the option is not explicitly defined it still just falls into the horrible ."extras" json blob21:30
zzzeekmorgan: "extracting" meaning.... migrating from an old schema to new ?21:31
*** jerrygb has joined #openstack-keystone21:31
morganuser_ref is a dict21:31
*** diazjf has quit IRC21:31
morganand we do user.from_dicT(user_ref)21:31
morganwhen we store which makes SQL-A objects to shove into the DB backend21:31
zzzeekOK if you have pyhton dictionary, and you use the normal SQLAlchemy ORM dictionary pattern, you say, user.my_stuff = the_dict21:31
*** jerrygb_ has joined #openstack-keystone21:32
zzzeekmorgan: the feature I'm referring to is here:
zzzeekmorgan: if you can see if that maps to your concept21:33
morganone extra layer of abstraction21:34
morganbut yes21:34
morgannow i just need to do a little extra work to make sure we don't delete options not set21:35
*** thorst_ has quit IRC21:35
morganbecause 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-keystone21:35
*** jerrygb has quit IRC21:36
morganyep. i will just need to do an explicit load/reconciliation on the_dict before saving in an update case21:37
*** jose-phillips has quit IRC21:39
*** thorst_ has quit IRC21:40
*** diazjf has joined #openstack-keystone21:41
*** jose-phillips has joined #openstack-keystone21:41
*** stingaci has joined #openstack-keystone21:42
*** Jack_V has quit IRC21:42
morganahh this looks more like the Unqiue object recipe i need21:42
*** nicodemus_ has quit IRC21:44
*** adrian_otto has quit IRC21:45
morganzzzeek: ok now i am confused...21:45
morganzzzeek: what exactly is being said here:21:45
morganOne 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, is21:45
morganrecommended, 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-keystone21:45
zzzeekmorgan: oh right.   so, you are doing User -> Option ?21:46
*** stingaci has quit IRC21:46
*** markvoelker has quit IRC21:47
openstackgerritSamuel Pilla proposed openstack/keystone: Update endpoint api for optional region_id
morgani mean, i can figure out how to muck with things to make it into a dict representation21:48
zzzeekmorgan: OK are all the possible "options" in the database already ?21:48
morganafter the fact, but i also need to make sure all options that are currently set continue to exist21:48
morganthey wont be in the db21:48
morganonly in code21:48
zzzeekmorgan: so if a user refers to option "foo" what is physically in the database that links to "foo" ?21:48
zzzeekinteger id? GUID ?  string ?21:48
morganuser_id and a option_id (defined in code)21:49
morganif someone fubars/changes option_ids, the values are lost21:49
morgani am trying my damnest to avoid needing to change the db schema or insert control rows for each option21:49
morganso we can define an option for a resource without needing migrations each and every time21:50
openstackgerritKristi Nikolla proposed openstack/keystone: WIP: Remove LDAP delete logic and associated tests
openstackgerritSamuel Pilla proposed openstack/python-keystoneclient: Allow Multiple Filters of the Same Key
morganthe FK to the User table in this case, will cascade delete if the user is deleted (sufficient)21:50
zzzeekmorgan: option_id is a...string ?21:50
morganwas going to do it as an int21:51
morgani could also do it as a String.21:51
zzzeekmorgan: you're going to hardcode ints in the python ?21:51
morgan(for the option name)21:51
morganbasically, yes, the options will be set in python21:51
zzzeekmorgan: 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 integer21:51
morganyeah i used to do it as a 4-character code21:52
morganbut same concept21:52
morgan4cc (4-character-code)21:52
zzzeekmorgan: also you wouldnt need the association proxy here since you are using a lookup21:52
morganright. the only direct association is the user_id21:52
morganand the uniqueness constraint is (user_id, 4cc)21:53
morganor (2cc)21:53
morganwhatever length is used21:53
morgani'll have a little extra logic to ensure user-options are only for user, eventually we will have domain options, project options, etc21:53
morganeach with their own table21:53
morganbecause the options will be fundamentally different for each resource type21:54
morganexAMPLE: a user may be opted out of passwor dexpiration21:54
morgana domain may require all users not opted out to use password expiration21:54
morganinstead of the global options we have right now21:55
morganwhere it is "everything is X"21:55
zzzeekmorgan: so each option has a value also right?21:55
morganacross all of keystone (and thus, uuids of users are encoded in the keystone.config)21:55
zzzeekmorgan: ok so the rationale for a separate table vs. json string is...searching on them and/or joining in queries ?21:55
morganto begin with options are mostly true/false21:55
morganthat was my thought, allowing a search for all users that do not have passwords that expire21:56
morganor all users in domain X that don't have password expire21:56
morgannot part of the implementation right now21:56
morganbut future proofing21:56
morganbecause the json extra blob is just ugly/terrible/unfortunate21:56
morganand i don't wnat to continue with that kind of "well you don't know unless you look at every user" pattern21:56
morganesp. for options that affect the PCI-DSS compliance code21:56
* morgan is trying for real(ish) architecture here.21:57
zzzeekmorgan: in the key/value area all the options are crappy21:58
morganso the way i saw the table initially was: [auto_inc_pk][user_id (fk to][option_id/code/whatever for lookup][option value]21:58
*** thorst_ has joined #openstack-keystone21:58
morgani could prob. drop the auto_inc_pk and just make the pk(, code)21:59
zzzeekmorgan: yeah that is mostly it, although you can make the PK the combination of (user_id, option_id) also21:59
morganthat is prob. best bet21:59
morganthen the automagic mapping should just work21:59
zzzeekmorgan: 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 too21:59
morganthese tables should not ever need to be the FKs to that table22:00
morganerm.. other tables should never need to FK to that table22:00
morganif you're not looking it up via (in this case) User22:00
morganyou're doing it wrong22:00
zzzeekmorgan: so...yeah, this is User.options = relationship(Option, collection_class=attribute_mapped_collection('option_id'))22:00
morganok cool22:00
morganand then that just looks like a dict on user.options22:01
morganwhen accessing/mucking with it22:01
morgani'll work on some logic to make sure we don't do a whole-sale replace with each updat eon that22:01
morganbecuase if someone does update_user(user_id=blah, user_ref={'ignore_password': True}) it should only change the ignore_password option22:02
morgannot replace all options and now the user only has ignore_password22:02
morgansome options may be (long term) admin-only settable, so need to be careful on replacements. but i think i know how to approach that22:02
*** thorst_ has quit IRC22:03
*** harlowja has quit IRC22:03
*** chris_hultin is now known as chris_hultin|AWA22:05
*** kukacz has joined #openstack-keystone22:05
*** jaugustine has quit IRC22:12
*** browne has quit IRC22:12
*** thorst_ has joined #openstack-keystone22:13
*** knikolla_ has quit IRC22:13
openstackgerritRichard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users
*** diazjf has quit IRC22:16
*** thorst_ has quit IRC22:22
morganzzzeek: 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
zzzeekmorgan: 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 before22:24
morganright i am looking for the opposite22:24
morganif you set a, b, c, but not D, D is not removed22:24
zzzeekmorgan: if you say, a.options['a'] = a, a.options['b'] = b, a.options['c'] = c, other keys are not removed22:25
morganahhh ok22:25
zzzeekmorgan: if you OTOH say, a.options = {'a':a, 'b':b, 'c':c}, then that deletes any other keys22:25
morgani'll be sure to do the former22:25
zzzeekso!  you might say, a.options.update({'a': a, 'b':b, 'c':c})22:25
openstackgerritRichard Avelar proposed openstack/keystone: Add queries for federated attributes in list_users
morganhmm. erg. not sure if this is going to work "right".. but we'll try it :)22:26
morganyeah, i will def. be doing the options['key'] = value model22:27
morganin all cases.22:27
morganand a option['a'] = None should null the option_value, right?22:27
morganin the table22:27
SamYapleis 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.z22:27
morganor a .pop/explicit del should remove the option i take it then22:28
*** edtubill has quit IRC22:35
morganSamYaple: you could look at the root /, we should give the version(s) there22:36
lbragstadsorrison o/ i'm attempting to put two and two together here and wonder if you're the author of this ?22:40
SamYaplemorgan: thanks, will check22:43
*** browne has joined #openstack-keystone22:48
*** thiagolib has quit IRC22:48
SamYapleawesome morgan! i think thats perfect for what im looking for22:49
*** chris_hultin|AWA is now known as chris_hultin22:52
*** spotz is now known as spotz_zzz22:54
zzzeekmorgan: that would make it NULL, yes22:55
zzzeekmorgan: but leave it present22:55
*** spotz_zzz is now known as spotz22:57
morganok and a .pop/del should remove it22:57
morganor would that likewise NULL it?22:57
zzzeekmorgan: removing the item means remove from the list, so if you have set up the "delete" cascade that would remove it22:58
zzzeekmorgan: you'd want delete, delete-orphan on this one22:58
zzzeekotherwise it owudl try to null out user_id and you'd get a constraint violation22:59
morganor all,delete-orphan,delete ?22:59
morganor just delete,delete-orphan23:00
*** furface has joined #openstack-keystone23:00
*** adrian_otto has quit IRC23:00
*** jperry has quit IRC23:01
*** spotz is now known as spotz_zzz23:06
zzzeekmorgan: all, delete, delete-orphan usually23:08
morgancool done thnx!23:10
*** chris_hultin is now known as chris_hultin|AWA23:18
*** catinthe_ has quit IRC23:23
*** phalmos has quit IRC23:23
*** ravelar has quit IRC23:26
*** ravelar has joined #openstack-keystone23:27
*** harlowja has joined #openstack-keystone23:34
*** harlowja has quit IRC23:35
*** jose-phillips has quit IRC23:35
*** jose-phillips has joined #openstack-keystone23:37
*** dave-mccowan has quit IRC23:38
*** stingaci has joined #openstack-keystone23:40
morganwhat the hell is up with D400 REQUIRING the first line of a file (comment) to end with a .23:44
morgan^^ REALLY?!23:45
*** stingaci has quit IRC23:45
morganoh... nvm23:45
morganwow that error is awful.23:45
morgantotally wrong error23:46
*** harlowja has joined #openstack-keystone23:48
*** lamt has quit IRC23:56
*** edmondsw has quit IRC23:57
*** edmondsw has joined #openstack-keystone23:59

Generated by 2.14.0 by Marius Gedminas - find it at!