17:01:42 <lbragstad> #startmeeting keystone-office-hours
17:01:43 <openstack> Meeting started Tue Apr  3 17:01:42 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:46 <openstack> The meeting name has been set to 'keystone_office_hours'
17:03:00 <lbragstad> just fyi - i have a few meetings to be in the next couple hours, but i'll try and check in here/multitask
17:12:51 <lbragstad> for those who are familiar with ldap - i took a shot at documenting some how-tos for ldap backed development environments https://review.openstack.org/#/c/557997/
17:16:15 <eandersson> looks great lbragstad
17:32:24 * gagehugo steps out for lunch
17:40:46 <lbragstad> eandersson: thanks for looking :)
18:36:08 <tmcm> hello
18:36:31 <tmcm> doc/keystone-install-ubuntu.rst says:
18:36:42 <tmcm> "Before the Queens release, keystone needed to be run on two separate ports to
18:36:42 <tmcm> accomodate the Identity v2 API which ran a separate admin-only service
18:36:42 <tmcm> commonly on port 35357. With the removal of the v2 API, keystone can be run
18:36:42 <tmcm> on the same port for all interfaces."
18:37:21 <tmcm> does that mean the glance installation instructions that refer to "auth_url=http://controller:35357" should be modified to refer to :5000?
18:37:42 <tmcm> in other words, there is a discrepancy between the two installation documents
18:57:10 <lbragstad> tmcm: yeah - that's likely the case
19:13:14 <tmcm> so, we SHOULD or SHOULD NOT use the admin wsgi in queens?
19:16:26 <tmcm> on ubuntu specifically
20:06:04 <tmcm> using the ldap driver, is there a way to have it fallback to sql for e.g., the service users like glance, neutron, etc?
20:13:23 <knikolla> tmcm: you can have different drivers for different domains
20:13:24 <knikolla> https://docs.openstack.org/keystone/latest/admin/identity-domain-specific-config.html
20:43:32 <kmalloc> tmcm: it is also recommended that keystone be run on HTTP[S] instead of port 5000 or 35357.
20:43:51 <kmalloc> standard HTTP[S] ports*
20:52:29 <lbragstad> kmalloc: another bootstrap question for you
20:52:37 <kmalloc> yeah
20:53:09 <lbragstad> the argument parser for bootstrap has defaults, but if i want to pull the bootstrap logic out into it's own class so that it's easier to hook into the tests, should the defaults move with it?
20:53:23 <kmalloc> i'd say no
20:53:34 <lbragstad> so - keep the new object really generic
20:53:37 <kmalloc> yeah
20:53:39 <lbragstad> and unopinionated
20:53:48 <kmalloc> mostly because bootstrap is opinionated to get an install running
20:53:56 <kmalloc> tests do not adhere to those concepts
20:54:07 <kmalloc> don't do acrobatics to make the test look like you want it to
20:54:53 <kmalloc> tests should be explicit - and defaults can be bundled into the same mechanism we use to do the setup vs. encoding "real world standup" defaults into the core object
20:55:08 <kmalloc> s/same//
20:55:27 <kmalloc> fwiw, i've learned a lot about SR-IOV today
20:55:43 <kmalloc> it's cool tech, it's a bit weird how it's implemented.
20:56:38 <lbragstad> hmm - ok, i think i can make that work
22:53:25 <lbragstad> #endmeeting
12:32:57 <yankcrime> lbragstad: so i did a comparison of the tokens issued before and after explicitly adding that federated user into the relevant group
12:33:13 <yankcrime> they both contain the right group and project
12:33:24 <lbragstad> yankcrime: hmm
12:33:27 <yankcrime> however, when it fails i do see:
12:33:29 <yankcrime> {"error": {"message": "Could not find token
12:34:00 <yankcrime> and 2018-04-04 10:20:54.373 18 DEBUG keystone.token.provider [req-720a8b5d-8686-4b56-89b5-7ab2f5900a8f - - - - -] Unable to validate token: User 4d1c38716d394e6097cf20d050f9d81e has no access to project 90fb2e3278344060a4b29008c30f1bc2
12:34:13 <yankcrime> that's basically the first bit in the log where it starts to go awry
12:34:49 <lbragstad> hmm
12:35:00 <lbragstad> which token provider are you using?
12:35:16 <yankcrime> uuid
12:36:00 <lbragstad> oh - i have a bug report for you
12:36:32 <lbragstad> https://bugs.launchpad.net/keystone/+bug/1758460
12:36:33 <openstack> Launchpad bug 1758460 in OpenStack Identity (keystone) "UUID (or any persistent) token providers unable to validate federation token" [Low,New]
12:36:58 <lbragstad> yankcrime: are you able to switch to fernet and test with that?
12:37:42 <yankcrime> damn, that looks exactly like it - i'd started to trawl the various bugs on launchpad but missed that one!
12:38:11 <yankcrime> yeah, it needs doing anyway so i'll press on with switching to fernet first
12:38:39 <lbragstad> yankcrime: let me know if you have any questions about fernet
12:38:53 <lbragstad> i can help
12:39:43 <yankcrime> lbragstad: thanks, much appreciated - been banging my head against a brick wall with this one for a couple of days now, good to know it's not me that's directly at fault ;)
12:40:02 <lbragstad> yeah.. it was just reported not too long ago
12:40:06 <yankcrime> and no worries, i should be ok - i have other deployments already on fernet
12:40:52 <lbragstad> but uuid support has been waning
12:41:25 <yankcrime> yup, surprised this particular instance was built with uuid tbh - probably an oversight
12:41:45 <lbragstad> i was just about ask if there was a particular reason it was being used
12:52:17 <yankcrime> this particular instance was deployed via kolla-ansible which still defaults to uuid
12:55:52 <lbragstad> ahh - gotcha
13:01:44 <yankcrime> https://review.openstack.org/#/c/549861/ fwiw
14:39:40 <gagehugo> o/
15:03:18 <knikolla> o/
15:07:21 <lbragstad> o/
15:17:05 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Fix mispelling of accommodate in install docs  https://review.openstack.org/558849
15:17:15 <gagehugo> easy change ^
15:30:36 <openstackgerrit> Harry Rybacki proposed openstack/keystone master: Update install guides  https://review.openstack.org/558079
15:43:57 <openstackgerrit> Harry Rybacki proposed openstack/keystone master: Update install guides  https://review.openstack.org/558079
16:31:02 <cmurphy> woops, forgot about policy meeting - I don't have rights on that project, looks like that honor belongs to these people https://review.openstack.org/#/admin/groups/1372,members
16:32:21 <lbragstad> oh - interesting
16:33:53 <lbragstad> there were a bunch of people in the session in dublin
16:34:09 <lbragstad> and i remember smcginnis being interested in it from a TC perspective
16:34:34 <lbragstad> i might do a drive by in the TC room just to see if it jars anyone's attention
18:10:02 <hrybacki> I think this looks better lbragstad https://review.openstack.org/#/c/523973/
18:10:13 <lbragstad> cool - i'll take another pass
18:33:42 <openstackgerrit> Merged openstack/keystone master: Fix mispelling of accommodate in install docs  https://review.openstack.org/558849
18:34:27 <openstackgerrit> Merged openstack/keystone master: Update install guides  https://review.openstack.org/558079
18:50:34 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add functional testing gate  https://review.openstack.org/531014
19:05:58 <openstackgerrit> Merged openstack/keystonemiddleware master: Remove kwargs_to_fetch_token  https://review.openstack.org/513273
19:07:55 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Move fernet doctor checks into tokens checks  https://review.openstack.org/527527
19:09:00 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Move fernet doctor checks into tokens checks  https://review.openstack.org/527527
19:22:42 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Decouple bootstrap from cli module  https://review.openstack.org/558903
19:22:51 <lbragstad> kmalloc: just got done beating my head against ^
19:23:26 <lbragstad> that was a fun scenic detour
19:23:43 <lbragstad> i should be able to get a patch up that bases the testing of the new keystone token model on that
19:24:21 <gagehugo> lbragstad that rips bootstrap out into it's own thing?
19:24:27 <lbragstad> yeah
19:24:51 <gagehugo> interesting
19:27:33 <lbragstad> yeah - i've been in the middle of a couple refactors where i need testing taht just gives me a base model to work from
19:27:45 <lbragstad> base model = admin user, project, system role assignments, default domain, etc...
19:27:55 <lbragstad> and bootstrap was written to do that for operators
19:28:01 <lbragstad> so i figured it might be useful to reuse for testing
19:28:16 <lbragstad> but the dependency injection stuff was kind of a pain for figure out
19:32:10 <lbragstad> s/for/to/
19:56:40 <lbragstad> hrybacki: took another pass
19:56:52 <lbragstad> just a few nits, otherwise i feel comfortable +1'ing it
20:33:17 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add new config option and setup for token keys  https://review.openstack.org/558918
21:37:55 <openstackgerrit> Gage Hugo proposed openstack/keystone master: WIP - Add LDAP-backed functional testing gate  https://review.openstack.org/558940
21:39:35 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add new config option and setup for token keys  https://review.openstack.org/558918
22:54:03 <openstackgerrit> Gage Hugo proposed openstack/keystone master: WIP - Add LDAP-backed functional testing gate  https://review.openstack.org/558940
04:07:38 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Decouple bootstrap from cli module  https://review.openstack.org/558903
07:41:26 <abhi89> do we have support in keystone to add periodic tasks? like we do have support in nova & other components
11:59:47 <lbragstad> o/
12:58:44 <knikolla> o/
13:00:21 <lbragstad> mornin'
14:01:21 <cburgess_> A
14:02:46 <root_743> hello, is it possible to specity a port when enabling ldap backend?
14:03:07 <root_743> I have ldap running behind haproxy and is running a different port than the default ones
14:05:54 <cmurphy> root_743: i think it should just be part of the url
14:06:07 <openstackgerrit> Merged openstack/keystone master: Expose a bug that list_limit doesn't work correctly  https://review.openstack.org/558150
14:06:10 <openstackgerrit> Merged openstack/keystone master: Fix list_limit doesn't work correctly for domain  https://review.openstack.org/558151
14:06:26 <root_743> cmurphy: thanks
14:31:32 <hrybacki> thanks lbragstad -- got some really good comments from Mel too! Misconceptions still exist :( system scope == global/god mode
14:31:45 <hrybacki> !=*
14:31:46 <lbragstad> oh - nice!
14:31:47 <openstack> hrybacki: Error: "=*" is not a valid command.
14:32:00 <hrybacki> heh openstack
14:32:10 <hrybacki> I just wanted a kiss, jeez
14:32:29 <lbragstad> lol
15:28:29 <mordred> lbragstad, cmurphy: so - if someone wants to get the complete version discovery picuture for a given cloud, they basically have to do this: http://paste.openstack.org/show/718491
15:28:50 <mordred> which uses a private method - and is also a bit yuck
15:29:56 <mordred> I'm going to poke at some options for exposing something a little better ...
15:31:02 <lbragstad> oh - sure
15:31:06 <lbragstad> that's handy
15:31:46 <cmurphy> mordred: fun
15:33:20 <mordred> I also need to finish the work on getting os-service-types integrated - so fair warning - there may be some keystoneauth patches coming from me :)
15:34:02 <cmurphy> my favorite
15:37:56 <mordred> cmurphy: I know how much you enjoy them
15:38:00 <lbragstad> that'd make a good doc contribution
15:40:15 <mordred> ++
16:11:59 <openstackgerrit> Colleen Murphy proposed openstack/keystoneauth master: add lower-constraints job  https://review.openstack.org/555625
16:12:00 <openstackgerrit> Colleen Murphy proposed openstack/keystoneauth master: Fix lower-constraints dependencies  https://review.openstack.org/559118
16:12:14 <cmurphy> crap, i only meant to submit one of those
16:14:27 <gagehugo> heh
16:38:49 <openstackgerrit> Monty Taylor proposed openstack/keystoneauth master: Expose version status in EndpointData  https://review.openstack.org/559125
16:39:03 <mordred> cmurphy, lbragstad: ^^ there's step one
16:51:08 <mordred> cmurphy, lbragstad: OOH. I may suck a little bit - it looks like we have a method that may do mostof this already \o/
16:53:36 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Introduce new TokenModel object  https://review.openstack.org/559129
16:54:03 <lbragstad> kmalloc: ^ i'm hitting a couple transients with dependency inject :( but that's what i have so far
17:03:10 <mordred> lbragstad, cmurphy: http://paste.openstack.org/show/718507/ and http://paste.openstack.org/show/718508/ (with that first ksa patch applied)
17:29:51 <lbragstad> mordred: wow - nice
18:10:36 <kmalloc> lbragstad: cool, will looks shortly
18:15:33 <openstackgerrit> Colleen Murphy proposed openstack/keystoneauth master: add lower-constraints job  https://review.openstack.org/555625
18:19:19 <cmurphy> mordred: hey ksa's queens branch is still borked http://logs.openstack.org/84/543684/1/check/openstacksdk-functional-devstack-tips/5c38f3a/job-output.txt.gz#_2018-04-04_16_55_29_473944 do you know why?
19:13:11 <mordred> cmurphy: the revision_number is different: http://logs.openstack.org/84/543684/1/check/openstacksdk-functional-devstack-tips/5c38f3a/job-output.txt.gz#_2018-04-04_16_55_29_476576
19:14:52 <mordred> cmurphy: I think that's something we fixed already in master branch of sdk ... https://review.openstack.org/#/c/544995/
19:15:02 <mordred> cmurphy: I think we just need to cherry-pick back to queens
19:15:24 <mordred> cmurphy: https://review.openstack.org/#/c/559150/
19:15:31 <mordred> cmurphy: cherry-pick submitted
19:18:54 <openstackgerrit> Monty Taylor proposed openstack/keystoneauth master: Add methods to get all of the version data  https://review.openstack.org/559154
19:31:52 <mordred> lbragstad, kmalloc, cmurphy: ^^ that needs tests, but it works against vexxhost public cloud - I've pushed it up for any initial feedback before I go writing unittests
19:32:10 <mordred> there's also some scrollback discussing it a little bit in #openstack-sdks
19:32:17 <lbragstad> cool - checking
20:53:29 <lbragstad> even with the uuid provide and sql driver gone, refactoring the token provider api is going to be difficult
20:53:46 <lbragstad> provider*
21:09:04 <gagehugo> yeah...
21:11:54 <lbragstad> i've tried slicing this refactor up about 3 different ways
21:12:19 <lbragstad> and 60% of the time, it's messy 100% of the time
21:43:30 <gagehugo> heh
06:07:02 <openstackgerrit> Nguyen Hai proposed openstack/keystone master: Follow the new PTI for document build  https://review.openstack.org/555196
08:05:38 <openstackgerrit> Colleen Murphy proposed openstack/keystoneauth master: add lower-constraints job  https://review.openstack.org/555625
11:24:43 <openstackgerrit> Monty Taylor proposed openstack/keystoneauth master: Add methods to get all of the version data  https://review.openstack.org/559154
11:25:11 <mordred> cmurphy: ^^ that should be ready for review now - and I even added tests
11:25:52 <cmurphy> mordred: fantastic
11:35:01 <openstackgerrit> Doug Hellmann proposed openstack/keystoneauth master: add lower-constraints job  https://review.openstack.org/555625
12:21:09 <fried_rice> ö/
12:37:39 <pooja_jadhav> fried_rice: Hi
12:37:48 <fried_rice> Hello
12:38:10 <pooja_jadhav> i want dicuss with you regarding keystoneauth session
12:39:41 <fried_rice> pooja_jadhav: Is this in reference to https://review.openstack.org/#/c/505764/ ?
12:40:01 <pooja_jadhav> correct
12:40:18 <fried_rice> Okay.  I remember seeing that go by, but I didn't actually review it.
12:40:32 <fried_rice> Let's just heads-up the folks who did, cause they're more likely to be able to help...
12:40:51 <fried_rice> kmalloc, cmurphy, mordred, cdent
12:40:59 <fried_rice> pooja_jadhav: Okay, proceed with your question please :)
12:41:15 <pooja_jadhav> fried_rice: Actually, i want use that split logger parameter in nova while call is going to cinder client.[1]https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L77
12:42:23 <pooja_jadhav> but how to use not getting still
12:42:39 <pooja_jadhav> :(
12:44:12 <fried_rice> pooja_jadhav: Okay, I'm reading over that patch, stand by...
12:44:34 <pooja_jadhav> fried_rice: Sure
12:48:25 <fried_rice> pooja_jadhav: Okay, it looks to me like there's no way to do this via ksa loading.
12:49:47 <pooja_jadhav> fried_rice: Yeah, but if we want to do.. then how can we do then?
12:50:32 <fried_rice> pooja_jadhav: If you want to try it out just to see if it will work the way you want it to, you can add:
12:50:33 <fried_rice> _SESSION._split_loggers = True
12:50:33 <fried_rice> after https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L82
12:51:16 <pooja_jadhav> ohk.. i will try and let u know
12:52:03 <fried_rice> pooja_jadhav: That's not going to be a real solution.  But if it does what you want, you could probably submit a patch to openstack/keystone to expose that via a conf option.
12:52:31 <fried_rice> pooja_jadhav: Then you wouldn't need to do anything to the nova code - you could just add the option in your conf file and restart the service.
12:56:45 <pooja_jadhav> ok
13:02:42 <openstackgerrit> Doug Hellmann proposed openstack/ldappool master: add lower-constraints job  https://review.openstack.org/555757
13:20:40 <openstackgerrit> Merged openstack/ldappool master: add lower-constraints job  https://review.openstack.org/555757
13:36:40 <openstackgerrit> Merged openstack/keystone master: Removal of deprecated direct driver loading  https://review.openstack.org/350815
13:36:55 <openstackgerrit> Nguyen Hai proposed openstack/keystone master: Fix incompatible requirement in lower-constraints  https://review.openstack.org/559334
13:38:22 <openstackgerrit> Nguyen Hai proposed openstack/keystone master: Fix incompatible requirement in lower-constraints  https://review.openstack.org/559334
13:43:41 <openstackgerrit> Colleen Murphy proposed openstack/keystoneauth master: add lower-constraints job  https://review.openstack.org/555625
13:49:14 <openstackgerrit> Merged openstack/keystonemiddleware master: Update links in README  https://review.openstack.org/557189
14:23:07 <lbragstad> cmurphy: an application credential token can't be used to change a user's password can it?
14:25:53 <cmurphy> lbragstad: it could if it has the user's original password https://developer.openstack.org/api-ref/identity/v3/index.html#change-password-for-user
14:26:28 <lbragstad> ahh
14:26:32 <lbragstad> ok - nevermind
14:26:56 <cmurphy> :)
14:27:01 <lbragstad> i thought i remember a restriction in there somewhere that might help with https://bugs.launchpad.net/keystone/+bug/1755874/
14:27:02 <openstack> Launchpad bug 1755874 in OpenStack Identity (keystone) "Ability to block users from changing passwords is missing in Kesystone v3" [Undecided,In progress] - Assigned to Pavlo Shchelokovskyy (pshchelo)
14:27:27 <lbragstad> i just read the use case they described...
14:29:12 <cmurphy> yeah we didn't any restrictions on that for app creds
14:29:58 <cmurphy> having a policy that users can't change their own passwords seems really weird and anti-security to me but i guess it's a real world use case we should allow
14:30:31 <lbragstad> mhmm
14:31:37 <lbragstad> unless there is a different workflow we can support somehow that doesn't require us to open that back up
14:32:20 <cmurphy> we can enforce password strength
14:32:47 <lbragstad> yeah
14:33:02 <cmurphy> that seems like the main thing they want
14:33:09 <lbragstad> sounds like the layer that sits on top of keystone does that too
14:33:24 <lbragstad> but i assume that's been around for a while if they implemented that for v2.0
14:34:14 <lbragstad> so - sure... some system creates a new user for some set of operations and a user *could* change the password directly using keystone
14:34:45 <lbragstad> but it won't buy them much because keystone can be configured to match the same password strength requirements that the layer on top of keystone requires?
14:35:37 <openstackgerrit> Nguyen Hai proposed openstack/keystone master: Follow the new PTI for document build  https://review.openstack.org/555196
14:36:13 <cmurphy> auditability i guess, if they're tracking password changes through this other layer and don't want to track them through keystone
14:37:26 <lbragstad> that could be true
14:38:41 <cmurphy> sounds like they have a system in place and we broke them, so we could either enable the change that unbreaks their system or we could encourage them to use our system
14:38:44 <cmurphy> ¯\_(ツ)_/¯
14:39:27 <lbragstad> sure - i'll leave a comment
14:40:02 <openstackgerrit> Monty Taylor proposed openstack/keystoneauth master: Add methods to get all of the version data  https://review.openstack.org/559154
14:41:36 <cmurphy> lbragstad: fyi i'll be on vacation all next week and hopefully not looking at my computer
14:41:49 <lbragstad> cmurphy: ack - thanks for the heads up
14:41:53 <lbragstad> cmurphy: i'm jealous ;)
14:42:09 <lbragstad> doing anything fun?
14:43:36 <cmurphy> meeting up with some friends to go camping in Iceland :D
14:44:08 <lbragstad> oh... wow
14:44:25 * lbragstad gives cmurphy his camera
14:44:30 <lbragstad> please take some pictures
14:44:38 <cmurphy> i plan to
14:44:40 <lbragstad> s/some/lots of/
14:44:45 <cmurphy> :)
14:44:47 <lbragstad> that's going to be amazing
14:45:12 <lbragstad> also - pretty hard to get onto irc while camping
15:03:16 <knikolla> cmurphy: have fun!
15:09:45 <openstackgerrit> Matthew Thode proposed openstack/keystone master: Fix incompatible requirement in lower-constraints  https://review.openstack.org/559334
15:09:45 <openstackgerrit> Matthew Thode proposed openstack/keystone master: Use the new pysaml2 constraints  https://review.openstack.org/558217
15:23:07 <openstackgerrit> Nguyen Hai proposed openstack/keystone master: Follow the new PTI for document build  https://review.openstack.org/555196
15:55:47 <gagehugo> o/
16:24:36 <kmalloc> lbragstad, cmurphy: so... there is a minor issue to fix the password-change API blocking bit
16:24:51 <kmalloc> and it is because @protected is wonky
16:25:02 * lbragstad dreads that refactor too
16:26:05 <kmalloc> the most immediate mechanism to block in that bug is use ninx/apache and put a block rule into http[s]://identity/v3/users/*/password
16:37:58 <kmalloc> lbragstad: oh man, i know how to fix the bug w/o code on our end
16:38:05 <kmalloc> we have minimum password change times.
16:38:44 <lbragstad> oh!
16:38:57 <kmalloc> right?!
16:39:06 * lbragstad checks the implementation
16:39:12 <kmalloc> yeah i am looking at that now
16:39:39 <kmalloc> oh.
16:39:46 <kmalloc> maybe we don't have that
16:39:51 <kmalloc> we might need to add that.
16:40:48 <lbragstad> yeah...
16:41:00 <lbragstad> we have unique last pass count
16:41:56 <kmalloc> lets just add minimum password change time
16:42:19 <kmalloc> rather than implement policy due to issues with @protected
16:42:24 <kmalloc> until that refactor lands
16:42:36 <lbragstad> what's the status of that refactor?
16:42:43 <lbragstad> i haven't had a chance to dig into it yet
16:43:01 <kmalloc> ... i don't know what the status is
16:43:18 <lbragstad> oh - no worries, i was just curious
16:43:48 <lbragstad> i've buried myself in the token provider refactor, but i think i need a break from that for a while
16:44:46 <kmalloc> i don't think much yeah
16:44:52 <kmalloc> s/don't think much
16:44:57 <kmalloc> annnnyway
16:45:05 <kmalloc> i don't think much has been done on the refactor
16:45:16 <kmalloc> i can try and dig in some, but, it's a beast of a refactor
16:45:29 <kmalloc> the issue is that it touches soooooo very much
16:45:40 <lbragstad> yeah :(
16:45:57 <kmalloc> let me start my NAS [old] -> NAS [new]
16:46:01 <kmalloc> transfer
16:46:08 <kmalloc> need to move ~4TB today
16:46:14 <kmalloc> and i'll start poking at the refactor
16:47:18 <lbragstad> sweet
16:47:37 <lbragstad> the refactors we have on our plate this release are _massive_
16:48:08 <kmalloc> yeah
16:48:12 <lbragstad> i started breaking the "rewrite keystone" patch into a series
16:48:16 <kmalloc> but it's all VERY good stuff that makes keystnoe better
16:48:18 <lbragstad> i failed, like 4 times
16:48:24 <kmalloc> honestly, i want to re-write a ton of keystone.
16:48:41 <kmalloc> once we break @protected, the flask re-write will be easy
16:49:06 <lbragstad> yesterday i pulled the entire new model into a separate change, which is cool.. but then i attempted to remove the KeystoneToken model
16:49:22 <lbragstad> so s/KeystoneToken/TokenModel/ everywhere in keystone
16:50:01 <lbragstad> and then went over like a kicking a hornets nest
16:50:35 <lbragstad> the problem is that we need to validate the token, then we pass it to the KeystoneTOken model to get an object
16:50:44 <lbragstad> but with the new model, we use composition
16:50:47 <kmalloc> right
16:51:09 <lbragstad> so - we validate the token and then handpick values to build a token model using TokenModel?
16:51:22 <lbragstad> which just defeats the purpose
16:51:31 <kmalloc> well, we know what the values from the fernet payload mean
16:51:42 <kmalloc> and we should be able to do composition with a "hey this is issued"
16:51:55 <kmalloc> vs "this is new"
16:52:01 <kmalloc> composition should work the same
16:52:05 <lbragstad> oh - yeah.. that'd mean building the model generation into the validation path right?
16:52:06 <kmalloc> it's a big change to the internals
16:52:08 <kmalloc> yeah
16:52:14 <lbragstad> right.. i didn't do that
16:52:19 <kmalloc> but that is the way to do it and how we discussed it
16:52:39 <lbragstad> all i did was introduce the new model and attempt to replace all usage of the old model with the new one
16:52:42 <lbragstad> which kinda backfired
16:52:44 <kmalloc> yeah
16:52:47 <lbragstad> and it got really messy
16:52:57 <lbragstad> i think we need to wait until validate_token returns an instance of TokenModel
16:53:00 <kmalloc> if anything do it inverse, compose validation 1st
16:53:04 <kmalloc> THEN everything else
16:53:15 <lbragstad> instead of making all the different places in keystone do composition on blank token models
16:53:23 <lbragstad> ++
16:53:24 <lbragstad> yeah
16:53:30 <lbragstad> i think that's what i learned yesterday
16:53:35 <kmalloc> and maybe just make a wrapper interface for the tokenmodel (new)
16:53:43 <kmalloc> so we can interface the token the same way elsewhere
16:53:46 <kmalloc> then drop the interface
16:54:15 <kmalloc> it's transitional code, but it would make it easy
16:54:29 <lbragstad> ok - so what if i do this
16:54:32 <kmalloc> and we can just drop the magic methods to see what all still references the old style
16:54:36 <lbragstad> 1.) propose the new token model
16:54:54 <lbragstad> 2.) rework the authentication API to construct token models and whatnot
16:55:07 <lbragstad> 3.) rework the validation path to construct token models
16:55:11 <kmalloc> 1a. implement interface for tokenmodel to work like current dict-model.
16:55:23 <lbragstad> how do you do that?
16:55:27 <kmalloc> basically some magic __getitem__ __setitem__
16:55:34 <lbragstad> one model accepts a dictionary and the other doesn't accept anything?
16:55:44 <lbragstad> s/?//
16:56:06 <kmalloc> just implement __getitem__ __setitem__ that knows the token dict format
16:56:09 <lbragstad> kt = token_model.KeystoneToken(token_data=token_data)
16:56:09 <kmalloc> and sets the values
16:56:22 <lbragstad> mmm
16:56:23 <kmalloc> then you can just use the KeystoneToken directly
16:56:29 <kmalloc> everywhere
16:56:33 <kmalloc> simple search/replace
16:56:36 <kmalloc> then rework bits to compose
16:56:39 <kmalloc> and direct access
16:56:47 <lbragstad> so - under the hood KeystoneToken proxies to TokenModel?
16:56:51 <kmalloc> no
16:57:08 <kmalloc> implement on KeystoneToken __getitem__ that knows what the format should be
16:57:15 <kmalloc> its the dict magic get method
16:57:52 <kmalloc> so KeystoneToken()['user'] etc returns dicts of the keystonetoken values
16:58:07 <kmalloc> and KeystoneToken()['user']['id'
16:58:11 <kmalloc> and KeystoneToken()['user']['id'] = XXXXX
16:58:15 <kmalloc> would set the ritght thin
16:58:26 <kmalloc> now that i think about it
16:58:31 <kmalloc> might be a massive amount of work
16:58:35 <lbragstad> yeah
16:58:39 <lbragstad> that's how i have things now
16:58:40 <kmalloc> maybe just a .to_dict()
16:58:42 <lbragstad> with the new model
16:58:49 <kmalloc> or _to_dict()
16:58:56 <lbragstad> it all @property methods
16:59:05 <kmalloc> and just render a token from the @propertys
16:59:24 <kmalloc> so keystonetoken.to_dict()[<normal_otken_lookup]
16:59:41 <kmalloc> since we already need the code to render the dicts
16:59:49 <kmalloc> for controller bits
17:00:01 <lbragstad> for exmple - https://review.openstack.org/#/c/555931/1/keystone/models/token_model.py@869
17:00:35 <kmalloc> eh, i think your proposed steps work fine
17:00:44 <lbragstad> so
17:00:47 <lbragstad> 1.) introduce new model
17:00:56 <lbragstad> 2.) make authentication path use new model
17:01:03 <lbragstad> 3.) make validation path use new model
17:01:15 <kmalloc> yep
17:01:36 <lbragstad> 4.) convert instances of KeystoneToken to use TokenModel (which is returned from PROVIDERS.token_provider_api.validate_token(token_id))
17:01:55 <lbragstad> 5.) remove duplicate model
17:02:04 <kmalloc> yep
17:02:13 <lbragstad> 6.) profit
17:02:29 <lbragstad> because everyone loves a good refactor, amiright?
17:12:42 <lbragstad> ok - i'm going to step away for lunch quick
17:18:21 <openstackgerrit> Matthew Thode proposed openstack/keystone master: Fix incompatible requirement in lower-constraints  https://review.openstack.org/559334
17:18:22 <openstackgerrit> Matthew Thode proposed openstack/keystone master: Use the new pysaml2 constraints  https://review.openstack.org/558217
17:22:43 <kmalloc> lbragstad: i'll propose the "minimum password change time" thing shortly
17:23:08 <kmalloc> lbragstad: and make it so -1 is a "never allowed",
18:10:52 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Introduce new TokenModel object  https://review.openstack.org/559129
18:21:08 <jessegler> #openstack-security
19:20:38 <kmalloc> lbragstad: almost have the password opt override added for min_password_age
19:21:14 <kmalloc> lbragstad: i am also implementing the case where if min_password_age is -1 in config, it makes password changes impossible.
19:21:39 <lbragstad> cool
19:22:07 <kmalloc> so, you will now have a useropt "min_password_age" which overrides the global conf only if it is greater than the global conf
19:22:15 <kmalloc> (basically, we only take the highest of the two values)
19:22:21 <kmalloc> EXCEPT if the value is -1 for either
19:22:32 <kmalloc> which means passwords may not be changed via the change_password API
19:24:54 <lbragstad> that makes se
19:24:56 <lbragstad> sense*
19:25:24 <lbragstad> knikolla: did you have the patch to replace non-existant users with @ while listing role assignments?
19:25:56 * lbragstad thinks something in our ldap implementation regressed
19:26:28 <lbragstad> i'm noticing something pretty strange
19:26:54 <lbragstad> if i have a user in ldap, i can create a role assignment for them, and everything is fine and dandy
19:27:16 <lbragstad> if i remove the user from ldap directly, i still see the role assignment
19:27:46 <lbragstad> if i attempt to remove the role assignment, i get an error saying the user can't be found, which makes sense
19:27:55 <lbragstad> but the role assignment doesn't go away
19:28:13 <lbragstad> and then after some period of time... the user name in the assignment list switches to @?
19:28:44 <knikolla> lbragstad:  that was a long time ago, yeah i think i did a patch for smth like that.
19:29:03 <knikolla> Changed names with empty string though
19:29:14 <knikolla> Not sure about the @
19:29:35 <lbragstad> http://paste.openstack.org/show/718621/
19:30:10 <lbragstad> i had a developers@Users group
19:30:16 <knikolla> Oh, because @ divides the username and domain
19:30:16 <lbragstad> and an lbragstad@Users user
19:30:23 <knikolla> Which both are empty strings
19:30:28 <lbragstad> yeah
19:31:31 <lbragstad> if i do `openstack role assignment list` i see the stale records
19:31:34 <lbragstad> with the IDs
19:31:43 <knikolla> I think my patch was only for listing, not deleting.
19:32:09 * knikolla is on the subway. Will be home in 10 mins or so.
19:32:55 <lbragstad> ok - no worries
19:50:08 <kmalloc> lbragstad: just finishing tests and then docs
19:53:10 <kmalloc> lbragstad: and we should really implement domain-specific overrides for all the DSS stuff.
19:53:46 <lbragstad> for PCI?
19:55:07 <kmalloc> https://www.irccloud.com/pastebin/c8D2uU2Y/
19:55:11 <kmalloc> lbragstad: yeah.
19:55:14 <kmalloc> pci-dss*
19:55:41 <kmalloc> lbragstad: once tests pass locally i'll toss in docs
19:55:44 <kmalloc> and a reno
19:55:55 <kmalloc> and we can tag that bug as closed
19:56:22 <kmalloc> the user resource options stuff is nice to work with.
19:57:32 <kmalloc> lbragstad: i'm pleased with the code just because adding a resource is straightforward
19:57:44 <kmalloc> s/resource/option
19:57:53 <lbragstad> right
19:57:57 <lbragstad> yeah - that is nice
19:58:54 <kmalloc> lbragstad: next challene, i need to standup keycloak or freeipa locally on my network so i can get my NAS to have consistent uids
19:59:26 <kmalloc> ayoung: i am frightened, i am actually thinking of standing up keycloak locally for my home network... just had to share (krb5 and all that)
20:00:02 <kmalloc> lbragstad: and i need to stand up some ansible for all my stuff *eek* this is like I am actually an engineer or something.
20:00:31 <kmalloc> lbragstad: annnd, i'm actually developing python on windows (gonna see if subsystem for linux will work for unit tests)
20:06:25 <lbragstad> 0.o
20:06:30 <lbragstad> python on windows?
20:07:07 <kmalloc> yep
20:07:11 <lbragstad> i know it's possible, but i always found it to be a pain sharing source between the development environment and the environment the project actually runs in
20:07:52 <kmalloc> oh, i just symlink: <WSL ROOT>/home/notmorgan/userprofile -> /mnt/c/User/<windowsuser>/Documents/ and have stuff under there
20:08:03 <kmalloc> i even have proper ssh-agent and all that running
20:08:05 <kmalloc> in bash
20:08:28 <kmalloc> i expect this will explode in my face
20:08:59 <lbragstad> lol
20:18:02 <knikolla> why is it still snowing in april...
20:25:37 <lbragstad> i just did something with ldap + keystone that technically shouldn't be possible
20:25:50 <lbragstad> ldap blows my mind some days
20:30:37 <gagehugo> knikolla right?!
20:39:45 <kmalloc> lbragstad: what did you do?
20:40:16 <lbragstad> this - https://bugs.launchpad.net/keystone/+bug/1751045
20:40:18 <openstack> Launchpad bug 1751045 in OpenStack Identity (keystone) "The removal of a role on a non existing group throws an error" [Undecided,In progress] - Assigned to Jose Castro Leon (jose-castro-leon)
20:40:23 <lbragstad> ^ i couldn't recreate it
20:40:29 <lbragstad> but i have no idea how not
20:40:53 <kmalloc> hmm
20:41:03 <kmalloc> what version of keystone is he using
20:41:11 <kmalloc> because shadow stuff might have 100% mitigated that
20:42:39 <lbragstad> we used to have a fix for getting that to work with users...
20:42:51 <lbragstad> well - we still have that fix
20:42:53 <kmalloc> right
20:43:26 <lbragstad> technically - it should blow up here https://github.com/openstack/keystone/blob/master/keystone/assignment/controllers.py#L403-L413
20:44:16 <lbragstad> but it doesnt?
20:44:45 <kmalloc> check to see if it's hitting shadow user stuff
20:44:56 <kmalloc> because the api.get would work if the group is shadowed
20:44:58 <kmalloc> right?
20:45:21 <kmalloc> lbragstad: also, it's funny, but unit tests are running.
20:45:23 <kmalloc> but man it's slow
20:46:13 <kmalloc> lbragstad: what was the invocation to run unit tests with the pretty output?
20:46:56 <lbragstad> added so logging to figure out what in the world is going on
20:47:07 <lbragstad> that's a good question, i'm not quite sure?
20:49:56 <ayoung> kmalloc, there is a reason all this technology exists, you know.
20:50:21 <kmalloc> ayoung: do you rtememebr the magic subunit-trace invocation w/ tox
20:50:32 <kmalloc> ayoung: this is driving me batty, i want to see the tests running
20:50:54 <ayoung> kmalloc, so I remeber  enable the venv and run the command tox runs
20:51:15 <kmalloc> there was something needed piping to like subunit-trace
20:52:16 <ayoung> oslo_debug_helper {posargs}
20:52:16 <ayoung> What is that?
20:52:38 <kmalloc> no idea
20:52:49 <ayoung> https://docs.openstack.org/os-testr/latest/user/subunit_trace.html
20:53:09 <ayoung> stestr run
20:53:33 <ayoung> something like that?
20:56:46 <kmalloc> ayoung: yeah, but i can't seem to get it to work.
20:57:42 <lbragstad> bah! caching bites me again
21:00:47 <lbragstad> once i disabled caching i was able to recreate it
21:00:53 <kmalloc> ayoung: it's working now
21:01:09 <kmalloc> lbragstad: AHA
21:01:12 <kmalloc> lbragstad: yeaaaah
21:01:19 <lbragstad> that group was being cached...
21:01:25 <kmalloc> lbragstad: rememebr, only 2 hard things in computer science
21:01:41 <kmalloc> lbragstad: naming things, caching, off-by-one-errors
21:01:49 <lbragstad> lol
21:01:51 <lbragstad> exactly
21:02:02 <kmalloc> i also like the async data version of that too
21:02:27 <kmalloc> holy crap. i'm... running 32 python test runners under windows subsystem for linux
21:02:30 <kmalloc> it's... working
21:02:58 <kmalloc> heh, load: 0.52
21:03:49 <kmalloc> lbragstad: i... i want another threadripper now.
21:04:43 <kmalloc> ... obligatory: COULD YOU IMAGINE A BEOWULF CLUSTER OF THOSE!?! *sigh* I'm ... making it clear how long i've lurked on the intertubes now
21:06:36 <kmalloc> ayoung: yeah, well i guess I'm back to having a far more complex home lab than expected ;)
21:07:47 <kmalloc> lbragstad: our tests are stupid chatty about debug things like scope-check failures
21:07:56 <kmalloc> lbragstad: we should make sure we aren't emitting that cruft unlessw e care
21:10:29 <lbragstad> yeah - i need to fix that
21:10:36 <lbragstad> not the chattyness
21:10:39 <lbragstad> the actual tests
21:10:47 <lbragstad> to do things  properly with scope
21:12:25 <ayoung> I actually built Beowulf clusters for a living. I cannot imagine a Beowulf cluster of those.
21:19:27 <kmalloc> ayoung: lol
21:19:46 <kmalloc> ayoung: i really do want to setup a few compute nodes that are all 1950x processors
21:19:51 <kmalloc> ayoung: it would be fantastic.
21:19:58 <kmalloc> but i don't have that kind of money
21:20:05 <ayoung> Running Windows?
21:20:17 <kmalloc> i run it locally for reasons of lazyness
21:20:29 <kmalloc> but i would run those nodes under linux
21:20:57 <ayoung> https://adam.younglogic.com/2012/03/shared-nothing-diskless-boot/
21:21:06 <kmalloc> yeah i've done that before
21:21:11 <kmalloc> it's fantastic.
21:21:29 <ayoung> Kinda want to do that for an OpenStack cluster
21:21:45 <kmalloc> that is how we managed all of our nodes at myspace [largely my design]
21:21:48 <kmalloc> and how we did it at blizzard
21:24:09 <kmalloc> ayoung: it wouldn't be too hard to do that for some of openstack, but parts need stateful storage [but i guess that could be outside of the root]
21:24:17 <kmalloc> notably libvirt is a culprit.
21:24:21 <kmalloc> and some cinder things
21:24:27 <ayoung> iSCSI for that
21:25:05 <kmalloc> sure.
21:25:52 <kmalloc> you'd have some wonky
21:25:56 <kmalloc> for some things
21:26:06 <kmalloc> but generally it would be doable for the API nodes themselves.
21:39:31 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Allow to remove a group deleted out-of-band from LDAP  https://review.openstack.org/546969
21:39:32 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Add a test for cleaning up stale group assignments  https://review.openstack.org/559435
21:43:31 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Add a test for cleaning up stale group assignments  https://review.openstack.org/559435
21:43:53 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Add a test for cleaning up stale group assignments  https://review.openstack.org/559435
22:13:59 <openstackgerrit> Morgan Fainberg proposed openstack/keystone master: Allow blockin users from self-service password change  https://review.openstack.org/559438
22:15:08 <openstackgerrit> Morgan Fainberg proposed openstack/keystone master: Allow blocking users from self-service password change  https://review.openstack.org/559438
22:15:59 <openstackgerrit> Morgan Fainberg proposed openstack/keystone master: Allow blocking users from self-service password change  https://review.openstack.org/559438
22:16:32 <kmalloc> lbragstad: ^ there ya go
22:19:31 <gagehugo> nice
22:19:36 <lbragstad> kmalloc: awesome - thanks for picking that up
22:35:00 <openstackgerrit> Merged openstack/keystone master: Fix incompatible requirement in lower-constraints  https://review.openstack.org/559334
22:57:53 <openstackgerrit> Morgan Fainberg proposed openstack/keystone master: Allow blocking users from self-service password change  https://review.openstack.org/559438
01:41:37 <prometheanfire> anyone around for a second review?
01:41:56 <prometheanfire> https://review.openstack.org/558217
02:18:16 <openstackgerrit> Nguyen Hai proposed openstack/keystone master: Follow the new PTI for document build  https://review.openstack.org/555196
02:41:32 <openstackgerrit> wangxiyuan proposed openstack/keystone master: Fix 500 error when deleting domain  https://review.openstack.org/558489
01:52:24 <openstackgerrit> wangxiyuan proposed openstack/keystone master: Fix 500 error when deleting domain  https://review.openstack.org/558489
03:10:57 <openstackgerrit> wangxiyuan proposed openstack/keystone-specs master: Hierarchical Unified Limits  https://review.openstack.org/540803
03:37:14 <openstackgerrit> wangxiyuan proposed openstack/keystone master: Fix 500 error when deleting domain  https://review.openstack.org/558489
06:32:07 <openstackgerrit> wangxiyuan proposed openstack/keystone master: Delete project limits when deleting project  https://review.openstack.org/538371
07:05:44 <openstackgerrit> wangxiyuan proposed openstack/keystone master: Do not return all the limits for GET request.  https://review.openstack.org/550736
08:07:47 <openstackgerrit> wangxiyuan proposed openstack/keystone master: Do not return all the limits for GET request.  https://review.openstack.org/550736
08:07:47 <openstackgerrit> wangxiyuan proposed openstack/keystone master: [WIP] Update limit Refactor  https://review.openstack.org/559552
16:14:13 <openstackgerrit> Nguyen Hai proposed openstack/keystone master: Follow the new PTI for document build  https://review.openstack.org/555196
02:38:28 <openstackgerrit> wangxiyuan proposed openstack/keystone master: Unified limit update APIs Refactor  https://review.openstack.org/559552
09:06:30 <hugokuo> Hi Team,
09:07:08 <hugokuo> While making a request to Swift, there's a header in the response WWW-Authenticate: Keystone uri='http://192.168.56.25:500/v2.0' `
09:07:21 <hugokuo> Is this returned by keystonemiddleware?
09:11:00 <wxy> hugokuo: yeah. https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L681-L683
09:11:55 <hugokuo> I'm reading RFC https://tools.ietf.org/html/rfc7235#section-2.1 and https://tools.ietf.org/html/rfc7230#section-3.2.6  . It looks like the string should be quoted by double quote instead of single quote?
09:22:36 <wxy> hugokuo: indeed. The RFC said that.
09:27:33 <hugokuo> kk
09:27:39 <hugokuo> I'll file a bug in LP
09:33:59 <hugokuo> Should it be in keystone's LP or some other place? https://launchpad.net/keystone
09:34:34 <wxy> https://launchpad.net/keystonemiddleware I think.
09:34:41 <hugokuo> thx man
09:35:24 <openstackgerrit> wangxiyuan proposed openstack/keystone master: Mark the idp's domain_id unique  https://review.openstack.org/559676
09:59:24 <ygl> hi all
09:59:57 <ygl> I am unable to delete other users' stacks as admin user
10:00:18 <ygl> can someone help me what exactly to modify in the heat policy.json file
10:16:04 <ygl> can anyone help me please
14:18:41 <openstackgerrit> Doug Hellmann proposed openstack/keystonemiddleware master: add lower-constraints job  https://review.openstack.org/555626
14:21:12 <openstackgerrit> Doug Hellmann proposed openstack/keystoneauth master: add lower-constraints job  https://review.openstack.org/555625
14:26:17 <openstackgerrit> Doug Hellmann proposed openstack/python-keystoneclient master: add lower-constraints job  https://review.openstack.org/556142
14:37:23 <kmalloc> Wxy, hugokuo : that may be python library representation. Remember ' and " are both acceptable. Is that actually the header on the wire or what ksm passes down via request. If it is the latter, the rfc doesn't matter, we're in Python and ' is the default.
14:38:50 <knikolla> o/
14:58:07 <hugokuo> kmalloc: It's not the later one as I know.
14:59:18 <lbragstad> relatively easy review here - https://review.openstack.org/#/c/558217/7
15:11:48 <lbragstad> knikolla: ty
15:11:54 <knikolla> lbragstad: that's a long != list.
15:13:05 <knikolla> lbragstad: this should be failing right? https://review.openstack.org/#/c/559435/
15:13:25 <knikolla> oh you rebased on top of the fix.
15:13:29 <knikolla> nice
15:14:37 <lbragstad> yeah - i was thinking about just merging those two patches together and writing a release note
15:15:06 <lbragstad> that'd be a pretty easy thing to propose and have ready for tomorrow
15:17:28 <knikolla> lbragstad: release note with the test or in a separate patch?
15:18:06 <lbragstad> knikolla: i was going to squash https://review.openstack.org/#/c/546969/4 and https://review.openstack.org/#/c/559435/3 and write a release note
15:18:11 <lbragstad> so it would all be in one pathc
15:18:13 <lbragstad> patch*
15:18:50 <knikolla> lbragstad: sounds good. ping me when you get that up so i can review, both look good.
15:19:35 <lbragstad> ++ i should be able to get to that after lunch for sure
15:19:40 <lbragstad> doing a bunch of bug triage now
15:19:57 <lbragstad> knikolla: i did see that new bug you opened about federated login after deleting a shadow user
15:20:13 <lbragstad> i wonder it that is cache related?
15:20:23 <hrybacki> lbragstad: have 15 mins to chat default role spec at like 1PM your time?
15:20:35 <lbragstad> hrybacki: sure
15:20:39 <hrybacki> lbragstad: ++
15:21:05 <lbragstad> my schedule is open today, so just ping me whenever
15:22:04 <knikolla> lbragstad: disabling caching and checking real quick.
15:23:37 <knikolla> lbragstad: yup, disabling caching fixed that.
15:23:50 <lbragstad> interesting
15:24:06 <lbragstad> so the shadow user api doesn't clear the cache when a shadow user is deleted?
15:24:15 <knikolla> looks like it.
15:24:21 <lbragstad> hmm
15:26:47 <knikolla> had some students discover it when playing around with mappings.
15:40:34 <lbragstad> kmalloc: hugokuo so is https://bugs.launchpad.net/keystonemiddleware/+bug/1762362 confirmed?
15:40:35 <openstack> Launchpad bug 1762362 in keystonemiddleware "[RFC] HTTP header field values should be quoted by double quote rather than single-quote" [Undecided,New]
15:59:44 <hugokuo> lbragstad: I filed it. That's confirmed the ksm returned single quote. But if it should follow the RFC will be determined by upstream core team.
16:04:00 <kmalloc> lbragstad: that might not be ksm, it might be an underlying liv
16:04:05 <kmalloc> Library
16:04:07 <kmalloc> *
16:04:39 <lbragstad> yeah - keystone doesn't use ksm?
16:04:58 <kmalloc> Not directly, afair
16:05:14 <kmalloc> I can check when o get home.
16:05:31 <kmalloc> But my guess is it isn't keystone or ksm.
16:06:20 <hugokuo> This line in ksm header_val = 'Keystone uri=\'%s\'' % self._auth_uri
16:06:49 <hugokuo> I tested it by change the code to have double quote and it works as expected.
16:08:43 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Allow cleaning up non-existant group assignments  https://review.openstack.org/546969
16:14:48 <lbragstad> knikolla: ^
16:17:36 * lbragstad breaks for lunch
16:23:02 <yankcrime> lbragstad: some good news for your return - switching keystone's token provider out from uuid to fernet solved my federation-related woes
16:23:09 <yankcrime> thanks again for the help!
16:25:57 <openstackgerrit> Johannes Grassler proposed openstack/keystone-specs master: Add capabilities to application credentials  https://review.openstack.org/396331
16:59:02 <kmalloc> yankcrime: i am glad to hear that.
16:59:20 <kmalloc> yankcrime: i figured that would work for you, but good for confirmation
17:01:11 <kmalloc> wow, we screwed that up: Www-Authenticate: Keystone uri='http://192.168.56.25:5000/'
17:01:19 <kmalloc> that looks... wrong somehow
17:01:23 <kmalloc> not just in the ' vs "
17:04:28 <kmalloc> hugokuo: if you want to propose a fix for ' vs " (and tests) we'll happily take / review it
17:08:49 <lbragstad> yankcrime: awesome! let us know if you run into any other snags :)
17:09:07 <kmalloc> lbragstad: yeah fixing the quotes is the corrective action in ksm
17:10:16 <lbragstad> kmalloc: nice
17:10:42 <lbragstad> i confirmed the bug
17:10:56 <kmalloc> lbragstad: https://review.openstack.org/#/c/559438/ is ready for eyes/merging
17:26:36 <lbragstad> kmalloc: oh - sweet
17:26:40 <lbragstad> that was on my list today
17:31:27 <openstackgerrit> Doug Hellmann proposed openstack/keystoneauth master: add lower-constraints job  https://review.openstack.org/555625
17:32:51 <kmalloc> jgrassler: o/ need a minor fix for the capabilities
17:33:00 <kmalloc> jgrassler: but... it can be a follow up
17:57:25 <lbragstad> i need to review that today, too
18:05:20 <hrybacki> lbragstad: still free? :)
18:24:03 <openstackgerrit> Merged openstack/keystone master: Use the new pysaml2 constraints  https://review.openstack.org/558217
19:32:55 <ayoung> lbragstad, hrybacki kmalloc so as prep for my talk at summit...I wrote a second article on Istio and Keystone, this time looking into RBAC.  https://adam.younglogic.com/2018/04/comparing-keystone-and-istio-rbac/  this is on top of what I wrote before https://adam.younglogic.com/2018/04/comparing-istio-and-keystone-middleware/
19:44:14 <ayoung> and knikolla and cmurphy of course...just didn't see you actively posting.  But Everyone....
19:48:20 <knikolla> ayoung: i'll have a look. never found the time to dive into istio though i've heard it mentioned to me multiple times.
19:48:49 <ayoung> knikolla, pretty sure it is "keystone middleware for Kubernetes based services"
19:49:34 <knikolla> ayoung: not limited to that though
19:49:34 <ayoung> plus a few other things, like a mutual Cert validation layer, but its the RBAC part that interests me
19:55:04 <knikolla> and it is the other part that interests me :)
19:55:39 <lbragstad> ldap developer docs available https://docs.openstack.org/devstack/latest/guides/devstack-with-ldap.html
20:15:07 <hrybacki> ayoung: domain scope was pulled from the spec -- look back in the comments for more detail about that
20:15:17 <hrybacki> tl;dr there is no 'real' domain scope (yet)
20:15:18 <ayoung> hrybacki, it is in the examples
20:15:54 <hrybacki> hanging chad, needs to be pulled as well. Good catch
20:16:04 <ayoung> hrybacki, no
20:16:21 <ayoung> hrybacki, domain scope needs to be put back in there, or domains themselves need to go away
20:16:43 <hrybacki> ayoung: domain scope will come, and we will add it then. This was discussed in length
20:16:49 <ayoung> Horizon now has support for domain scoped tokens
20:16:54 <ayoung> it is a real thing
20:17:29 <hrybacki> I'll let cmurphy weigh in here. We can emulate domain scope but it's not actually domain scope
20:17:29 <ayoung> I'm more concerned about the Implied Roles comment
20:17:46 <ayoung> hrybacki, cloudsamplev2 is in wide usage
20:17:56 <ayoung> domain scope is real, its just not in default policy
20:18:28 <ayoung> http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json
20:19:45 <ayoung> hrybacki, so I'd recommend putting domain scoped back in, and you can caveat it that way
20:20:51 <hrybacki> ayoung: that was my literal approach but I was dissuaded by cmurphy and the team agreed
20:21:14 <ayoung> hrybacki, you were right and they were wrong.
20:21:19 <ayoung> :)
20:21:28 <hrybacki> ayoung: I disagree with you know and past Harry :P
20:22:00 <ayoung> hrybacki, so, if the goal is to make Domain scoping go away, I would be in full support
20:22:23 <ayoung> however, users and groups are not owned by projects, and I absolutetly should not need a System scoped token to create either
20:23:04 <ayoung> I mean, I know domains were a mistake
20:23:11 <ayoung> but they are not one was can sweep under the rug now
20:23:15 <hrybacki> All arguments I raised, the team discussed, and rejected
20:23:38 <hrybacki> I agree with them now (to be clear)
20:23:47 <kmalloc> domain scoping can be sidelines
20:23:52 <kmalloc> we cannot remove it/make it go away
20:23:56 <kmalloc> because it is part of the v3 api
20:24:16 <kmalloc> sidelined* and/or suggested to "not be used"
20:24:45 <hrybacki> WRT implied roles. Our aim (at the project level) is make these alterations by way of policy file changes that move into policy-in-code after being vetted
20:25:57 <hrybacki> simple, quick, and easily modifiable. Customers will /really/ start to flip if we don't offer these things soon
20:26:14 <hrybacki> implied roles were also discussed in length (during one of the office hours sessions IIRC)
20:28:03 <ayoung> hrybacki, it was a tool built explicitly to aid in this problem
20:29:12 <hrybacki> ayoung: that doesn't mean it's right for right now
20:29:35 <hrybacki> we really need to keep this as simple as possible right now
20:30:58 <hrybacki> maybe I misunderstand how you are advising we use them here. But minor mods to policy files is acceptable other projects and the team after a lot of discussion at PTG
20:31:17 <ayoung> hrybacki, simple:
20:31:22 <ayoung> create 2 rules
20:31:27 <ayoung> admin implies memember
20:31:33 <ayoung> member implies reader
20:31:39 <ayoung> or auditor whatever it is called
20:31:48 <ayoung> tag the API with the Lowest level role
20:31:54 <ayoung> no need for the OR statements
20:32:15 <ayoung> for project scoped apis, you still need the right system scoped role to get at it
20:32:28 <hrybacki> I see what you are suggesting now. Create the implications during the bootstrap process and keep the policy files clean as possible?
20:32:35 <ayoung> so you could give someone system:auditor and they can read all of the auditor roles
20:32:39 <ayoung> yep
20:32:50 <hrybacki> okay, I have to run to an appt. I'm gonna reflect on this while I walk
20:33:12 <ayoung> cool
20:35:32 <kmalloc> lbragstad: responded to your comments
20:35:39 <kmalloc> need some more feedback before I post an updated patch
20:39:08 <lbragstad> kmalloc: ack -
20:39:14 <lbragstad> thoughts on https://bugs.launchpad.net/keystone/+bug/1729933 ?
20:39:15 <openstack> Launchpad bug 1729933 in OpenStack Identity (keystone) "region update doesn't update extras" [Undecided,In progress] - Assigned to David Lyle (david-lyle)
20:39:56 <ayoung> kmalloc, do you honestly thinkg there is an alternative to doing domain scoped for users and groups?  DO we honestly want to make people system admins in order to add new users?  Adding users should be cheap...its role assignements that are dangerous.
20:51:25 <kmalloc> ayoung: no, i am not advocating for anything it was just a comment
20:51:32 <ayoung> cool
20:51:40 <kmalloc> ayoung: we can sideline we can say don't do this, we cannot remove the functionality from keystone
20:51:55 <kmalloc> lbragstad: ugh, extras
20:52:00 <kmalloc> lbragstad: sigh
20:52:11 <lbragstad> =/ yeah...
20:52:18 <ayoung> kmalloc, lbragstad one topic I want to discuss at the summit is multi-site OpenStack deployements where the different regions/sites are on different versions of OpenStack.
20:52:45 <kmalloc> lbragstad: if it never worked for region, even if the table exists, i'll -2 any added extras support
20:52:48 <ayoung> Something like the hub-and-spoke model, where a central keystone just forwards to another keystone
20:53:09 <kmalloc> ayoung: theoretically possible with federation
20:53:17 <kmalloc> realistically... unknown
20:53:43 <lbragstad> i think the domain scope thing with users and group can still happen, i don't expect it to be system-scope for ever
20:53:56 <lbragstad> if you're referencing the default roles specification
21:03:13 <kmalloc> lbragstad: just commented on the bug
21:03:27 <kmalloc> lbragstad: basically if we can show regions EVER supported "Extras" we need to add it back in
21:03:38 <kmalloc> else, nope, nope, not doing it, no, nope, no thanks
21:03:53 <kmalloc> though I am not opposed to a Region['VendorData'] like thing
21:04:05 <kmalloc> that is explicitly outlined as deployment specific
21:04:22 <kmalloc> [AND is a little smarter, like Resource-Opts is, where a "None" clears the value]
21:07:14 <ayoung> kmalloc, I think there is a little bit more to it than just Federation.  I'll try to write up a decent agenda.
21:07:30 <ayoung> lbragstad, are we going to have breakout rooms for design, or has all of that been conceded to the PTGs?
21:17:59 <lbragstad> ayoung:  i don't think so
21:18:08 <lbragstad> i think the rooms we get are for large discussions
21:18:15 <lbragstad> like cross-project things
21:18:21 <lbragstad> or feedback sessions
21:18:34 <lbragstad> e.g. i don't think we'd get a room to work on keystone-specific things
21:18:46 <lbragstad> they're also time-boxed to 40 minutes or so
21:21:23 <ayoung> lbragstad, OK, so multi-site is a cross project topic.
21:21:53 <ayoung> lbragstad, what I am realizing now is that even if there are multiple openstacks in a single org, they need to be only loosly-unified.  If that makes sense
21:22:04 <ayoung> like, maybe you only upgrade one at a time
21:22:16 <ayoung> but you still want a unified Keystone scheme for them
21:22:31 <kmalloc> there is no reason you can't use a bleeding edge keystone with an ancient <everything else>
21:22:36 <ayoung> and thus having a database sync
21:22:39 <kmalloc> and regions can be other deploys.
21:22:48 <ayoung> kmalloc, heh yes there is. and it has n othing to do with Keystone
21:22:50 <kmalloc> i think that is how most orgs end up doing it
21:22:54 <ayoung> and everything to do with our deployment tool
21:23:13 <kmalloc> this sounds like an inflexible deployment tool :P
21:23:25 <kmalloc> but yeah, that is how i've seen folks crack that nut
21:23:30 <kmalloc> it's still not pretty
21:23:34 <ayoung> but I think having DB sync between version of Keystone is a reasonable design discussion
21:23:46 <kmalloc> i.. well
21:24:01 <kmalloc> i think this sounds kindof awful
21:24:05 <ayoung> like, how to make a deployment work when one part is on Q and one is on R and one is on S
21:24:19 <ayoung> nAH
21:24:24 <kmalloc> everyone use "S" keystone *shiftyeyes*
21:24:39 <ayoung> THey named it for Brian?
21:24:57 <ayoung> https://www.linkedin.com/in/brian-stein-7b659b/
21:24:59 <kmalloc> in all honesty, i would refrain from referencing "db" anywhere in it.
21:25:22 <kmalloc> simply so as to circumvent the convo around db-replication :P
21:25:45 <ayoung> kmalloc  yep
21:25:57 <kmalloc> so, what I *think* you're looking for is something we sortof proposed in the past.
21:26:03 <ayoung> kmalloc, the other convo I want to have is "how do I delete a project without orphaning the majority of my resources"
21:26:15 <ayoung> ah...pause on mine...go on
21:26:27 <kmalloc> something that may intercept a keystone call and replicate it [public interface] to other keystones via rest.
21:26:37 <kmalloc> and some mechanism to "replay"/"catchup"
21:28:10 <ayoung> thing is, our REST Apis are not create firendly, as they tend to allocate new IDs
21:28:14 <kmalloc> but- it wont scale out.
21:28:29 <ayoung> we'd want to make sure that a new Create is done with the ID from the server that has the right to create that record
21:28:36 <kmalloc> i was actually thinking of something that would be a dogpile proxy, and it would talk to other dogpile proxies
21:28:44 <kmalloc> originally
21:29:24 <kmalloc> but it has a lot of potential issues.
21:29:34 <ayoung> My original view was that, in a multi-keystone deployment, each keystone server would be canonical for a subset of domains, and could write data for those, but only read data for other domains
21:29:47 <ayoung> I'm not wedded to that impl, but I think the bones is
21:29:54 <kmalloc> so you'd capture at just below the manager layer, and replicate that out to the other keystones
21:30:00 <ayoung> "what data can I write locally, and what do I need to sync"
21:30:41 <ayoung> I'm not sure where capture would happen.  I think I'd be pretty flexible on the impl
21:31:05 <kmalloc> it would need to be below the manager i think..
21:31:31 <kmalloc> but there are a lot of issues with "what if someone did an update for some new data that R dodens't know about via the S keystone and that is forwarded"
21:31:42 <kmalloc> i think it's kindof going to be full of awful pitfalls/
21:33:13 <ayoung> kmalloc, right.  But on the other hand, we can map it out, and at least start sketching out a solution
21:33:30 <ayoung> We couild even say "it starts with K2K
21:33:44 <ayoung> "but we need to keep data in sync"
21:34:50 <kmalloc> i'd need to talk more, but honestly, i think k2k still solves 95-99% of what you're asking for
21:35:04 <kmalloc> and really only has a lower bound of minimum supportable keystone
21:46:48 <ayoung> kmalloc, I'm OK with K2K as the basis.  Just want to map out the full use cases, including how to automate project creation and mapping.
07:00:26 <openstackgerrit> wangxiyuan proposed openstack/keystonemiddleware master: Double quote www_authenticate_uri  https://review.openstack.org/559925
12:29:24 <openstackgerrit> Johannes Grassler proposed openstack/keystone-specs master: Add capabilities to application credentials  https://review.openstack.org/396331
14:38:58 <knikolla> o/
14:47:03 <gagehugo> o/
15:12:28 <hrybacki> o/
15:35:27 <lbragstad> o/
15:43:32 <hrybacki> lbragstad: FYI I'm gonna be in-and-out all afternoon (tons of meetings I'm getting pulled into today)
15:44:01 <lbragstad> hrybacki: thanks for the heads up
15:45:00 <hrybacki> ack. I'll be in the weekly meeting though
15:45:48 <lbragstad> cool
15:59:33 <lbragstad> reminder that the keystone team meeting is starting in a minute in #openstack-meeting-alt
15:59:38 <SamYaple> this might be an olso.log question.. but im noticing when running keystone behind uwsgi that when it spits out the DEBUG running config the name of application is 'uwsgi' in logging
15:59:48 <SamYaple> on glance, it is 'glance.common.config'
16:00:16 <SamYaple> so i have to filter for (^keystone|^uwsgi) on keystone, but only (^glance) for glance
16:00:45 <SamYaple> is there anything i can do to get the module to report something a bit more 'keystone' named
16:01:45 <kmalloc> SamYaple: it is likely uwsgi is configurable
16:01:49 <kmalloc> SamYaple: i haven't looked though
16:02:49 <SamYaple> kmalloc: my knowledge of uwsgi as relates to python logging approaches zero, do you have a param or option for me to start searching for in uwsgi to control the name?
16:03:00 <SamYaple> im running glance behind uwsgi as well, same configuration
16:03:16 <kmalloc> ah
16:03:35 <kmalloc> you might need to supply a keystone-specific uwsgi with logging prefix or some such
16:03:46 <kmalloc> i'll look post meeting/lunch
16:04:08 <kmalloc> and see if i can help you. FWIW, I'm setting up an openstack for my home network today, so I'll specifically poke at that
16:04:57 <SamYaple> ok yea, this is really a non-critical issue
16:05:05 <SamYaple> im just working on openstack logging right now for my company
16:05:15 <SamYaple> appreciate the comments
16:16:09 <openstackgerrit> Merged openstack/keystone-specs master: Add capabilities to application credentials  https://review.openstack.org/396331
16:31:35 <gagehugo> I should be back after awhile, may not make the rest of the meeting though
17:01:20 <openstack> lbragstad: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
17:01:30 <lbragstad> #endmeeting