Thursday, 2016-06-02

stevemari figure i'll let you do this one, just copy the previous release yaml, slap on 10.0.0.0b1 and pick the latest sha00:00
jamielennoxcurrent master is 38d3c73888d46a330d8043e230e5bd4cc6f7b6b4 - i don't assume there's any point waiting for whatever to merge for b100:01
*** lhcheng has quit IRC00:01
stevemarjamielennox: correct, and you can remove the release notes url, since it doesn't exist yet00:02
jamielennoxstevemar: we don't tag middleware, client and auth as part of this release?00:03
stevemarjamielennox: nah, and i just did those before i left00:03
jamielennoxtheoretically they're release independant but this might be different00:04
jamielennoxstevemar: we were going to do another ksa this week00:04
jamielennoxshould check to see if that merged..00:04
stevemarjamielennox: i did all the libs 2 weeks ago: https://review.openstack.org/#/c/317837/00:04
patchbotstevemar: patch 317837 - releases - release keystone libraries (MERGED)00:04
stevemarjamielennox: oh sure, if someone wants a new ksa, that is usually not an issue00:04
*** amrith is now known as _amrith_00:05
jamielennoxstevemar: yea, yolanda has been trying to get an up to date one with the betamax stuff in it for infra00:05
stevemarjamielennox: no one has requested a new ksa release00:05
stevemarlooking at https://review.openstack.org/#/q/project:openstack/releases anyway00:05
jamielennoxwe were waiting for https://review.openstack.org/#/c/321814/ to merge00:05
patchbotjamielennox: patch 321814 - keystoneauth - Make the kerberos plugin loadable00:05
stevemarah00:06
stevemarfi-lgtm ?00:06
jamielennoxstevemar: probably - if it's broken it's no more broken than not existing at all00:06
stevemaryep00:06
stevemari'll +A00:06
jamielennoxayoung had said he would test00:06
notmorganstevemar: https://pbs.twimg.com/media/CjxOMODUoAE5Mvl.jpg:large00:07
stevemarjamielennox: people can blame me if something goes wrong00:07
notmorganstevemar: too late i already blame you00:08
stevemarnotmorgan: bring it on!00:08
notmorganstevemar: even if it doesn't go wrong00:08
notmorganstevemar: /me is formatting OSSA email.00:08
jamielennoxdone: https://review.openstack.org/#/c/324143/00:09
patchbotjamielennox: patch 324143 - releases - Release keystone 10.0.0.0b100:09
*** sdake_ is now known as sdake00:19
*** ayoung has joined #openstack-keystone00:22
*** ChanServ sets mode: +v ayoung00:22
openstackgerritSteve Martinelli proposed openstack/keystoneauth: Make the kerberos plugin loadable  https://review.openstack.org/32181400:23
stevemarjamielennox: you can make a ksa release with SHA f7766ebb37d34d0a4185fa8405e4799d5cb91bcd00:23
jamielennoxstevemar: was going to wait for the merge - why'd you re-propose?00:24
stevemarjamielennox: it wasn't gating/queued according to zuul00:24
stevemarand jenkins didn't trigger anything00:24
stevemarre-basing / re-proposing just kinda kicked it in the pants00:24
*** dan_nguyen has quit IRC00:25
stevemarjamielennox: anyway, the SHA shouldn't change, you can create a new patch with that one safely00:27
*** diazjf has joined #openstack-keystone00:29
stevemarjamielennox: nooo it failed tests now00:29
*** BjoernT has quit IRC00:30
*** diazjf has quit IRC00:34
*** dan_nguyen has joined #openstack-keystone00:46
ayoungrodrigods, you figure out what "Only single element list is acceptable" means?00:51
*** KarthikB has joined #openstack-keystone00:55
ayoungself._first(idp_response_consumer_url)00:56
ayoung  returns []00:56
ayoungjdennis, ^^00:56
openstackgerritRon De Rose proposed openstack/keystone: Shadow LDAP and custom driver users  https://review.openstack.org/32360201:06
*** woodster_ has quit IRC01:08
*** BjoernT has joined #openstack-keystone01:09
*** BjoernT has quit IRC01:14
*** raddaoui has quit IRC01:17
*** KarthikB has quit IRC01:17
*** EinstCrazy has joined #openstack-keystone01:25
*** sheel has joined #openstack-keystone01:28
*** amit213 has joined #openstack-keystone01:39
*** amit213 has quit IRC01:41
*** amit213 has joined #openstack-keystone01:44
*** dan_nguyen has quit IRC01:45
*** KarthikB has joined #openstack-keystone01:46
*** sdake has quit IRC01:49
*** KarthikB has quit IRC01:50
*** tlbr has quit IRC01:50
*** tlbr has joined #openstack-keystone01:51
*** rmizuno_ has quit IRC01:58
*** roxanaghe has joined #openstack-keystone02:04
*** spandhe has quit IRC02:08
*** roxanaghe has quit IRC02:09
*** eszxy has joined #openstack-keystone02:10
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Change password requirements  https://review.openstack.org/32015602:15
openstackgerritRon De Rose proposed openstack/keystone: Add password table columns to meet PCI-DSS change password requirements  https://review.openstack.org/31428402:16
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Change password requirements  https://review.openstack.org/32015602:16
*** sdake has joined #openstack-keystone02:16
*** sdake has quit IRC02:18
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Change password requirements  https://review.openstack.org/32015602:26
*** itisha has quit IRC02:30
*** richm has quit IRC02:31
*** KarthikB has joined #openstack-keystone02:36
ayoungjamielennox, ECP Federation Auth plugin...works getting an unscoped token, but does not seem to beaware that it needs to request a scoped token.   THis is OSP7, so....Liberty.  Sound like a known issue?02:37
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Change password requirements  https://review.openstack.org/32015602:42
ayoungnotmorgan, http://git.openstack.org/cgit/openstack/keystoneauth/tree/setup.cfg  where is the SAML plugin?02:42
*** KarthikB_ has joined #openstack-keystone02:52
*** KarthikB has quit IRC02:55
openstackgerritSteve Martinelli proposed openstack/keystoneauth: Make the kerberos plugin loadable  https://review.openstack.org/32181402:59
*** roxanaghe has joined #openstack-keystone03:04
*** julim has joined #openstack-keystone03:05
*** diazjf has joined #openstack-keystone03:06
*** diazjf has quit IRC03:06
*** spandhe has joined #openstack-keystone03:07
*** roxanaghe has quit IRC03:09
*** KarthikB_ has quit IRC03:12
*** KarthikB has joined #openstack-keystone03:12
*** KarthikB has quit IRC03:17
*** spandhe_ has joined #openstack-keystone03:21
*** dan_nguyen has joined #openstack-keystone03:22
*** spandhe has quit IRC03:23
*** spandhe_ is now known as spandhe03:23
*** dan_nguyen has quit IRC03:29
*** neophy has joined #openstack-keystone03:29
*** dan_nguyen has joined #openstack-keystone03:30
*** rderose has quit IRC03:34
*** links has joined #openstack-keystone03:35
*** julim has quit IRC03:36
openstackgerritRon De Rose proposed openstack/keystone-specs: Drop Support for Driver Versioning  https://review.openstack.org/32408103:36
*** clenimar has quit IRC03:41
*** gerhardqux has quit IRC03:43
stevemarhenrynash_: did you finally setup a bouncer?04:00
openstackgerritMerged openstack/keystone: Fix credentials_factory method call  https://review.openstack.org/32336004:01
*** TxGVNN has joined #openstack-keystone04:01
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/32253904:04
*** roxanaghe has joined #openstack-keystone04:05
stevemarjamielennox: can you verify i didn't do something crazy between ps6 and ps7? https://review.openstack.org/#/c/321814/04:07
patchbotstevemar: patch 321814 - keystoneauth - Make the kerberos plugin loadable04:07
*** roxanaghe has quit IRC04:09
jamielennoxstevemar: so there's a real concern of that patch that when you iterate through all the plugins it loads all the modules and requests_kerberos isn't available04:10
jamielennoxi thought i checked it once before but it may be an actual problem04:10
jamielennoxi don't think crinkle is waiting on it?04:11
stevemarjamielennox: i don't think she is04:11
stevemarjamielennox: we can release without it04:11
stevemarjamielennox: i'm not sure i understand your previous statements... ?04:12
jamielennoxstevemar: right, then figure out if it's a real problem04:12
*** TxGVNN has quit IRC04:12
stevemarjamielennox: the patch that introduced the entry point check is here; https://review.openstack.org/#/c/319980/04:12
patchbotstevemar: patch 319980 - keystoneauth - Check that all defined entry points can be loaded (MERGED)04:12
crinkleo/04:13
jamielennoxstevemar: so there is a function that loops through all plugins in the system via entrypoint04:13
stevemaryep..04:13
stevemarcrinkle: o/04:13
stevemarcrinkle: taking a break from pycon? :)04:13
crinklestevemar: yeah just for a bit :)04:13
jamielennoxstevemar: if you import say requests_kerberos that requires an extras install then the import might get triggered without the package being installed04:13
stevemareveryone is at pycon or mesoscon and i'm am home changing diapers >.<04:13
stevemarjamielennox: i think i get what you're saying04:14
stevemarjamielennox: do you have a suggestion / alternative to what i proposed?04:15
jamielennoxcrinkle: are you waiting for that kerberos plugin for something or just fixing the bug?04:15
jamielennoxstevemar: i hven't seen you change anything04:15
crinklejamielennox: i was just bug stomping04:15
stevemarjamielennox: i did this: https://review.openstack.org/#/c/321814/6..7/keystoneauth1/tests/unit/loading/test_entry_points.py04:16
patchbotstevemar: patch 321814 - keystoneauth - Make the kerberos plugin loadable04:16
jamielennoxcrinkle: cool, we were holding a KSA release because it was close but if you're not needing it we can release without it and wait till next one04:16
stevemarjamielennox: in order to resolve this: http://logs.openstack.org/14/321814/6/check/gate-keystoneauth-python34/3f02584/testr_results.html.gz04:16
*** dan_nguyen has quit IRC04:16
crinklejamielennox: fine with me04:17
*** roxanaghe has joined #openstack-keystone04:17
jamielennoxstevemar: yep, but the bug fail is an actual problem04:19
jamielennoxbecause the kerberos plugin will now show up when you find all available plugins04:19
jamielennoxand if you don't have requests_kerberos installed you will get an error04:19
jamielennoxi think we might need to do some importerror checking04:20
stevemarjamielennox: ahhhh i get what you mean04:20
jamielennoxlike in the kerberos plugin on importerror set a flag04:20
stevemaryou don't want that EP showing up at all if they just did pip install keystoneauth (no kerb)04:20
jamielennoxand then in the loadable we do if not imported then don't let people instantiate the plugin04:20
jamielennoxstevemar: not sure if we have that choice04:21
jamielennoxstevemar: everything in the setup.cfg is going to show up anyway04:21
jamielennoxbut we need to throw an error in --os-auth-type kerberos before seeing the importerror04:22
*** ayoung has quit IRC04:22
*** patchbot has quit IRC04:22
*** patchbot has joined #openstack-keystone04:22
*** nonameentername has quit IRC04:23
*** dmellado has quit IRC04:24
*** brad_behle has quit IRC04:25
*** nonameentername has joined #openstack-keystone04:25
stevemarjamielennox: btw https://review.openstack.org/32420204:25
jamielennoxstevemar: cool, i was about to do that04:25
stevemarjamielennox: i have a few spare cycles now :P04:26
stevemari see lbragstad went on a review spree04:27
*** dmellado has joined #openstack-keystone04:27
lbragstadstevemar yes sir - dev on capstone is slowing down so i'm hoping to transition back to keystone04:27
lbragstadall keystone, all the time04:27
*** lipt has joined #openstack-keystone04:31
stevemarlbragstad: i like the sound of that!04:31
*** edtubill has joined #openstack-keystone04:33
*** edtubill_ has joined #openstack-keystone04:35
*** dave-mccowan has quit IRC04:36
lbragstadstevemar me too!04:37
*** edtubill has quit IRC04:38
lbragstadstevemar aren't you suppose to be away from you computer?04:41
stevemarlbragstad: both people i'm taking care of are asleep04:44
lbragstadstevemar shouldn't you be?!04:44
stevemarlbragstad: so... many... diapers04:44
lbragstadstevemar how have night been - is he up a lot?04:44
lbragstader nights*04:45
stevemarlbragstad: he's actually pretty good. wakes up about 3 times, soon (1am), then 4-5am, then 8-9am (when we get up for the day)04:45
stevemarluckily, he goes back to sleep fairly easily04:46
lbragstadwow - that doesn't seem too bad (i've heard of worse)04:46
stevemaroh yeah04:46
stevemarwe lucked out04:46
lbragstadstevemar that's awesome04:46
*** iurygregory has quit IRC04:47
*** jamielennox is now known as jamielennox|away04:48
*** eszxy has quit IRC04:52
*** eszxy has joined #openstack-keystone04:53
*** spandhe has quit IRC04:58
*** jamielennox|away is now known as jamielennox05:04
*** spandhe has joined #openstack-keystone05:12
openstackgerritedan david proposed openstack/oslo.policy: Fix typo: 'olso' to 'oslo'  https://review.openstack.org/32421605:35
*** roxanaghe has quit IRC05:38
*** roxanaghe has joined #openstack-keystone05:38
*** GB21 has joined #openstack-keystone05:42
*** jbell8 has quit IRC05:43
*** roxanaghe has quit IRC05:43
*** rcernin has joined #openstack-keystone05:48
*** jamielennox is now known as jamielennox|away06:01
*** GB21 has quit IRC06:02
*** GB21 has joined #openstack-keystone06:15
*** jamielennox|away is now known as jamielennox06:16
*** mou has joined #openstack-keystone06:27
*** spandhe has quit IRC06:35
openstackgerritMerged openstack/keystone: Updated from global requirements  https://review.openstack.org/32253906:36
*** edtubill_ has quit IRC06:39
*** roxanaghe has joined #openstack-keystone06:39
notmorganstevemar: fwiw, re+2 on the ksa thing.06:43
notmorganstevemar: but i am still inclined to hold for direct confirmation of a fix.06:43
*** roxanaghe has quit IRC06:43
*** zyxes has joined #openstack-keystone06:52
*** mvk_ has quit IRC06:52
*** tesseract- has joined #openstack-keystone06:53
*** eszxy has quit IRC06:56
*** sdake has joined #openstack-keystone06:57
*** jaosorior has joined #openstack-keystone07:02
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Zanata  https://review.openstack.org/32425807:16
openstackgerritSrushti Gadadare proposed openstack/keystone: Provide user friendly messages for db_sync  https://review.openstack.org/28931607:18
*** henrynash has joined #openstack-keystone07:22
*** ChanServ sets mode: +v henrynash07:22
*** neophy has quit IRC07:29
*** GB21 has quit IRC07:36
*** henrynash has quit IRC07:36
*** hoonetorg has quit IRC07:38
*** sdake has quit IRC07:39
*** roxanaghe has joined #openstack-keystone07:40
*** lipt has quit IRC07:41
*** jaosorior has quit IRC07:42
*** roxanaghe has quit IRC07:44
*** lipt has joined #openstack-keystone07:46
*** lipt has quit IRC07:46
*** hoonetorg has joined #openstack-keystone07:50
*** lipt has joined #openstack-keystone07:51
*** lipt has quit IRC07:51
*** lipt has joined #openstack-keystone07:51
*** lipt has quit IRC07:51
*** lipt has joined #openstack-keystone07:56
*** lipt has quit IRC07:56
*** jaosorior has joined #openstack-keystone07:56
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:02
*** GB21 has joined #openstack-keystone08:03
*** henrynash has joined #openstack-keystone08:07
*** ChanServ sets mode: +v henrynash08:07
*** jbell8 has joined #openstack-keystone08:08
openstackgerritDavanum Srinivas (dims) proposed openstack/keystone: [WIP] Testing latest u-c  https://review.openstack.org/31843508:10
*** jaosorior has quit IRC08:14
*** jaosorior has joined #openstack-keystone08:15
*** lipt has joined #openstack-keystone08:15
*** lipt has quit IRC08:15
*** lipt has joined #openstack-keystone08:19
*** lipt has quit IRC08:19
*** lipt has joined #openstack-keystone08:20
*** lipt has quit IRC08:20
*** lipt has joined #openstack-keystone08:21
*** lipt has quit IRC08:21
*** lipt has joined #openstack-keystone08:22
*** lipt has quit IRC08:22
*** markvoelker has quit IRC08:29
*** markvoelker has joined #openstack-keystone08:30
*** lipt has joined #openstack-keystone08:34
*** lipt has quit IRC08:34
*** lipt has joined #openstack-keystone08:34
*** lipt has quit IRC08:34
*** lipt has joined #openstack-keystone08:43
*** lipt has quit IRC08:43
*** lipt has joined #openstack-keystone08:44
*** lipt has quit IRC08:44
*** lipt has joined #openstack-keystone08:45
*** lipt has quit IRC08:45
*** lipt has joined #openstack-keystone08:50
*** lipt has quit IRC08:50
*** lipt has joined #openstack-keystone08:52
*** lipt has quit IRC08:52
*** lipt has joined #openstack-keystone08:59
*** lipt has quit IRC08:59
*** lipt has joined #openstack-keystone09:02
*** lipt has quit IRC09:02
*** lipt has joined #openstack-keystone09:04
*** lipt has quit IRC09:04
*** lipt has joined #openstack-keystone09:09
*** lipt has quit IRC09:09
*** sdake has joined #openstack-keystone09:13
*** TxGVNN has joined #openstack-keystone09:17
openstackgerritSrushti Gadadare proposed openstack/keystone: Return BadRequest for 4 byte unicode characters  https://review.openstack.org/32432009:19
*** pnavarro has joined #openstack-keystone09:36
*** TxGVNN has quit IRC09:36
*** _amrith_ is now known as amrith09:37
*** sdake has quit IRC09:40
*** roxanaghe has joined #openstack-keystone09:42
*** henrynash has quit IRC09:43
*** roxanaghe has quit IRC09:46
*** neophy has joined #openstack-keystone10:03
*** mou has quit IRC10:07
*** henrynash has joined #openstack-keystone10:10
*** ChanServ sets mode: +v henrynash10:10
*** GB21 has quit IRC10:14
*** GB21 has joined #openstack-keystone10:16
*** neophy has quit IRC10:22
*** spandhe has joined #openstack-keystone10:25
*** EinstCrazy has quit IRC10:26
*** henrynash has quit IRC10:36
*** rodrigods has quit IRC10:39
*** rodrigods has joined #openstack-keystone10:40
*** amrith is now known as _amrith_10:40
*** mvk_ has joined #openstack-keystone10:41
*** roxanaghe has joined #openstack-keystone10:42
*** roxanaghe has quit IRC10:47
*** GB21 has quit IRC10:53
breton_²10:58
*** GB21 has joined #openstack-keystone11:22
*** julim has joined #openstack-keystone11:31
breton_so11:38
breton_since keystone is on suburl now by default in devstack11:39
breton_how should federation-related things be configured?11:39
breton_for example, should shibboleth live on /identity/Shibboleth.sso or on /Shibboleth.sso?11:39
*** nisha has joined #openstack-keystone11:40
breton_should /v3/auth/OS-FEDERATION/websso/saml2 be prefixed with /identity/ everywhere or there should be a cleaner way?11:40
breton_like moving it inside the <Location /identity/>?11:40
*** roxanaghe has joined #openstack-keystone11:43
*** roxanaghe has quit IRC11:48
*** nisha has quit IRC11:48
*** rk4n has joined #openstack-keystone11:48
*** _amrith_ is now known as amrith11:52
*** raildo-afk is now known as raildo11:53
*** jbell8 has quit IRC11:54
*** clenimar has joined #openstack-keystone12:01
openstackgerritMerged openstack/keystone: Simplify & fix configuration file copy in setup.cfg  https://review.openstack.org/32208612:02
*** nisha has joined #openstack-keystone12:07
*** hoonetorg has quit IRC12:12
*** GB21 has quit IRC12:18
*** hoonetorg has joined #openstack-keystone12:27
*** dave-mccowan has joined #openstack-keystone12:28
*** clenimar has quit IRC12:31
*** mou has joined #openstack-keystone12:33
*** clenimar has joined #openstack-keystone12:38
*** julim has quit IRC12:41
*** clenimar has quit IRC12:44
*** roxanaghe has joined #openstack-keystone12:44
*** zyxes has quit IRC12:46
*** gordc has joined #openstack-keystone12:46
*** roxanaghe has quit IRC12:48
*** zyxes has joined #openstack-keystone12:50
*** iurygregory has joined #openstack-keystone12:51
*** zyxes has quit IRC12:56
*** neophy has joined #openstack-keystone12:56
rodrigodsknikolla, ping.. there?12:57
*** amrith is now known as _amrith_13:00
*** _amrith_ is now known as amrith13:09
*** julim has joined #openstack-keystone13:14
*** rderose has joined #openstack-keystone13:17
*** neophy has quit IRC13:18
shewlessHi there. Is anyone available to help walk me through federation using keystone as the service provider and adfs as the identity provider? I've followed the steps here: http://docs.openstack.org/developer/keystone/federation/federated_identity.html but I'm having trouble generating the "right" metadata for adfs13:19
*** pauloewerton has joined #openstack-keystone13:22
*** edmondsw has joined #openstack-keystone13:29
rodrigodsrderose, ping... re: role assignments with shadow users13:30
rderoserodrigods: just checking your comments13:31
rderoserodrigods: thanks btw13:31
rderoserodigods: what's up13:32
rderose*rodrigods13:33
*** nisha has quit IRC13:33
rodrigodsrderose, did you consider changing the role_assignments to use FKs?13:33
rodrigodsthe table, i mean13:33
rodrigods(just brainstorming)13:33
*** crinkle has quit IRC13:35
rderoserodrigods: hmm... no, my goal has been to treat federated users like any other users, so using the existing implementation13:35
rodrigodsrderose, yeah... i remember that one of the reasons we don't have FKs there were federated users13:35
*** henrynash has joined #openstack-keystone13:36
*** ChanServ sets mode: +v henrynash13:36
rderoserodrigods: oh really...  yeah, then there may be an opportunity now to add them (FKs)13:36
*** crinkle has joined #openstack-keystone13:36
rderoserodrigods: I'll look into it13:36
rodrigodsrderose, yeah, just don't remember all the use cases, but would avoid to manually delete everything in the manager/driver layer13:37
rderoserodrigods: ah, I see.13:37
rodrigodsrderose, for example: https://github.com/openstack/keystone/blob/master/keystone/resource/core.py#L46513:38
henrynashdolphm: ping13:40
rderoserodrigods: hmm... this method is cleaning up assignments after a project has been deleted, so if having FK, you would have to delete assignments first...13:41
*** tonytan4ever has joined #openstack-keystone13:41
*** aurelien__ has joined #openstack-keystone13:41
rodrigodsrderose, thinking about using cascade13:41
rderoserodrigods: right13:42
*** richm has joined #openstack-keystone13:42
rderoserodrigods: yeah, seems like a good opportunity to do some performance improvements and refactoring13:42
rderoserodrigods: adding it to my list :)  thx13:43
rodrigodsrderose, awesome :)13:43
rodrigodsthanks13:43
*** roxanaghe has joined #openstack-keystone13:45
*** roxanaghe has quit IRC13:49
*** jaugustine has joined #openstack-keystone13:51
*** lucas__ has joined #openstack-keystone13:51
*** ametts has joined #openstack-keystone13:53
*** rk4n has quit IRC13:55
knikollarodrigods: hey, just saw your ping13:56
rodrigodsknikolla, hey13:56
rodrigodsto let you know that i have a saml2/ecp tempest test working13:56
* rodrigods is doing a refactoring right now13:56
breton_rderose:13:58
breton_rderose: i've investigated the issue with concrete role assignments13:58
rderosebreton_: yeah, just reading your comments13:59
rderosebreton_: and thanks for looking into this btw13:59
*** aurelien__ has quit IRC13:59
breton_rderose: it happens because of that api call13:59
rderosebreton_: I see13:59
breton_rderose: and the call happens because of code in keystoneclient's ./v3/contrib/federation/base.py13:59
*** gagehugo has joined #openstack-keystone14:00
breton_rderose: so we have 2 options14:00
breton_rderose: 1. fix concrete role assignments14:00
breton_rderose: 2. fix the client14:00
*** ddieterly has joined #openstack-keystone14:00
*** KarthikB has joined #openstack-keystone14:00
breton_although OS-FEDERATION/projects is deprecated, i don't know when14:00
*** KarthikB has quit IRC14:00
breton_"since 1.1" it says14:01
rderosebreton_: on the surface, I think fixing the client makes more sense.  what do you think?14:01
*** KarthikB has joined #openstack-keystone14:01
breton_rderose: it depends on how far we are from removing OS-FEDERATION/projects14:01
breton_if we are going to remove it this cycle, i am all for fixing the client14:01
breton_if we are not going to remove it this cycle, i am for fixing the server14:02
rderosebreton_: good point14:03
breton_i will post all this to the review now14:03
rderosebreton_: appreciate that and thanks again14:03
knikollarodrigods: we were already working on that with mylu and now another intern. should probably compare and see if we are duplicating effort.14:04
*** EinstCrazy has joined #openstack-keystone14:04
knikollarodrigods: do you have the code available somewhere?14:04
*** rk4n_ has joined #openstack-keystone14:05
*** ayoung has joined #openstack-keystone14:05
*** ChanServ sets mode: +v ayoung14:05
*** lucas__ has quit IRC14:05
*** jaosorior has quit IRC14:06
*** lucas__ has joined #openstack-keystone14:09
*** edtubill has joined #openstack-keystone14:09
*** shoutm has joined #openstack-keystone14:09
*** lucas__ has quit IRC14:10
openstackgerrithenry-nash proposed openstack/keystone-specs: Domain Specific Mapping Rules  https://review.openstack.org/32455214:10
*** lucas__ has joined #openstack-keystone14:12
*** links has quit IRC14:12
*** jbell8 has joined #openstack-keystone14:15
*** lucas__ has quit IRC14:16
rodrigodsknikolla, yep, let me finish it here and send it to you14:16
rodrigodsknikolla, mine is for "regular" federation, not k2k14:17
*** woodster_ has joined #openstack-keystone14:17
*** aurelien__ has joined #openstack-keystone14:18
*** lucas__ has joined #openstack-keystone14:19
knikollarodrigods: ours does k2k, gets a token, gets a saml from keystone, exchanges, gets an unscoped token, scopes it.14:19
*** ayoung has quit IRC14:19
*** lucas__ has quit IRC14:20
*** lucas__ has joined #openstack-keystone14:20
*** edtubill has quit IRC14:21
*** lucas__ has quit IRC14:21
*** lucas___ has joined #openstack-keystone14:21
*** edtubill has joined #openstack-keystone14:21
knikollarodrigods: we're working on refactoring it https://github.com/wjdan94/tempest/compare/master...wjdan94:k2k14:22
*** lucas___ has quit IRC14:22
*** lucas__ has joined #openstack-keystone14:22
*** nisha_ has joined #openstack-keystone14:24
*** vint_bra has joined #openstack-keystone14:28
*** spandhe_ has joined #openstack-keystone14:29
*** nisha_ has quit IRC14:29
*** spandhe has quit IRC14:30
*** spandhe_ is now known as spandhe14:30
*** BjoernT has joined #openstack-keystone14:32
*** ayoung has joined #openstack-keystone14:35
*** ChanServ sets mode: +v ayoung14:35
henrynashanyone been doing performance checkigng token validation with fernet tokens? (and trying to explain why they seem slower than UUID validation)?14:37
*** pushkaru has joined #openstack-keystone14:37
henrynashdolphm did a while back, and we’ve done cache improvements in Mitaka…and tryingt o see how good we got14:37
lbragstadhenrynash one of the current major hangups is the revocation path14:40
lbragstadayoung and jorge_munoz had a bunch of patches up to prune the unnecessary revocation events and remove the tree structure14:41
henrynashlbragstad: does that only cause issues when you ahve to revoke, or slow down all fernet access?14:42
ayounglbragstad, starting to wonder if that is a good idea, or if leaving it in the revocation events will actually be the faster track14:42
ayoungthere is going to be a DB hit on either14:42
lbragstadhenrynash  when we validate a fernet token, we have to check *all* the revocation events14:42
henrynashlbragstad: ouch14:42
lbragstadhenrynash yup14:42
ayoungwith the "remove spurious" approach, the validation has to then hit the identity, assignment, and resource back ends14:42
ayoung"all the revocation events" might actually be faster than querying all these backends on each token14:43
* notmorgan still believes we should oush this down to the db as a test14:43
lbragstadnotmorgan ++14:43
ayoungnotmorgan, so, kindof orthoganal14:43
*** mou has quit IRC14:43
notmorganask sql to dk the work instead of python. indexed lookups are cheap14:43
notmorganayoung: i think regardless of pruned events or not14:44
notmorganso ++14:44
*** david-lyle has joined #openstack-keystone14:44
henrynashas an aside, do we know who creates all teh tests for: http://performance-docs.readthedocs.io/en/latest/test_results/keystone/all-in-one/index.html since we haev token issue in there, but not token vlaidation (which would be good to add)14:44
ayoungnotmorgan, events held in memory and checked via iterating through a list is probably going to be the fastest.  SQL will be slower, as it is an out-of-process call, regardless of how optimized.14:45
*** timcline has joined #openstack-keystone14:45
notmorganayoung: like i said we should poc it14:45
ayoungbut...either way will probably be faster than checking identity, assignment, and resource for each validation14:45
*** roxanaghe has joined #openstack-keystone14:45
ayoungnotmorgan, On the other hand, checking the backends is the simpler approach14:46
notmorganayoung: to be fair... we already hit all those backends  in a validate call before revoke check14:46
notmorganwe could invert that once we wxplode the fernet payload14:46
ayoungnotmorgan, right14:47
breton_henrynash: DinaBelova had something to do with it afaik14:47
notmorganand the local cache means we hit those backebds 1 time regardless14:47
henrynashlbragstad: (and sorr for bing dumb but)…when you say we need to check revocations, you mean the middleware lib has to do this so it knows whether its cache is out of date?14:47
ayoungnotmorgan, we should populate and validate each piece step by step14:47
henrynashbreton_: thx14:47
ayoungremember my pipeline design from oh 18 years ago or so?14:47
notmorganayoung: eh. id say check revoke tjen pass to validate14:47
notmorganayoung: we dont need to hit the backebds at all to check revoke  in most cases14:48
notmorgan(or at all?)14:48
ayoungnotmorgan, agreed,  if we reduce the number of spurious revocation events, that is probably the right sequence14:49
openstackgerritMerged openstack/oslo.policy: Fix typo: 'olso' to 'oslo'  https://review.openstack.org/32421614:49
notmorganeve  without reducing events14:49
ayounga good data point would be "how many token validations are done with cached data"14:49
lbragstadrderose https://github.com/openstack/keystone-specs/blob/master/specs/keystone/liberty/keystone-tokenless-authz-with-x509-ssl-client-cert.rst14:50
*** adu has joined #openstack-keystone14:50
ayoungnotmorgan, regardless, if I don't get ECP working with Keycloak I won't have time for any of this14:50
breton_DinaBelova: ayoung: osprofiler could do something like that14:50
*** roxanaghe has quit IRC14:50
* DinaBelova reading14:51
ayoungbreton_, more idle curoisity than anything else...would have to be run on a large size deployment.  ProbAbly depends on what client is used....lots of variables14:51
rderoselbragstad: so this is the spec, but it was implemented, right?14:52
DinaBelovahenrynash - perofrmance-docs is the result of performance WG activities. We're proposing test plans, etc. on review, work on them, and then land the results and plans to the docs14:52
*** vgridnev_ has joined #openstack-keystone14:53
*** vgridnev_ has quit IRC14:53
henrynashDinaBelova: great! If i wanted to prose an addition to the keystone tests, how would I go abour doing that14:53
DinaBelovaayoung - as for the number of the revocation calls - it looks like this can be checked via adding just one profiling decorator on the interested function call to the debugged keystone and run several profiling requests to see full tree of the calls14:54
lbragstadrderose yes - i believe that was gyee's doing14:54
rderoselbragstad: cool, thx14:55
lbragstadrderose yep14:55
lbragstadhenrynash sorry - was in a meeting14:55
henrynashlbragstad: no worried!14:55
lbragstadhenrynash the token_provider_api has to perform checks against the revocation api to see if a given token is invalidated14:55
DinaBelovahenrynash - very simple workflow :) you may join #openstack-performance channel, we're mostly working right now on two repos - https://github.com/openstack/performance-docs and https://github.com/openstack/osprofiler14:55
DinaBelovathe test plan proposal is the same as any commit in the OpenStack14:56
DinaBelovathe same gerrit workflow14:56
lbragstadhenrynash https://github.com/openstack/keystone/blob/0068096e132d05aa799a8d7b58f9646b4d96ac34/keystone/token/provider.py#L26014:56
henrynashDinaBelova: great, thx14:57
DinaBelovahenrynash - so yeah, you can wrap this line with @profiler.trace(<needed info>) and see the result in the result profiling report14:57
henrynashlbragstad: yep, that’s smack there14:57
*** andreykurilin__ has joined #openstack-keystone14:57
*** raddaoui has joined #openstack-keystone14:57
*** clenimar has joined #openstack-keystone14:57
*** spandhe has quit IRC15:00
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Change password requirements  https://review.openstack.org/32015615:00
openstackgerrithenry-nash proposed openstack/keystone-specs: Domain Specific Mapping Rules  https://review.openstack.org/32455215:00
*** pnavarro has quit IRC15:01
*** amrith is now known as _amrith_15:02
*** spandhe has joined #openstack-keystone15:03
lbragstadhenrynash what do you think about lines 166 - 169 here https://review.openstack.org/#/c/324055/2/specs/keystone/newton/shadow-mapping.rst15:03
patchbotlbragstad: patch 324055 - keystone-specs - Mapping shadow users into projects and roles15:03
henrynashlbragstad: looking15:03
*** basilAB has quit IRC15:06
*** _amrith_ is now known as amrith15:08
*** basilAB has joined #openstack-keystone15:08
*** KevinE has joined #openstack-keystone15:09
*** KevinE has quit IRC15:09
*** amrith is now known as _amrith_15:09
*** KevinE has joined #openstack-keystone15:09
*** KevinE has quit IRC15:10
henrynashlbragstad: so I’ve added a question…it would be great it we could do it all within the scoped of more flexible mapping….15:11
*** KevinE has joined #openstack-keystone15:11
*** _amrith_ is now known as amrith15:14
*** pumarani__ has joined #openstack-keystone15:17
lbragstadhenrynash ++15:18
*** pushkaru has quit IRC15:20
ayoungrodrigods, so did you test SAML Federated plugin using Mitaka (OSP8) and the corresponding keystoneauth?15:20
ayoungDinaBelova, that would be cool to do long term, but really, I think the focus for now needs to be on correctness.  I'm a litle leery of putting too much effort in to performance tuning Keystone token validations under artificial loads.  We can lock ourselves into more bad decisions that way15:22
*** ksavich has joined #openstack-keystone15:22
ayoung“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”15:22
*** shoutm has quit IRC15:23
DinaBelovaayoung understood :)15:23
henrynashayoung: are you saying you don’t think we should at least get the number of token validation? (one of the most common keystone calls of all time)15:29
*** jbell8 has quit IRC15:29
ayounghenrynash, sort of.15:30
*** clenimar has quit IRC15:30
henrynashayoung: :-)15:30
ayounghenrynash, I was actually suggesting that there is a difference in cost for 2 token validations if15:30
ayoungthey are for the same token versus two different tokens15:30
henrynashayoung: ah, sure15:30
ayoungand for the same user, role, project versus different15:30
ayoungcaching etc15:30
*** pumarani__ has quit IRC15:33
*** ksavich has quit IRC15:35
*** EinstCrazy has quit IRC15:35
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Change password requirements  https://review.openstack.org/32015615:40
*** rk4n_ has quit IRC15:42
*** GB21 has joined #openstack-keystone15:42
*** agrebennikov has joined #openstack-keystone15:47
*** spzala has joined #openstack-keystone15:48
*** pushkaru has joined #openstack-keystone15:48
*** lucas__ has quit IRC15:49
*** lucas__ has joined #openstack-keystone15:54
*** ddieterly is now known as ddieterly[away]15:57
openstackgerritAlexander Makarov proposed openstack/keystone: Add failed auth attempts logic to meet PCI-DSS  https://review.openstack.org/32402915:58
*** tesseract- has quit IRC15:59
*** lucas__ has quit IRC15:59
*** rcernin has quit IRC16:01
*** diazjf has joined #openstack-keystone16:02
*** diazjf has quit IRC16:02
*** ddieterly[away] is now known as ddieterly16:02
*** mvk_ has quit IRC16:03
*** diazjf has joined #openstack-keystone16:07
*** gyee has joined #openstack-keystone16:08
*** ChanServ sets mode: +v gyee16:08
*** ayoung has quit IRC16:09
lbragstadrderose i have another dumb shadow users question16:09
*** ayoung has joined #openstack-keystone16:09
*** ChanServ sets mode: +v ayoung16:09
rderoselbragstad: sure16:09
lbragstadwhen a user comes in from ldap or some custom driver - i thought keystone would be creating them a user id16:10
lbragstadfor example - even though my username in ldap is lance and my user_id is lbragstad - my user id in keystone would be some uuid.uuid4().hex value16:11
lbragstadwhich would be the id used when assigning roles to my shadow user, right?16:11
breton_are shadow users for ldap implemented?16:13
*** breton_ is now known as breton16:13
rderosethat's not a dumb question :)  when a person comes in from LDAP or custom driver, we'll create a (user -> nonlocal_user) object.16:13
rderoselbragstad: ^16:13
*** lhcheng has joined #openstack-keystone16:13
*** ChanServ sets mode: +v lhcheng16:13
lbragstadbreton it's up for review16:13
rderoselbragstad: If your using an LDAP driver the user.user_id would be lbragstad and the domain_id and username would be mapped in the nonlocal_user table16:14
lbragstadrderose i see the NonLocalUser model has three attributes, domain_id, name, and user_id16:15
rderoselbragstad: the user_id in that table is an FK to the user table16:15
lbragstadok so the user.id and the nonlocal_user.id would be the same16:15
rderoselbragstad: correct16:16
lbragstadso the user table could have a bunch of different format IDs in it16:16
KevinEI have a folder of scenarios I'd like to merge up. Is it possible to build unit tests in a secondary merge for cleanliness, or would my initial one just get shot down for not having them in the first place?16:16
lbragstadsome being rderose or lbragstad and some being deeab2451cd04839aa705712bf539c6016:16
lbragstaddepending on where the user was actually created16:16
rderoselbragstad, not really.  if your backend identity is ldap, it will have what's in ldap.  but if ldap has a bunch of different formats, then yes.16:18
*** nisha_ has joined #openstack-keystone16:18
rderoselbragstad: so this model allows us to do account linking where you could have a nonlocal identity and a federated identity, all tied to the same user16:18
rderoselbragstad: actually, if your are using LDAP and federation, your federated users created would have a uuid16:20
lbragstadrderose and that is because the federated user is persisted as a shadow user and the user id for the shadow user is generated by keystone (some arbitrary uuid)16:21
rderoselbragstad: correct16:21
lbragstadso if i authenticate via federation there is going to be a user entry persisted in keystone with deeab2451cd04839aa705712bf539c60 as the id (for example)16:22
rderoselbragstad: yes16:22
lbragstadif I authenticate with LDAP there is going to be another user entry persisted in keystone with lbragstad as the id16:22
*** jbell8 has joined #openstack-keystone16:22
rderoselbragstad: correct16:22
lbragstadtwo totally separate user references - and they can be linked in either direction i assume?16:23
rderoselbragstad: and that's one thing we'll need to solve with account linking.  when we link your ldap account with your federated account, which id will you get16:23
lbragstadright16:23
lbragstadfor some reason i'm getting mixed up on that part16:24
*** david-lyle has quit IRC16:24
rderoselbragstad: two totally different users before the accounts are linked16:24
lbragstadbut i don't think that has much to do with what's currently proposed16:24
rderoselbragstad: it can be confusing, but essentially shadow users creates a data model that supports all of these identities under a master identity (user table)16:24
rderoselbragstad: so all users (ldap, federated, sql...) will have a record in the user table16:26
rderoselbragstad: and IDs may not be standard, but it works as long as they are unique16:26
lbragstadrderose do you think unique-ness with IDs will be an issue?16:27
lbragstadsay there is an lbragstad in another ldap somewhere16:28
rderoselbragstad: no, because it's not currently with LDAP and everything else would be uuid16:28
rderoselbragstad and multiple ldaps, we have already solved this with id_mapping16:28
lbragstadok - that makes sense16:29
lbragstadrderose what about this case16:29
bretonknikolla: https://review.openstack.org/#/c/320623/ looks good. Do you mind if i fix some things if i find them there during live testing?16:29
patchbotbreton: patch 320623 - keystone - Devstack plugin for Federation16:29
lbragstadsay we have an LDAP setup and I have a user persisted in it with the id lbragstad16:30
lbragstadi authenticate against keystone with that ldap and my user id in keystone is also lbragstad16:30
*** rk4n has joined #openstack-keystone16:31
lbragstadlet's say that I use that same LDAP as an identity provider and get a SAML assertion proving my identity16:31
lbragstadand i pass that to keystone16:31
knikollabreton: sure, please do!16:31
lbragstadI'll get a shadow user with an arbitrary uuid for the user id16:31
rderosethe current implementation would create a new user record for the federated user with a uuid as the id16:31
*** clenimar has joined #openstack-keystone16:31
rderoselbragstad: yes16:32
*** lucas__ has joined #openstack-keystone16:32
*** lucas__ has quit IRC16:32
*** lucas__ has joined #openstack-keystone16:32
lbragstadso shadowing users will behave differently with id depending on where the authentication is coming from16:32
rderoselbragstad: and in that case, maybe we should automatically link them, however...16:32
rderoselbragstad: I don't think that use case would be practical, I mean why would you do that?  maybe migrating to federation perhaps...16:33
lbragstadrderose right - it's probably not practical at all16:34
rderoselbragstad: actually...16:34
lbragstadjust using it as a way to showcase the fact shadow users behaves differently (possibly with the same ldap) depending on where authentication (assertions?) come from.16:34
lbragstadi guess the question i'm trying to answer is - why wouldn't we just do for LDAP and custom like we do for federated users?16:35
lbragstadin terms of the ID generation16:35
rderoselbragstad: yeah, we would still create 2 separate users16:35
bretonare there plans to have a function to unify 2 shadow users into 1?16:38
rderoselbragstad: shadow users happens at authentication, but you may want to get user and assign them a role before they every auth16:38
knikollabreton: like linked accounts?16:38
lbragstadrderose wouldn't that case be solved by dolphm's new spec?16:38
lbragstadbreton yep - down the road16:39
bretonknikolla: probably16:39
bretonlbragstad: cool16:39
bretoni am also a little concerned about how shadow ldap users will work with id_mapping_api16:39
rderoselbragstad: dolphm's spec is specific to federation16:39
bretonin terms of performance16:39
bretonbecause there are performance issues even now for id_mapping_api (which i wanted to tackle but didn't have time)16:40
lbragstadrderose true - the mapping engine would have to be available for ldap cases too16:40
bretonand i wonder if it gets worse with an additional layer16:40
rderoselbragstad: to standardize the ids for LDAP (and custom), we would need to inject the id for all API calls; not only authentication16:41
*** aurelien__ has quit IRC16:41
rderoselbragstad: and it would require a substantial data migration16:41
rderoselbragstad: I think ultimately, we want to solve this with federation and make federation a first class citizen16:42
rderoselbragstad: so that deployers are using LDAP through federation16:42
lbragstadright - agree16:42
rderoselbragstad: but does that answer your question "...why wouldn't we just do for LDAP and custom like we do for federated users?"16:43
rderoselbragstad: does that make sense?16:43
*** sdake has joined #openstack-keystone16:44
lbragstadrderose and the answer is because it would be a significant data migration, right?16:44
lbragstadalso - what did you mean by inject the id for all API calls?16:44
*** tesseract has joined #openstack-keystone16:44
lbragstadsorry, i didn't catch that part16:44
rderoselbragstad: I mean, what if an admin calls get users (LDAP) before users authenticate?  which user id is returned?16:45
lbragstadrderose oh - meaning the id from LDAP (identity/backends/ldap.py) or the shadow id16:47
*** roxanaghe has joined #openstack-keystone16:47
rderoselbragstad: shadow users creates the user id for federation at authentication.  we couldn't do that for ldap unless we injected the user id for all api calls (get user, get user list...)16:47
rderoseyes, id from backends/ldap16:48
lbragstadgot it16:48
lbragstadyeah - that makes sense16:48
lbragstadso which one gets priority16:48
rderoselbragstad: cool16:48
rderoselbragstad: priority?16:49
rderoselbragstad: what do you mean?16:50
lbragstadrderose the user in ldap would have an id and if we ignored that id when creating the shadow user and created it with some arbitrary uuid then which id is technically considered correct when you do a list_users()16:50
*** roxanaghe has quit IRC16:51
*** julim has quit IRC16:51
rderoselbragstad: so if we did ignore it, then the uuid would be the user's user_id.  however, we don't, so for LDAP identities, lbragstad would be the user_id16:51
*** tesseract has quit IRC16:51
rderoselbragstad: I'm getting the feeling that I'm confusing you :)16:52
lbragstadso listing users from LDAP would return lbragstad as the id - but my "real" user id that is used to create role assignments is something different16:52
lbragstad^ that would be the case if we decided to generate user id for LDAP (and custom) users like we do for federated users16:54
rderoselbragstad: in that case, the real user id would be the uuid16:54
rderoselbragstad: in that case, admin calls list users, we would map lbragstad to a uuid in the user table (if it didn't already exist)16:56
rderoseso like shadow users, we would create the user_id, but it would have to happen at other API calls like get user16:57
rderosenot only authentication16:57
*** dan_nguyen has joined #openstack-keystone16:58
lbragstadrderose ok - right... so we kind of get around the problem by using the id from ldap16:59
rderoselbragstad: exactly16:59
* lbragstad hears church bells16:59
lbragstadsweet - makes sense16:59
rderose:)16:59
lbragstadi had to whiteboard it16:59
lbragstadlike four times16:59
rderoselbragstad: lol, yeah I've had to as well17:00
lbragstadrderose thanks for the explanation17:00
rderoselbragstad: no problem, let me know if more questions come up.  or, if you think over this again and doesn't make sense :)17:01
lbragstadrderose will do - i think the only thing that i was hung up on was why ldap users weren't treated like federated users17:01
rderoselbragstad: yeah, I see17:02
lbragstadbut i'll review your change now that I have a clearer picture17:02
rderoselbragstad: cool17:02
*** nisha_ has quit IRC17:05
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Change password requirements  https://review.openstack.org/32015617:06
*** timcline has quit IRC17:08
*** timcline has joined #openstack-keystone17:09
*** ayoung has quit IRC17:09
*** timcline has quit IRC17:09
*** timcline has joined #openstack-keystone17:10
*** timcline_ has joined #openstack-keystone17:11
openstackgerritwerner mendizabal proposed openstack/keystone-specs: Credential Encryption  https://review.openstack.org/32471417:11
*** spandhe_ has joined #openstack-keystone17:11
*** spandhe has quit IRC17:13
*** spandhe_ is now known as spandhe17:13
*** spzala has quit IRC17:13
*** timcline has quit IRC17:14
*** mvk_ has joined #openstack-keystone17:14
*** pushkaru has quit IRC17:14
*** tonytan4ever has quit IRC17:17
*** nisha_ has joined #openstack-keystone17:20
*** ddieterly is now known as ddieterly[away]17:32
*** pushkaru has joined #openstack-keystone17:36
andreykurilin__Is there someone how can review patch about novaclient integration with keystone session?17:39
*** gyee has quit IRC17:40
*** timcline_ has quit IRC17:40
*** timcline has joined #openstack-keystone17:41
*** tonytan4ever has joined #openstack-keystone17:42
*** timcline has quit IRC17:45
*** lucas__ has quit IRC17:47
raildoandreykurilin__: can you provide a link for it?17:47
andreykurilin__raildo: sure. https://review.openstack.org/#/c/30403517:48
*** lucas__ has joined #openstack-keystone17:49
*** lucas__ has quit IRC17:54
*** jbell8 has quit IRC17:54
*** diazjf has quit IRC17:56
*** lucas__ has joined #openstack-keystone17:56
*** links has joined #openstack-keystone17:56
*** lucas___ has joined #openstack-keystone17:58
*** lucas___ has quit IRC17:59
*** rdo has quit IRC17:59
*** lucas____ has joined #openstack-keystone17:59
*** lucas__ has quit IRC17:59
*** jbell8 has joined #openstack-keystone17:59
*** browne has joined #openstack-keystone18:01
*** spzala has joined #openstack-keystone18:01
*** spzala has quit IRC18:06
*** timcline has joined #openstack-keystone18:06
dolphmnotmorgan: https://review.openstack.org/#/c/324714/ should resolve your issue on https://review.openstack.org/#/c/284950/8/specs/keystone/newton/credential-encryption.rst@8918:07
patchbotdolphm: patch 324714 - keystone-specs - Credential Encryption18:07
patchbotdolphm: patch 284950 - keystone-specs - Credential Encryption18:07
*** iurygregory_ has joined #openstack-keystone18:07
notmorgandolphm: cool.18:09
*** david-lyle has joined #openstack-keystone18:09
SamYaplecan domains currently have sub-domains (projects with is_domain=True)?18:09
*** nisha_ has quit IRC18:09
notmorganSamYaple: no18:09
notmorganSamYaple: and it is not planned.18:09
dolphmanyone use gertty regularly? i've been meaning to try it again, and just started it up for the first time. it appears stuck on the project list screen (L), and isn't responding to input (or i have no idea how to use it)18:09
notmorgandolphm: yes.18:10
notmorgandolphm: it has some bugs. but i haven't run into that18:10
SamYaplenotmorgan: i thought that was part of the reseller stuff18:10
dolphmi chose to sync 2 projects, the Sync count went up to 329 and now it's "frozen"18:10
notmorganSamYaple: it was a long while ago, but I am very skeptical of that value18:10
notmorgandolphm: it gets very slow sometimes when syncing18:10
*** mvk has joined #openstack-keystone18:10
SamYapleim unsure how useful resellers are if projects can't have non-uniuque users18:11
SamYapleusers are still unique to domains, right?18:11
notmorganSamYaple: more domains.18:11
notmorganSamYaple: plain and simple, create more domains to isolate18:11
SamYapleright but inherited permissions don't work in that case, or have i missed something18:11
notmorganSamYaple: it's the same thing just not under a root -- it is much much much more complex.18:11
dolphmnotmorgan: hmm, i guess you're right. it is spinning up lots of git processes18:11
dolphmthe count isn't going down though18:12
notmorgandolphm: yeah it blocks on the sqlite backend.18:12
dolphmor up18:12
notmorgandolphm: and http+git18:12
notmorgandolphm: the ui gets hung up if there is a lock on the sqlite things18:12
notmorgandolphm: since it can't query/etc via the blocking lock18:13
*** mvk_ has quit IRC18:13
notmorganSamYaple: we can work on inherited permissions across domains for that case. but it feels like trees of domains is going to be highly complex and problematic in general. and the current model helps limit the extra complexity without forcing API breaking changes/auth-insanity18:14
amakarovnotmorgan, good day! Can you please give me an example how @MEMOIZE things are being tested?18:14
notmorgandolphm: +2/+A btw18:14
notmorgandolphm: on the spec18:14
notmorganamakarov: sure sec.18:14
SamYaplei understand your worries, and do share them to a degree. but i question how useful any "reseller" type thing is without inherited permissions and the ability to list only subdomains (not list _ALL_ domains)18:15
dolphmnotmorgan: sweet18:15
notmorganSamYaple: asking for "domains I can see" is a fine acl change18:17
SamYaplenotmorgan: sure, but for inherited permissions or that to work you would have to have some way to track a domains parent domain I would think18:17
notmorganSamYaple: no not really, domains are easy to tell "does user have grant X on domain[list]"18:18
notmorganSamYaple: inherited permissions *can* be assigned onto the domain [any domain] for [user].18:18
SamYaplei suppose what im missing is the linkage that says this domain is related in any way to this other domain18:18
SamYapleinherited implies some hierarcy18:19
notmorganit isn't. and it shouldn't be in keystone18:19
notmorganSamYaple: that is a billing thing. not a keystone thing18:19
*** pushkaru has quit IRC18:19
notmorganSamYaple: you're asking for business logic in keystone, and i disagree with that.18:19
notmorganamakarov: https://github.com/openstack/keystone/blob/f7b33213f1cb8313d2cb81225e8530ebbc37ce18/keystone/tests/unit/resource/test_backends.py#L1497-L155418:19
*** pushkaru has joined #openstack-keystone18:19
notmorganamakarov: that is a test of the caching + crud.18:19
amakarovnotmorgan, thank you18:19
notmorganamakarov: it basically does crud and reaches behind the manager to ask the driver directly18:20
notmorganamakarov: also look for the _invalidate tests18:20
SamYaplenotmorgan: im not sure i am. but its completely possible im missing something. how can *inherited* permissions work without the concept of a hierarchy? unless you are suggesting manually assigning userX with roleX in domainX18:20
notmorganSamYaple: when you create the new domain - assign to the account the RoleX in domainX18:21
notmorganSamYaple: it's a billing thing.18:21
notmorganSamYaple: and business logic thing.18:21
*** roxanaghe has joined #openstack-keystone18:22
SamYaplewhen you refer to "account" are you refering to a user?18:23
notmorganSamYaple: account is a billing construct18:23
notmorganSamYaple: sorry assign user <reseller> to newdomainx18:23
*** julim has joined #openstack-keystone18:23
dolphmnotmorgan: *poke* since you +2/+A'd the follow up https://review.openstack.org/#/c/284950/18:24
patchbotdolphm: patch 284950 - keystone-specs - Credential Encryption18:24
SamYaplenotmorgan: i mean thats not inherited permissions at that point. so i suppose thats where my confustion comes from here18:24
notmorganSamYaple: i'm arguing billing != keystone constructs.18:25
notmorgandolphm: done18:26
SamYapleim not familiar with buisness or billing logic to be honest. but if I am manually (automated) assigning permissions to new domains then its not inheritied18:26
notmorganSamYaple: it shouldn't be magically inherited.18:26
dolphmnotmorgan: ++18:26
SamYaplenotmorgan: i mean, its not magic. its inheritance18:27
notmorganSamYaple: create the domains directly.18:27
notmorganSamYaple: inheritence if permission sin keystone are really magical18:27
notmorganSamYaple: it should be less so.18:27
notmorganSamYaple: when you are going to sell another thing, get a domain for your new user (ask ythe provider's portal for the domain) which assigns the permissions for your (owner) account18:28
SamYaplefair enough. but just to be clear that is just permissions at that point, nothing is inherited18:29
notmorganSamYaple: then you sell that. it also means you explicitly get automatic breakdown of utilizations. isolation of quotas etc.18:29
notmorganSamYaple: it is inherited into the stuff under the new domain18:29
notmorganit is not *automatically magically* inherited.18:29
*** spzala has joined #openstack-keystone18:29
notmorganSamYaple: as long as the nerw domain role has inherit=true which i assume in my argument18:29
notmorganSamYaple: it's a difference between encoding business logic into keystone for some limited (very limited) models of deployment or providing tools for those deployments to succeed18:30
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Change password requirements  https://review.openstack.org/32015618:30
notmorganand i'm very much worried of the complexity for the narrow use cases (and it is narrow) for that type of reseller build that isn't met 90% of the way already with the current model.18:31
SamYaplenotmorgan: inherit=true is where? is this the new theortical feature that could be implemented?18:31
SamYapleor something im not aware of18:31
notmorganSamYaple: it is when you assign a role18:32
notmorganSamYaple: you can assign a role to userX that is inherited to everything under that domain/project resource18:33
notmorganSamYaple: so, when you create the domain(s) you assign an inherited role.18:33
notmorganSamYaple: anyway. so. the volume of complexity and massive security considerations worryme with stacking domains in domains in domains in domains.18:34
SamYaplei am familiar with inherited roles, but ive been looking at this a different. let me try to wrap my brain around what youre saying18:34
notmorganSamYaple: sounds good :)18:34
SamYapleand for the record i am not advocating domains of domains, just trying to understand18:34
SamYaplei get the potential issues there18:34
notmorganSamYaple: i am also saying "resellers selling to resellers selling to resellers" is not common18:34
notmorganand if it is, i have heard of very limited interest at best.18:35
*** david-lyle has quit IRC18:35
SamYaplei only started the conversation with resellers since that was the name of the blueprint18:35
notmorganSamYaple: /me nods.18:36
openstackgerritMerged openstack/keystone: Allow domain admins to list users in groups with v3 policy  https://review.openstack.org/32112818:36
notmorganSamYaple: :)18:36
notmorganSamYaple: lets continue this when you've had a chance to think it over :)18:36
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements  https://review.openstack.org/32058618:36
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements  https://review.openstack.org/32058618:36
SamYaplenotmorgan: thanks for the talk!18:37
notmorganSamYaple: of course!18:37
*** ddieterly[away] is now known as ddieterly18:37
*** diazjf has joined #openstack-keystone18:38
*** links has quit IRC18:39
openstackgerritSean Perry proposed openstack/keystoneauth: Show deprecation when a user_agent is not set  https://review.openstack.org/28964518:41
openstackgerritAlexander Makarov proposed openstack/keystone: Pre-cache new tokens  https://review.openstack.org/30914618:42
*** shaleh has joined #openstack-keystone18:43
shalehlbragstad: you around?18:43
*** ddieterly has quit IRC18:43
lbragstadshaleh yessir18:44
*** harlowja has quit IRC18:44
shalehlbragstad: re: your review of my keystone auth change. What would you like to see me change? I was worried I would be too verbose and apparently i erred on the too quiet side.18:44
lbragstadshaleh do you have the link handy?18:45
shalehlbragstad: one sec18:45
*** dan_nguyen has quit IRC18:45
shalehlbragstad: https://review.openstack.org/#/c/288175/18:45
patchbotshaleh: patch 288175 - keystoneauth - Apply a heuristic for product name if a user_agent...18:45
shalehIt is my plan to remove this code once the deprecate cycle completes and user_agent is a required parameter.18:46
lbragstadshaleh ah gotcha18:49
shalehlbragstad: until then it makes keystone's access file actually usable.18:49
shalehWe were trying to figure out what was spamming keystone. It turned out to be monasca and neutron.18:49
lbragstadshaleh hah nice18:50
shalehI will add more detail and update the review. Thanks for the guidance.18:50
*** jbell8 has quit IRC18:50
lbragstadshaleh thanks for the patch :)18:52
*** jbell8 has joined #openstack-keystone18:52
lbragstadshaleh and putting up with my questions!18:52
shalehlbragstad: you always ask good questions.18:53
dolphmdstanek: when will soon be now? https://github.com/dstanek/vim-gertty18:53
*** diazjf has quit IRC18:53
SamYaplenotmorgan: if i have this correct, user "reseller" has "domainadmin" role in "domain1". "domain2" and "domain3" three are compaines (business/billing logic) under "domain1". assign user "reseller" "domainadmin" role in "domain2" and "domain3" at time of domain creations is your suggested solution here?18:56
*** amakarov is now known as amakarov_away19:01
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements  https://review.openstack.org/32058619:02
*** clenimar has quit IRC19:02
notmorganSamYaple: yes19:03
notmorganSamYaple: that sounds correct19:03
*** nisha_ has joined #openstack-keystone19:05
*** clenimar has joined #openstack-keystone19:06
openstackgerritMerged openstack/keystone-specs: Credential Encryption  https://review.openstack.org/28495019:07
*** nisha_ has quit IRC19:10
*** GB21 has quit IRC19:10
openstackgerritRodrigo Duarte proposed openstack/keystone: Federated authentication via ECP functional tests  https://review.openstack.org/32476919:11
SamYaplenotmorgan: ok. that works for permissions. i personally wouldn't call that "inherited".19:11
notmorganSamYaple: sure19:11
openstackgerritRodrigo Duarte proposed openstack/keystone: WIP: Federated authentication via ECP functional tests  https://review.openstack.org/32476919:12
SamYapleregarding the "domains I can see" acl, would that be "domains I have roles assigned in"?19:12
notmorganSamYaple: i'd say "domains I have X role in"19:12
openstackgerritRodrigo Duarte proposed openstack/keystone: WIP: Federated authentication via ECP functional tests  https://review.openstack.org/32476919:12
openstackgerritRodrigo Duarte proposed openstack/keystone: Add protocols integration tests  https://review.openstack.org/30750819:12
openstackgerritRodrigo Duarte proposed openstack/keystone: Add mapping rules integration tests  https://review.openstack.org/30544419:12
openstackgerritRodrigo Duarte proposed openstack/keystone: Add service providers integration tests  https://review.openstack.org/30350219:12
notmorganSamYaple: but same idea :)19:13
openstackgerritSean Perry proposed openstack/keystoneauth: Apply a heuristic for product name if a user_agent is not provided  https://review.openstack.org/28817519:13
shalehlbragstad: ^^19:13
*** clenimar has quit IRC19:14
SamYaplenotmorgan: are we talking new api call for this? I don't see an existing one that maps well for what we are talking about19:15
notmorganSamYaple: i would say new API here19:15
notmorgantbh19:15
*** clenimar has joined #openstack-keystone19:17
SamYaple /v3/users/{user_id}/domains/{role_id} maybe?19:17
SamYapleit doesnt really map well with the other ones does it19:17
openstackgerritMerged openstack/keystone-specs: Credential Encryption  https://review.openstack.org/32471419:18
notmorganSamYaple: i'd be open to something under /v3/domains19:18
openstackgerritRodrigo Duarte proposed openstack/keystone: WIP: Federated authentication via ECP functional tests  https://review.openstack.org/32476919:19
notmorganSamYaple: or something new under /../users19:19
*** timcline has quit IRC19:19
SamYaplei think users might make the most sense. but that should be easily switchable. let me get a WIP up. endpoint can always change before merge19:21
openstackgerritRodrigo Duarte proposed openstack/keystone: WIP: Federated authentication via ECP functional tests  https://review.openstack.org/32476919:21
*** david-lyle has joined #openstack-keystone19:24
*** clenimar has quit IRC19:32
notmorganSamYaple: this is goin to need a spec because it's changing the API too.19:33
notmorganSamYaple: but WIP code to start is cool too.19:33
notmorganSamYaple: just a heads up (we'll want the spec to be proposed tomorrow if we want to land it this cycle)19:33
*** sdake has quit IRC19:35
SamYapleesh im not a spec guy notmorgan. not sure i could write it by tomorrow19:36
notmorganSamYaple: it should be an easy spec :)19:36
notmorganSamYaple: but at least get the WIP code up19:36
notmorganwe can talk spec-freeze exception on tuesday if needed.19:37
SamYapleyea im going to see if i can copy a spec real quick19:37
*** sdake has joined #openstack-keystone19:38
*** openstackstatus has quit IRC19:39
*** openstack has joined #openstack-keystone19:39
*** openstackstatus has joined #openstack-keystone19:40
*** ChanServ sets mode: +v openstackstatus19:40
*** sdake_ has joined #openstack-keystone19:40
*** frontrunner has joined #openstack-keystone19:41
*** sdake has quit IRC19:43
*** jbell8_ has joined #openstack-keystone19:45
*** jbell8 has quit IRC19:45
*** timcline has joined #openstack-keystone19:49
*** timcline_ has joined #openstack-keystone19:51
*** timcline has quit IRC19:51
*** clenimar has joined #openstack-keystone19:51
*** neophy has joined #openstack-keystone19:54
*** clenimar has quit IRC19:56
*** david-lyle has quit IRC19:57
openstackgerritMerged openstack/keystone: Imported Translations from Zanata  https://review.openstack.org/32425819:59
*** clenimar has joined #openstack-keystone19:59
bknudsonI've been trying some performance tests with devstack -- uuid tokens takes 12 seconds validate a token 1000 times, fernet takes 56 seconds.20:02
openstackgerritRon De Rose proposed openstack/keystone: Refactor shadow users and deprecate driver backend  https://review.openstack.org/32359620:03
stevemarbknudson: that doesn't sound good20:05
bknudsonI'm going to mess with caching20:05
stevemarbknudson: mess it all up20:05
stevemarbknudson: oh, i wanted to ask you to review this: https://review.openstack.org/#/c/274400/ before someone punts it through20:06
patchbotstevemar: patch 274400 - keystonemiddleware - Use extras for oslo.messaging dependency20:06
stevemarand possibly it's follow on patch... it may have an impact on devstack20:06
*** amrith is now known as _amrith_20:07
*** clenimar has quit IRC20:07
*** spzala has quit IRC20:08
*** clenimar has joined #openstack-keystone20:11
openstackgerritRaildo Mascena proposed openstack/keystone: Adding role assignment lists unit tests  https://review.openstack.org/25443620:12
*** neophy has quit IRC20:12
raildosamueldmq: ^20:12
openstackgerritRaildo Mascena proposed openstack/keystone: Adding role assignment lists unit tests  https://review.openstack.org/25443620:13
*** tqtran has joined #openstack-keystone20:14
*** spzala has joined #openstack-keystone20:14
*** clenimar has quit IRC20:17
*** roxanaghe has joined #openstack-keystone20:18
openstackgerritSam Yaple proposed openstack/keystone-specs: Add spec for domains user has role assignments in  https://review.openstack.org/32479720:19
*** spzala has quit IRC20:19
SamYaplenotmorgan: ^ not a spec guy though... not sure i even described the situation adequetly20:19
lbragstadbknudson ayoung had a patch up for revocation stuff20:19
lbragstadbknudson not sure what the status of that is20:20
*** rcernin has joined #openstack-keystone20:20
*** clenimar has joined #openstack-keystone20:21
*** harlowja has joined #openstack-keystone20:24
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements  https://review.openstack.org/32058620:28
*** lucas____ has quit IRC20:29
*** gyee has joined #openstack-keystone20:31
*** ChanServ sets mode: +v gyee20:31
*** clenimar has quit IRC20:31
*** lucas___ has joined #openstack-keystone20:31
bknudsonlbragstad: since this is a clean install there shouldn't be a lot of revocations unless devstack is doing a bunch. (not a very realistic test)20:32
lbragstadbknudson what devstack tests are you running?20:32
bknudsonalso I probably need to set up memcache for this to be realistic20:32
bknudsonlbragstad: I wrote my own script that just creates a token and calls validate using it20:32
bknudsonpython script20:33
*** lucas____ has joined #openstack-keystone20:33
*** spzala has joined #openstack-keystone20:33
bknudsonI can post it to my github20:33
lbragstadbknudson oh - so does your test do anything that would create a revocation event?20:33
*** dan_nguyen has joined #openstack-keystone20:33
*** lucas____ has quit IRC20:33
*** lucas____ has joined #openstack-keystone20:33
*** lucas___ has quit IRC20:34
bknudsonlbragstad: https://github.com/brantlk/keystone_performance20:34
*** clenimar has joined #openstack-keystone20:34
bknudsonlbragstad: the token is not revoked20:34
lbragstadbknudson gotcha20:35
bknudsonlbragstad: I would be interested to know what kind of numbers you get on your own systems20:35
*** sheel has quit IRC20:35
bknudsonthen I could compare it to what we get20:35
lbragstadbknudson when I was performance testing, i was doing it with devstack20:35
lbragstadand just hammering it with tempest tests20:36
bknudsonlbragstad: did you compare fernet and uuid?20:36
lbragstad./run_tempest tempest.api.identity.v3 (for example)20:36
lbragstadbknudson https://gist.github.com/lbragstad/7b60de511cfcd71b8bb520:37
bknudsonso my next things to try are to set up memcache and also to run in parallel since we want to see if there's contention20:37
lbragstadbut that was a different test - i was using dolphm's benchmark scripts20:37
bknudsonlbragstad: let me take a look at these20:38
*** lucas____ has quit IRC20:38
bknudsonresponse time - 1665.453 (ms)20:39
bknudsonthat's 1.6 seconds :(20:39
dolphmlbragstad: are you actually using caching? you have to point keystone to memcache20:40
dolphmlbragstad: or whatever your cache backend is - you can't just hit enable = true20:40
lbragstaddolphm i could have been doing that wrong - i also don't have the environment up anymore20:40
bknudsonconcurrent token validate: 4047.776 (ms) -- 4 seconds :((((20:41
*** tonytan4ever has quit IRC20:41
*** jbell8_ has quit IRC20:42
bknudsonhttps://gist.github.com/lbragstad/7b60de511cfcd71b8bb5 shows that uuid is faster, too: concurrent token validate: 348.120 for uuid vs 1414.370 for fernet20:43
*** lucas___ has joined #openstack-keystone20:44
lbragstadyeah - that was my general findings20:44
*** lucas___ has quit IRC20:44
*** lucas___ has joined #openstack-keystone20:45
bknudsonwe need to speed that up!20:45
lbragstadbknudson the call the check service providers in the validation path is also something that took forever20:46
bknudsonlbragstad: do you have an idea where the extra time is spent? decryption or database?20:46
lbragstadat least the last time dstanek dolphm and i ran profiling on keystone20:46
bknudsonservice catalog?20:46
dolphmbknudson: federated service providers20:46
lbragstadyep20:47
dolphmbknudson: it gets called several times to generate one token20:47
dolphmlist_service_providers(), i believe20:47
lbragstaddolphm generate or validate?20:47
bknudsonthat's included in these devstack tests?20:47
dolphmlbragstad: both?20:47
lbragstaddolphm that's what I thought20:47
dolphmbknudson: yes, even if the list is empty, it takes forever20:47
lbragstaddolphm bknudson marekd had a patch somewhere to add caching to it20:48
bknudsonwas it not cached or not cachable or something?20:48
dolphmbknudson: it's very cacheable and not cached today20:48
dolphmafaik20:48
lbragstadbknudson not sure what the status of it is20:48
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements  https://review.openstack.org/32058620:48
lbragstads/it/that patch/20:48
*** lucas___ has quit IRC20:49
dolphmactually, the hangup might have been that we don't do caching on lists, generally speaking... but this one should be trivial20:49
*** roxanagh_ has joined #openstack-keystone20:50
*** diazjf has joined #openstack-keystone20:51
*** joaotargino has quit IRC20:51
bknudsonmaybe you're talking about https://github.com/openstack/keystone/blame/master/keystone/federation/core.py#L66 ?20:52
bknudsonhttps://review.openstack.org/#/c/298748/ -- looks like lbragstad owns that one20:52
patchbotbknudson: patch 298748 - keystone - Refactor to allow for service provider caching20:52
*** julim has quit IRC20:53
lbragstadbknudson ah - you're right20:53
lbragstadthat looks like it's it20:53
*** roxanagh_ has quit IRC20:55
bknudsonone thing I realized is that we do validation twice whenever we validate a token -- once for x-auth-token and again for x-subject-token20:55
dolphmdstanek: ping20:55
bknudsonthe validation of x-auth-token should be much faster since it's not going to care about service catalogs or service providers20:55
dolphmdstanek: if you answered yesterday, i never saw the response :( but i'm still keeping an eye out for the pysaml service provider PoC20:55
lbragstaddolphm isn't dstanek on vacation this week?20:56
*** raildo is now known as raildo-afk20:56
dolphmlbragstad: oh, boo.20:56
lbragstadbknudson maybe we can add a patch to always do something like ?nocatalog for the x-auth-token20:56
dolphmlbragstad: i swear i talked to him a day or two ago lol20:56
bknudsonlbragstad: that should be easy to do.20:56
lbragstaddolphm yeah - he was in for a bit on monday and he said he might be on for a bit tomorrow20:57
bknudsondstanek needs to learn how to take a vacation20:57
dolphmlbragstad: ack20:57
*** ayoung has joined #openstack-keystone20:59
*** ChanServ sets mode: +v ayoung20:59
bknudsonlbragstad: I'm going to keep trying stuff (setting up memcache) and see if I can get better numbers.  I'll have to check out the service providers caching issue, too.20:59
lbragstadbknudson i'll see if i can get the patch cleaned up and rebased21:00
bknudsonthat would be great21:00
*** iurygregory_ has quit IRC21:03
*** gagehugo has quit IRC21:04
*** diazjf1 has joined #openstack-keystone21:07
*** diazjf has quit IRC21:09
*** diazjf1 has quit IRC21:12
*** adu has quit IRC21:16
openstackgerritRon De Rose proposed openstack/keystone: Shadow LDAP and custom driver users  https://review.openstack.org/32360221:16
*** diazjf has joined #openstack-keystone21:18
openstackgerritDolph Mathews proposed openstack/keystone: Move stray notification options into config module  https://review.openstack.org/32488021:18
openstackgerritLance Bragstad proposed openstack/keystone: Refactor to allow for service provider caching  https://review.openstack.org/29874821:18
lbragstadnotmorgan i rebased ^ but i think it still needs some work21:19
notmorganlbragstad: okie21:19
notmorganlbragstad: i'll take a look soon21:19
lbragstadnotmorgan i'm running tests locally but the caching stuff still don't quite make sense to me21:19
lbragstadnotmorgan thanks21:19
notmorganlbragstad: oh working to elminate circular importing huh?21:22
notmorganlbragstad: i think i see what you;re doing there21:22
*** pauloewerton has quit IRC21:22
*** jaugustine has quit IRC21:23
openstackgerritLance Bragstad proposed openstack/keystone: Refactor to allow for service provider caching  https://review.openstack.org/29874821:23
openstackgerritDolph Mathews proposed openstack/keystone: Move stray notification options into config module  https://review.openstack.org/32488021:24
*** ayoung has quit IRC21:25
lbragstadnotmorgan  yes - so revoke_model.py has a dependency on keystone.common.cache._context_cache has a dependency on revoke_model21:25
lbragstader... revoke_model has a dependency on cache and _context_cache has a dependency on revoke_model21:27
notmorganlbragstad: right. you're just restructuring that it looks like.21:28
*** _amrith_ is now known as amrith21:30
lbragstadnotmorgan why is/was _RevokeModelHandler here https://review.openstack.org/#/c/298748/3/keystone/models/revoke_model.py,unified/21:30
patchbotlbragstad: patch 298748 - keystone - Refactor to allow for service provider caching21:30
lbragstadhttps://review.openstack.org/#/c/298748/3/keystone/models/revoke_model.py,unified *21:31
patchbotlbragstad: patch 298748 - keystone - Refactor to allow for service provider caching21:31
lbragstadnotmorgan isn't that handled by keystone/common/cache/_context_cache.py _RevokeEventHandler()?21:31
notmorganlbragstad: uhm... it is.21:32
notmorganlbragstad: or should be.21:32
lbragstadnotmorgan hmm21:32
notmorganlbragstad: i would love to fix it so we can use json instead of msgpack21:32
notmorganbut there are some things... datetime objects etc that... wlel21:33
notmorgan:(21:33
notmorganwe could use cpickle >.>21:33
lbragstadso the changes to https://review.openstack.org/#/c/298748/3/keystone/models/revoke_model.py,unified should *not* include the _RevokeModelHandler21:33
patchbotlbragstad: patch 298748 - keystone - Refactor to allow for service provider caching21:33
notmorgan<.<21:33
* notmorgan waits for bknudson to throw things.21:33
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Change password requirements  https://review.openstack.org/32015621:33
notmorganlbragstad: it's fine to move it, but long term it should just go away21:33
openstackgerritRon De Rose proposed openstack/keystone: WIP - PCI-DSS Password strength requirements  https://review.openstack.org/32058621:33
notmorganit needs to be able to import revoke_model21:34
notmorganbecause it *needs* to say what objects it specifically serializes21:34
notmorganalso wait why is it still doing RevokeTree?21:34
lbragstadbecause that was proposed quite a white ago21:34
notmorgandidn't revoketree go away?21:35
lbragstadnotmorgan yep https://github.com/openstack/keystone/commit/75abc21ecfc2a37c10be61289204b5056403dd5c21:35
notmorganyeah that should just go away21:35
notmorganor if anything is moved the RevokeEventHandler moves.21:36
notmorganbut RevokeTree handler is superfluous now21:36
notmorgan(in fact that probably will fail jenkins because RevokeTree isn't a thing21:36
lbragstadnotmorgan right21:37
notmorganyeah this is an unfun rebase it looks like21:37
*** rcernin_ has joined #openstack-keystone21:38
lbragstadnotmorgan hmm why does the handler registration have to the line in the revoke_model?21:38
lbragstadnotmorgan cache.register_model_handler(_RevokeModelHandler) was in /keystone/models/revoke_model.pu21:39
lbragstad.py*21:39
notmorganlbragstad: not sure what you're asking21:40
lbragstadnotmorgan but that handler registration should already be taken care of here - https://github.com/openstack/keystone/blob/c1e712e18743fd683c9e6ee8886032a6e468188e/keystone/common/cache/_context_cache.py#L4521:40
*** adu has joined #openstack-keystone21:41
notmorganlbragstad: right. it should unless you can't have context cache import revoke_model21:41
notmorganwhich case, you may need to move it and have revoke_model import context_cache and register21:41
openstackgerritEric Brown proposed openstack/keystone: Update man page for Newton release  https://review.openstack.org/32489121:43
*** edtubill has quit IRC21:43
lbragstadnotmorgan hmm how did this come up when trying to cache service providers?21:43
*** diazjf has quit IRC21:43
notmorganlbragstad: no idea21:43
lbragstadthis circular dependency seems unrelated to caching service providers21:43
notmorgani'm very confused by this patch fwiw21:43
lbragstadme too21:43
bknudsonI just noticed that mitaka devstack has memcache enabled already, so that might explain the improvements I saw on devstack mitaka21:46
notmorganbknudson: yes21:46
notmorganbknudson: it was something i was working on to help with when we did the "disable in-memory cache" in keystonemiddleware21:46
notmorganbknudson: it was the other fix that was landed ... an hour after the "OMG REVERT" fix21:47
bknudsonnotmorgan: ok. I thought it was because fernet is too slow without it.21:47
bknudsonnow I'm trying to figure out how to enable caching on liberty ... Can't load plugin dogpile.cache oslo_cache.memcache_pool21:48
notmorganbknudson: nope. fernet being slow is also fixed by cache, but the reason devstack runs cache (and shared cache for service's validating user tokens, like it should be), is because of the ksm change21:48
notmorgan"fixed"21:48
*** henrynash has quit IRC21:48
*** ThomasHsiao has joined #openstack-keystone21:48
bknudsonwe probably weren't using oslo_cache in liberty21:50
*** spzala has quit IRC21:51
openstackgerritLance Bragstad proposed openstack/keystone: Refactor to allow for service provider caching  https://review.openstack.org/29874821:52
lbragstadnotmorgan starting over from square one21:52
notmorganbknudson: not in ksm.21:53
notmorganbknudson: i *think* oslo_cache landed in keystone in mitaka, and ksm in ... newton?21:54
bknudsonnotmorgan: we were still using keystone.cache.memcache_pool in liberty21:57
stevemarbknudson: fun times with performance eh21:58
*** markvoelker has quit IRC21:58
bknudsonstevemar: yes, people aren't happy with the performance.21:59
notmorganbknudson: yes :(22:01
notmorganbknudson: memcache_pool is uses (oslo_cache version) in mitaka22:02
notmorganbknudson: that will hopefully start going away once we fixup python-memcached (i'll be taking ownership of it next week)22:02
bknudsonwe're old-school22:02
*** gordc has quit IRC22:02
notmorganbknudson: aslo i want to pointout... that i love that we are the "clear" performance issue (we scale horizontally fairly well) compared to the seconds+ it takes nova and other projects to perform actions22:03
*** ametts has quit IRC22:03
notmorganbknudson: also the lack of most people willing to look at keystone until welllllll after we ship things because we're "not the problem" then "OMG YOURE SLOW"22:04
notmorganbknudson:  (common thread I keep hearing, if you can't tell)22:04
stevemarnotmorgan: you sound totally happy about it22:05
notmorganbknudson: operationally easier to manage keystone > pure performance imnsho.22:05
notmorganbut with that said...w eshould not suck at performance22:05
*** rcernin_ has quit IRC22:06
lbragstadnotmorgan gah!22:06
lbragstadnotmorgan so when we strip it down to the base basics - https://review.openstack.org/#/c/298748/422:06
patchbotlbragstad: patch 298748 - keystone - Refactor to allow for service provider caching22:06
lbragstadwe will fail on another *different* circular dependency22:06
lbragstadhttp://cdn.pasteraw.com/jybhso7rfr2yqhc0xjsyjrjh403hu0l22:07
notmorganlbragstad: so we need to fix some import orders/where things live22:09
*** ayoung has joined #openstack-keystone22:11
*** ChanServ sets mode: +v ayoung22:11
*** KarthikB has quit IRC22:13
openstackgerritMerged openstack/keystoneauth: Apply a heuristic for product name if a user_agent is not provided  https://review.openstack.org/28817522:13
*** KarthikB has joined #openstack-keystone22:14
notmorganstevemar: what makes you think i'm happy :P22:14
*** KarthikB has quit IRC22:15
*** KarthikB has joined #openstack-keystone22:15
*** KarthikB has quit IRC22:17
*** KarthikB has joined #openstack-keystone22:17
*** KarthikB_ has joined #openstack-keystone22:19
*** openstackgerrit has quit IRC22:19
*** openstackgerrit has joined #openstack-keystone22:20
*** KarthikB has quit IRC22:22
*** KevinE has quit IRC22:23
*** KarthikB_ has quit IRC22:24
notmorganFYI we're getting a policy file validation error bug being opened22:27
notmorganwe should really make it better ( devananda will hand us the bugid soonish)22:27
*** edmondsw has quit IRC22:28
*** rk4n has quit IRC22:28
*** henrynash has joined #openstack-keystone22:29
*** ChanServ sets mode: +v henrynash22:29
*** dave-mccowan has quit IRC22:30
*** devananda has joined #openstack-keystone22:31
devanandanotmorgan: https://bugs.launchpad.net/oslo.policy/+bug/158855222:31
openstackLaunchpad bug 1588552 in oslo.policy "policy file validation errors are hard to debug" [Undecided,New]22:31
notmorgandevananda: thanks!22:32
*** frontrunner has quit IRC22:38
*** edtubill has joined #openstack-keystone22:41
*** agrebennikov has quit IRC22:42
*** samueldmq has quit IRC22:48
*** pushkaru has quit IRC22:48
*** dave-mccowan has joined #openstack-keystone22:48
*** roxanagh_ has joined #openstack-keystone22:52
*** adu has quit IRC22:52
*** frontrunner has joined #openstack-keystone22:56
*** roxanagh_ has quit IRC22:56
*** lucas__ has joined #openstack-keystone22:58
*** markvoelker has joined #openstack-keystone22:58
*** lucas___ has joined #openstack-keystone23:00
*** lucas____ has joined #openstack-keystone23:02
*** lucas__ has quit IRC23:02
*** markvoelker has quit IRC23:03
*** ThomasHsiao has quit IRC23:04
*** ayoung has quit IRC23:04
*** lucas___ has quit IRC23:05
*** tonytan4ever has joined #openstack-keystone23:06
*** lucas____ has quit IRC23:06
*** r-daneel has joined #openstack-keystone23:07
*** lucas__ has joined #openstack-keystone23:09
*** rcernin has quit IRC23:10
*** lucas__ has quit IRC23:12
*** lucas___ has joined #openstack-keystone23:12
*** edtubill has quit IRC23:12
*** lucas__ has joined #openstack-keystone23:13
*** lucas___ has quit IRC23:17
*** pushkaru has joined #openstack-keystone23:17
*** lucas__ has quit IRC23:18
*** agireud has quit IRC23:19
*** BjoernT has quit IRC23:20
*** david-lyle has joined #openstack-keystone23:20
*** agireud has joined #openstack-keystone23:21
*** pushkaru has quit IRC23:22
*** lhcheng has quit IRC23:22
*** adu has joined #openstack-keystone23:23
*** roxanaghe has quit IRC23:29
openstackgerritOpenStack Proposal Bot proposed openstack/keystoneauth: Updated from global requirements  https://review.openstack.org/32483023:30
*** shaleh has quit IRC23:39
*** henrynash has quit IRC23:43
*** timcline_ has quit IRC23:49
*** roxanaghe has joined #openstack-keystone23:52
*** iurygregory_ has joined #openstack-keystone23:53
*** sdake has joined #openstack-keystone23:54
*** sdake_ has quit IRC23:56
*** roxanaghe has quit IRC23:57
*** sdake has quit IRC23:57

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!