Tuesday, 2016-02-23

*** shoutm has joined #openstack-keystone00:01
*** ayoung has joined #openstack-keystone00:01
*** ChanServ sets mode: +v ayoung00:01
*** porunov has quit IRC00:02
kfox1111is gnocchi 2.0 compatable with data written by gnocchi 1.0 with the ceph backend?00:03
gyeestevemar, bknudson, https://review.openstack.org/#/c/283315/00:04
patchbotgyee: patch 283315 - keystonemiddleware (stable/liberty) - Disble deprecation warning check when loading auth...00:04
*** diazjf1 has quit IRC00:12
*** mylu has quit IRC00:13
openstackgerritBrant Knudson proposed openstack/keystone: Fix project-related forbidden response messages  https://review.openstack.org/28332500:15
*** mylu has joined #openstack-keystone00:20
*** mylu has quit IRC00:34
*** mylu has joined #openstack-keystone00:35
*** roxanaghe has quit IRC00:40
*** mylu has quit IRC00:40
*** gyee has quit IRC00:47
*** sdake_ has joined #openstack-keystone00:49
*** sdake_ has quit IRC00:49
*** sdake_ has joined #openstack-keystone00:49
*** sdake has quit IRC00:51
*** sdake_ has quit IRC00:56
*** edmondsw has joined #openstack-keystone00:56
*** tobasco has quit IRC00:56
*** jdennis1 has joined #openstack-keystone00:57
*** jdennis has quit IRC00:57
*** mylu has joined #openstack-keystone00:59
*** mylu has quit IRC01:00
*** tobasco has joined #openstack-keystone01:05
*** mylu has joined #openstack-keystone01:05
*** diazjf has joined #openstack-keystone01:07
*** EinstCrazy has joined #openstack-keystone01:16
*** davechen_afk is now known as spring01:32
*** spring is now known as Guest7006301:33
*** Guest70063 is now known as grassy01:33
*** davechen has joined #openstack-keystone01:33
*** lhcheng has quit IRC01:35
*** clenimar has joined #openstack-keystone01:39
*** EinstCrazy has quit IRC01:40
*** spandhe has quit IRC01:41
*** EinstCrazy has joined #openstack-keystone01:42
*** clenimar has quit IRC01:42
*** sdake has joined #openstack-keystone01:57
*** edmondsw has quit IRC01:59
*** tobasco has quit IRC02:01
*** sdake has quit IRC02:04
*** browne has quit IRC02:05
*** mylu has quit IRC02:06
*** mylu has joined #openstack-keystone02:07
*** tobasco has joined #openstack-keystone02:07
*** sdake has joined #openstack-keystone02:07
*** lhcheng has joined #openstack-keystone02:08
*** ChanServ sets mode: +v lhcheng02:08
*** su_zhang has quit IRC02:09
*** mylu has quit IRC02:09
*** mylu has joined #openstack-keystone02:09
*** su_zhang has joined #openstack-keystone02:09
*** dims has quit IRC02:13
*** su_zhang has quit IRC02:14
*** mylu has quit IRC02:14
*** jasonsb has joined #openstack-keystone02:15
*** mylu has joined #openstack-keystone02:16
davechenbknudson: hi, around?02:23
*** mylu has quit IRC02:29
*** mylu has joined #openstack-keystone02:29
*** jorge_munoz has joined #openstack-keystone02:30
*** neophy has joined #openstack-keystone02:33
*** mylu has quit IRC02:36
*** sdake has quit IRC02:38
*** mylu has joined #openstack-keystone02:38
*** sdake has joined #openstack-keystone02:39
*** diazjf has quit IRC02:39
*** sdake has quit IRC02:41
*** phalmos has joined #openstack-keystone02:44
*** phalmos has quit IRC02:45
*** phalmos has joined #openstack-keystone02:45
*** dan_nguyen has quit IRC02:47
*** mylu has quit IRC02:47
*** mylu has joined #openstack-keystone02:48
*** phalmos has quit IRC02:50
*** mylu has quit IRC02:52
*** fawadkhaliq has joined #openstack-keystone02:52
*** mylu has joined #openstack-keystone02:53
*** LZ has joined #openstack-keystone02:57
*** GB21 has quit IRC03:02
*** phalmos has joined #openstack-keystone03:06
*** mylu has quit IRC03:08
*** mylu has joined #openstack-keystone03:10
*** mylu has quit IRC03:16
*** jdennis1 has quit IRC03:16
*** mylu has joined #openstack-keystone03:16
openstackgerritJorge Munoz proposed openstack/keystone: Reduce revoke events for disabled domains and projects.  https://review.openstack.org/25327303:16
ayoungGAH!  I was going to do something so simple, so elegant.  Just, duplicate the "main"  pipeline on port 80 (soon to be 443) but I'm getting a an error trying to opmne the keystlone log03:17
stevemarayoung: womp womp03:17
stevemardavechen: whats up?03:17
ayoungstevemar, is it true that two different things can't open the same log file?03:17
ayoungor am I trying to do it as the wrong user...but I see the wsgi app running as the keystone user03:17
stevemartwo can probably open, maybe not write03:17
*** mylu has quit IRC03:19
davechenstevemar: just wanna ask Brant when we didn't add the domain_id to users, which change made this.03:20
davechenstevemar: just curious about that when i saw this patch - https://review.openstack.org/#/c/282042/203:20
patchbotdavechen: patch 282042 - keystone - db_sync doesn't create default domain03:20
ayoungstevemar, I think we are making shadow users way too complicated. Just a quick check:  do we really want to go that way?03:21
*** jdennis has joined #openstack-keystone03:21
ayoungstevemar, its just a knee jerk reaction.  I know we need "something" along those lines.03:22
ayoungBut, anyway...03:22
openstackgerritClenimar Filemon proposed openstack/keystone: Fix incorrect assumption when deleting assignments  https://review.openstack.org/28269603:24
*** spzala has joined #openstack-keystone03:28
*** davechen is now known as davechen_afk03:31
*** ccard__ has joined #openstack-keystone03:32
*** jorge_munoz has quit IRC03:32
ayoungstevemar, https://review.openstack.org/#/c/282017/3  is the epitome of the succinct code review.  Care to push trhe button?03:33
patchbotayoung: patch 282017 - python-keystoneclient - Support creation of domain specific roles03:33
*** ccard_ has quit IRC03:35
morganayoung: what is too complex [what part]?03:37
stevemarayoung: i think shadow users is a must03:37
morganayoung: or just the whole thing?03:37
* morgan still doesn't like the "name shadow user"03:37
stevemarmorgan: the bikeshed is over there *points*03:37
ayoungstevemar, I think the whole thing can be in one table03:38
* morgan wishes we could just move to where everything is just a user and we can connect/link federated user to the "user" like some things03:38
ayoungwe need shadow users, I conceed03:38
ayoungconcede03:38
ayoungconceded that point a long time back03:38
morganayoung: that much i can say i think is wrong. we probably need a couple tables not just one03:38
morgan<user> | <identity source> | <password, for $reasons$> makes sense03:38
ayoungpassword can be split03:38
morganif you support more than one identity / authn source03:39
morganyou need a many-to-one table03:39
stevemardavechen_afk: not sure i understand your question?03:39
ayoungso two tables: users, paasswords, sure03:39
*** browne has joined #openstack-keystone03:39
stevemardavechen_afk: domain_id wasn't added to users03:39
morganso <user> (local representation of data for the user, keystone/openstack specific), Password (yep), and then the map of IDP source/IDP ID -> user03:39
ayoungmorgan, I don;t want to derail it.  I just struck me each time I looked at it that I never liked having the id_mapping table and that we are making more of them03:39
morgansure, but i think we need to future proof this03:40
morganif we do it all in the user table, we get 1 and only 1 identity source03:40
*** fawadkhaliq has quit IRC03:40
morganwe could probably merge the identity mapping backend thing03:40
ayoungmy gut says that this approach will work, but likely can be refactored to something simpler.  Kindof like how I think the oauth code that stevemar wrote back in the stone age can merge with trusts03:40
stevemardef. stone age03:41
morgansure, so the real benefit right now is this is all internal03:41
ayoungI still think we need to look at the relationship between Idps and domains03:41
morgansure. but you also need IDP<ID> -> User03:41
morganand you want more tha one IDP to be able to login to a local user.03:41
ayoungmorgan, why not by way of domain03:41
ayoungidp->domain->user03:41
ayoungone IdP to one domain is the norm03:42
morganmost of the time the IDP isn't domain specific in application03:42
morgans03:42
ayoungmaybe we go one-to-many03:42
morganYou can map Google|Facebook|OIDC<generic> to <user>03:42
ayoungbut users from one Idp probably should all go into one domain03:42
ayoungsee...there is something different about those...03:42
ayoungthe public IdPs...03:43
ayoungI don;'t know, sometimes I feel like I am relearning this each time we discuss it03:43
morganbut it's a known pattern03:43
morganand it wouldn't be broken in the internal cloud/hosted cloud model03:43
ayoungOK...so, ayoung@redhat and admiyo@launchpad are both my accounts, but they still should be separable03:43
morganbut if we *needed* all google auth (for example) to go to a single domain, you might break the "public" format03:44
ayoungjust becuase they are both me don't mean they come out of the same budget03:44
*** fawadkhaliq has joined #openstack-keystone03:44
morganbut do you agree that ayound@redhat and adimyo@launchpad *could* be two ways to login to the same user?03:44
ayoungaand I actually have 2 google Ids, I think, because redhat contracts with google03:44
ayoungso I can get google auth to confirm me as ayoung@redhat03:44
morganassuming you aren't talking internal redhat cloud03:44
*** fawadkhaliq has quit IRC03:44
*** fawadkhaliq has joined #openstack-keystone03:45
morgannothing says you can't make them separate, but why make it always separate and not allowed to be the same user?03:45
* morgan is playing devils advocate03:45
*** fawadkhaliq has quit IRC03:45
* morgan really doesn't have much of a horse in this race03:45
ayoungmorgan, so...I sort of agree, but what if I get tossed from redhat, but have used other resources to create things using admiyo@launchpad?03:45
morganthe local user could be disabled.03:45
morganor the grant to <redhat> domain is revoked03:46
ayoungthere was an article  I read  a long time ago about medical records, and the issues with identifying people that came in to an ER03:46
morganbut the user may have access to another domain, and adimyo@launchpad is still valid03:46
morgansince billing based on <domain>|<project>03:46
morgannot based on <user>03:46
ayoungthe whole : we don't know who you are, so we start a new record...3 days later you wake up and say you are "adam young" and they link your records, but then find out hey linked them with the wrong "Adam Young"03:47
morganbut the difference here is you have a known account03:47
morganvs an unknown03:47
ayoungIts like we want to make sure everything is tagged by the credential used to make the resource.  But then link resources to the same account?03:47
morganyou assert (and have credentials) for account X03:47
morganso you as ayoung, link the account03:47
morganvs. <nameless admin> linking without your knowledge03:48
ayoungright...it is that distinction...03:48
morganyou're asserting you can login to user anyway, so you wish to link another authn (if allowed) to use it03:48
morganif you can't login, you can't link the other idp.03:49
morganand by that token long term the deployer needs to restrict (policy?) the ability to link <random IDP> in03:49
*** dims has joined #openstack-keystone03:49
ayoungmorgan, my point is that deactivating my redhat credential should not block me from using my launchpad account to authenticate, but it should prevent me from getting any more quota from a project paid for by redhat...unless I am contractor and explicitly added back in?03:50
ayoungGuh03:50
ayoungOK...I've made my own head hurt03:50
morganright, but blocking your redhat access is likely more than blocking your user, if it's a shared cloud, it is likely revoking your grant to the redhat project03:50
morganfor the local user.03:50
*** spandhe has joined #openstack-keystone03:50
ayoungthe use case I needed to be able to solve was a user coming in via two different auth mechanisms getting mapped to the same identity:  SAML v. Kerberos\03:51
*** spzala has quit IRC03:51
ayoungBut that is just two ways of exposing the same data, just a difference in mapping03:51
morganright03:51
*** spzala has joined #openstack-keystone03:51
morgani'm aiming at the RAX case03:51
ayoungWe do want to limit who can map *in* to a domain03:51
morganyour case is straightforward comparatively03:51
morganand yes that is a deployer choice i think03:52
ayoungright now, only the domain admin can set up the mapping rules, and that does not really scale03:52
morganunfortunately, we also have public clouds that you want <public IDP> to work.03:52
ayoung"they can't do that to our pledges!"03:52
morganso. i think maybe the current design is the RAX case but it doesn't break your use case?03:52
morganwhere if we only allowed per-domain, the RAX case wouldn't work? i think...03:53
morgani *think*03:53
morganif someone wants to use FB and Google and Launchpad OIDC, public clouds may want to let them all use any/all of those forms at once? i just don't know03:54
*** spzala has quit IRC03:55
*** mylu has joined #openstack-keystone03:57
*** sdake has joined #openstack-keystone04:00
*** mylu has quit IRC04:00
*** fpatwa_ has joined #openstack-keystone04:01
*** links has joined #openstack-keystone04:03
*** shoutm_ has joined #openstack-keystone04:04
*** fpatwa_ has quit IRC04:05
*** shoutm has quit IRC04:05
openstackgerritMaho Koshiya proposed openstack/python-keystoneclient: Add wrapper classes for return-request-id-to-caller  https://review.openstack.org/26118804:09
*** wolsen has quit IRC04:10
ayoungmorgan, care to https://review.openstack.org/#/c/282017/  kick that one over the edge04:10
patchbotayoung: patch 282017 - python-keystoneclient - Support creation of domain specific roles04:10
ayoungWOOOOT04:14
*** mylu has joined #openstack-keystone04:14
ayoungstevemar, got it:  And with that, I think we have a path to Keystomne running on port 443!04:14
ayounghttp://paste.openstack.org/show/487828/  worked.04:15
*** richm has quit IRC04:21
*** sdake has quit IRC04:28
*** GB21 has joined #openstack-keystone04:33
*** su_zhang has joined #openstack-keystone04:36
*** Nirupama has joined #openstack-keystone04:44
*** GB21 has quit IRC04:49
*** GB21 has joined #openstack-keystone04:49
stevemarayoung: i'll look at the DSR stuff in ksc soon05:13
*** su_zhang has quit IRC05:27
*** su_zhang has joined #openstack-keystone05:28
*** browne has quit IRC05:30
*** diazjf has joined #openstack-keystone05:35
*** woodster_ has quit IRC05:36
*** GB21 has quit IRC05:41
*** GB21 has joined #openstack-keystone05:41
*** sdake has joined #openstack-keystone05:41
*** ankita_wagh has joined #openstack-keystone05:46
*** spandhe has quit IRC05:46
*** tomoiaga has joined #openstack-keystone05:48
*** dims has quit IRC05:54
*** jorge_munoz has joined #openstack-keystone05:54
*** GB21 has quit IRC05:55
*** GB21 has joined #openstack-keystone05:55
*** mylu has quit IRC05:57
*** sdake has quit IRC05:57
*** mylu has joined #openstack-keystone05:58
*** davechen_afk is now known as davechen06:01
*** shoutm_ has quit IRC06:05
*** wasmum has quit IRC06:08
davechenstevemar: thanks, the commit message says domain_id wasn't added to users anymore, so i think it was added to users at one time.06:09
*** shoutm has joined #openstack-keystone06:10
openstackgerritJorge Munoz proposed openstack/keystone: Reduce revoke events for disabled domains and projects.  https://review.openstack.org/25327306:14
stevemarthanks jorge_munoz :)06:14
jorge_munoznp :)06:16
*** jorge_munoz has quit IRC06:16
*** fawadkhaliq has joined #openstack-keystone06:18
*** shoutm has quit IRC06:19
*** GB21 has quit IRC06:21
*** fpatwa_ has joined #openstack-keystone06:21
*** GB21 has joined #openstack-keystone06:24
*** mariusv has quit IRC06:25
*** shoutm has joined #openstack-keystone06:25
openstackgerritfengzhr proposed openstack/keystone: The name can be just white character except project and user  https://review.openstack.org/27235806:28
*** jorge_munoz has joined #openstack-keystone06:31
*** mylu has quit IRC06:31
*** mariusv has joined #openstack-keystone06:32
*** mariusv is now known as Guest9803906:32
*** jaosorior has joined #openstack-keystone06:37
openstackgerritMerged openstack/python-keystoneclient: Support creation of domain specific roles  https://review.openstack.org/28201706:39
*** fpatwa_ has quit IRC06:41
*** diazjf has quit IRC06:43
*** GB21 has quit IRC06:47
*** GB21 has joined #openstack-keystone06:47
*** lhcheng has quit IRC06:48
stevemardavechen: poke06:49
davechenstevemar: yes sir06:49
*** Guest98039 has quit IRC06:53
*** marius- has joined #openstack-keystone06:53
*** marius- has quit IRC06:54
*** josecastroleon has joined #openstack-keystone07:00
*** neophy has quit IRC07:07
stevemardavechen: i have a request -- can you update the cascade fix for the implied role patch?07:11
*** fawadkhaliq has quit IRC07:11
stevemaryou seem to have a good handle on it, i saw your test on the abandoned patch, it looked good07:12
davechenstevemar: sure.07:12
stevemari'll continue with it when i wake up07:12
davechenstevemar: will work on that.07:12
stevemar\o/07:12
stevemardavechen: you can remove the rally and functional test code, nothing runs it :(07:13
davechenstevemar: and possibly split the patch into two paches.07:13
davechenstevemar: yep;07:13
stevemargood, we're of the same opinion :)07:13
davechenstevemar: :)07:14
stevemarbed time for me!07:14
stevemardavechen: thanks sir07:14
davechenstevemar:  good night sir!07:14
davechenstevemar: np.07:14
*** porunov has joined #openstack-keystone07:16
*** vinaym213 has joined #openstack-keystone07:32
vinaym213hello all07:33
vinaym213morning07:33
davechenvinaym213: good morning.07:33
vinaym213Getting an issue while deploying devstack on ubuntu 14.0407:33
vinaym213davechen , morning07:34
vinaym213related to keystone07:34
vinaym213http://paste.openstack.org/show/487834/07:34
vinaym213Any idea :007:34
vinaym213:)07:34
davechenrm ~/.config/openstack/clouds.yaml and try again.07:36
vinaym213No that file doesn't exist on my setup07:37
*** GB21 has quit IRC07:38
davechenvinaym213: maybe this thread is helpful - http://www.gossamer-threads.com/lists/openstack/dev/5250707:43
*** jed56 has joined #openstack-keystone07:44
*** jaosorior has quit IRC07:50
*** lhcheng has joined #openstack-keystone07:51
*** ChanServ sets mode: +v lhcheng07:51
*** boris-42 has quit IRC07:54
*** pcaruana has joined #openstack-keystone07:58
*** jaosorior has joined #openstack-keystone08:05
*** pcaruana is now known as pcaruana|afk|08:08
*** pcaruana|afk| is now known as pcaruana08:08
*** vinaym213 has quit IRC08:13
*** Oku_OS has quit IRC08:13
*** martinus___ has joined #openstack-keystone08:14
*** vinaym213 has joined #openstack-keystone08:14
*** mariusv has joined #openstack-keystone08:20
*** GB21 has joined #openstack-keystone08:23
*** ankita_wagh has quit IRC08:23
*** subscope has joined #openstack-keystone08:32
*** subscope has quit IRC08:36
*** daemontool has joined #openstack-keystone08:38
*** josecastroleon has quit IRC08:43
*** shoutm has quit IRC08:45
*** subscope has joined #openstack-keystone08:47
*** shoutm has joined #openstack-keystone08:48
*** rk4n has joined #openstack-keystone08:49
*** jistr has joined #openstack-keystone08:49
*** josecastroleon has joined #openstack-keystone08:50
*** su_zhang has quit IRC08:53
*** su_zhang has joined #openstack-keystone08:54
*** su_zhang has quit IRC08:58
*** fhubik has joined #openstack-keystone09:01
*** fhubik is now known as fhubik_brb09:01
*** daemontool has quit IRC09:05
*** henrynash has joined #openstack-keystone09:05
*** ChanServ sets mode: +v henrynash09:05
*** fhubik_brb is now known as fhubik09:06
*** shoutm has quit IRC09:17
*** subscope has quit IRC09:20
*** shoutm has joined #openstack-keystone09:23
*** mvk has quit IRC09:26
openstackgerritJorge Munoz proposed openstack/keystone: Reduce revoke events for disabled domains and projects.  https://review.openstack.org/25327309:28
*** jorge_munoz has quit IRC09:29
*** phalmos has quit IRC09:33
*** subscope has joined #openstack-keystone09:43
openstackgerritDave Chen proposed openstack/keystone: Implied roles index with cascading update/delete  https://review.openstack.org/28192109:46
openstackgerritDave Chen proposed openstack/keystone: Implied roles index with cascading delete  https://review.openstack.org/28192109:49
*** mvk has joined #openstack-keystone09:53
*** davechen has left #openstack-keystone09:55
*** subscope has quit IRC09:57
samueldmqmorning keystoners10:00
*** subscope has joined #openstack-keystone10:02
*** rk4n_ has joined #openstack-keystone10:03
*** fawadkhaliq has joined #openstack-keystone10:03
*** rk4n has quit IRC10:04
*** fhubik is now known as fhubik_brb10:04
*** rk4n has joined #openstack-keystone10:04
*** fhubik_brb is now known as fhubik10:04
*** henrynash has quit IRC10:06
bretonmorning10:06
*** rk4n_ has quit IRC10:08
*** vinaym213 has quit IRC10:10
*** vinaym213 has joined #openstack-keystone10:10
*** fawadkhaliq has quit IRC10:14
*** fawadkhaliq has joined #openstack-keystone10:14
*** EinstCrazy has quit IRC10:15
*** bdossant has joined #openstack-keystone10:16
*** belmoreira has joined #openstack-keystone10:17
*** daemontool has joined #openstack-keystone10:28
daemontoolall, I'm setting up keystone federated with saml2 as a protocol10:28
daemontoolI'm adding the [saml2] group in keystone.conf but when i print the conf the saml2 group is not there :(10:29
daemontoolanyone has any hint?10:29
daemontoolso basically I'm adding groups in the keystone.conf but that they are not processed10:29
*** fhubik is now known as fhubik_brb10:29
*** fhubik_brb is now known as fhubik10:30
*** jorge_munoz has joined #openstack-keystone10:33
odyssey4medaemontool I'm confused - you're adding a section to keystone.conf and it isn't there?10:35
daemontool odyssey4me  exactly10:35
daemontoolI add [saml2]10:35
daemontoolthen I print all the keys in the CONF dict10:35
daemontoolso [saml] is there10:35
daemontoolwhile [saml2] is not10:35
odyssey4medaemontool ah, I see10:36
odyssey4medaemontool as far as I know, the section should be '[saml]' and then in the [auth] section you need 'saml2' in the 'methods' key list, and saml2 may need to be mapped like so: https://github.com/openstack/openstack-ansible/blob/master/playbooks/roles/os_keystone/templates/keystone.conf.j2#L5210:37
daemontoollooking10:37
*** henrynash has joined #openstack-keystone10:38
*** ChanServ sets mode: +v henrynash10:38
*** jorge_munoz has quit IRC10:38
odyssey4meI last worked with making federation work using the Kilo code-base so I'm a little rusty, but with OpenStack-Ansible we deploy it like that. The saml section starts here: https://github.com/openstack/openstack-ansible/blob/master/playbooks/roles/os_keystone/templates/keystone.conf.j2#L10910:38
odyssey4meI take it that you're setting Keystone up as an IDP?10:39
odyssey4meIf you're setting it up only as an SP, then those sections aren't required.10:39
daemontoolodyssey4me, nope we are setting keyystone only as SP10:41
daemontoolthe IDP is openam (forgerock)10:41
*** lhcheng has quit IRC10:41
odyssey4medaemontool ah, in that case all you need is the SP related configs10:41
odyssey4medaemontool ie https://github.com/openstack/openstack-ansible/blob/master/playbooks/roles/os_keystone/templates/keystone.conf.j2#L157-L16510:42
odyssey4methen you need to configure mod_shib / mod_mellon / <insert your saml2 provider here>10:42
*** Nirupama has quit IRC10:42
odyssey4mein OpenStack-Ansible we configure Keystone behind Apache2 and for SAML2 federation we use mod_shib10:43
odyssey4memod_shib requires additional config, one is in Apache to tell it to trust mod_shib to handle auth: https://github.com/openstack/openstack-ansible/blob/master/playbooks/roles/os_keystone/templates/keystone-httpd.conf.j2#L33-L5710:44
daemontoolif I do not add the [saml2] group in keystone.conf from the logs it returns an error saying it cannot find the group saml210:45
daemontoolyes we use mellon10:45
daemontoolI should be almost there....10:45
odyssey4medaemontool you only need that section if you have it referred to somewhere10:45
daemontoolok10:45
odyssey4meperhaps you have it referred to in your auth section's method list?10:46
daemontoolyes10:47
daemontool[auth]10:47
daemontoolmethods = external,password,token,saml210:47
daemontoolsaml2 = keystone.auth.plugins.mapped.Mapped10:47
*** shoutm_ has joined #openstack-keystone10:48
daemontoolso I need to remove the saml2 attribute there?10:48
daemontoolIf I remove it, it returns Internal server error10:49
odyssey4medaemontool yes, that's only used if Keystone is an IDP. You can also remove saml2 = ... as that's also for the IDP bits10:49
daemontoolah brilliant, let me try10:50
*** shoutm has quit IRC10:50
daemontoolso removed both saml2 from auth group in keystone.conf10:51
odyssey4meanother thing - I see that you have 'external' in the auth method list - what's that for?10:51
odyssey4mein our configs we only have 'password,token' for Keystone as an SP10:51
*** spzala has joined #openstack-keystone10:52
*** Oku_OS has joined #openstack-keystone10:52
daemontoolI think it was already there by default10:52
daemontooltrying to remove it10:52
odyssey4medaemontool something else worth noting, although I think the issues have been sorted out - for the Kilo code base fernet tokens didn't work so we had to revert to using UUID tokens when Federation was being used10:53
daemontoolyes we use UUID10:54
daemontoolI get the following error now:10:55
daemontool{"error": {"message": "Attempted to authenticate with an unsupported method. (Disable debug mode to suppress these details.)", "code": 401, "identity": {"methods": [password", "token"]}, "title": "Unauthorized"}}10:55
odyssey4methe issue I saw was fixed in Liberty: https://bugs.launchpad.net/keystone/+bug/147128910:55
openstackLaunchpad bug 1471289 in OpenStack Identity (keystone) kilo "Fernet tokens and Federated Identities result in token scope failures" [High,In progress] - Assigned to Dolph Mathews (dolph)10:55
daemontoolmmhh...10:55
odyssey4mehmm, unauthorised10:55
odyssey4mea few checks here10:56
daemontoolunauthorized mean the authentication work but not the authorization?10:56
daemontoolok10:56
*** spzala has quit IRC10:56
odyssey4methe client, server and service catalogue all need to be using the same address that's configured in the IDP and the SP10:56
daemontoolok checking10:57
odyssey4mein the IDP I was testing with, SSL for any SP endpoints was required, so the public endpoint needed to be both SSL and using a DNS name to ensure that the SSL connection worked properly10:57
*** Nirupama has joined #openstack-keystone10:58
odyssey4mealso, I found that Keystone would reply back through Apache with a different address to the one in the public endpoint, so I had to set the 'public_endpoint' entry in keystone.conf to make sure that Keystone always gave back the right address11:00
odyssey4meIf you're using Horizon WebSSO then you need to also ensure that Horizon is configured to use Keystone's public endpoint because Horizon will redirect to Keystone which will then redirect to the IDP.11:01
*** fhubik has quit IRC11:02
odyssey4meoh, and of course, an essential piece of information - Federation requires Keystone v3 API endpoints to be configured and used11:02
daemontoolodyssey4me,  yes we use v311:02
*** fawadkhaliq has quit IRC11:03
odyssey4medaemontool keystone.conf will require the 'trusted_dashboard = <URL>' for each dashboard URL if you're using WebSSO, and the URL will be of the form: "https://{{ horizon_server_name }}/auth/websso/"11:04
daemontoolin the endpoint list I have keystone only on admin and internal11:04
daemontoolok11:04
daemontoolthe strange thing I see is11:05
daemontoolopenstack --os-identity-api-version 3  identity provider show unica11:05
daemontool+-------------+-----------+11:05
daemontool| Field       | Value     |11:05
daemontool+-------------+-----------+11:05
daemontool| description | Unica Idp |11:05
daemontool| enabled     | True      |11:05
daemontool| id          | unica     |11:05
*** martinus___ has quit IRC11:05
daemontool| remote_ids  | []        |11:05
daemontool+-------------+-----------+11:05
daemontoolthere remote_ids is empty in the db11:05
odyssey4meyeah, that's not right I don't think: http://docs.openstack.org/developer/openstack-ansible/install-guide/configure-federation-use-case.html#identity-providers-on-the-service-provider11:07
odyssey4mewe have some samples recorded there to help with troubleshooting11:07
odyssey4meyou must have created that IDP though, so you can update the remote_id11:07
odyssey4medo you know the right URL for your provider's SAML2 endpoint?11:08
daemontoolyes11:09
daemontoolI could try to set it with11:09
daemontoolopenstack identity provider set ....11:09
daemontoolsomething like that?11:09
odyssey4meyes, I think so - my memory is foggy, but it sounds right11:11
daemontoolodyssey4me, yes thanks a lot trying11:11
*** subscope has quit IRC11:21
*** davechen has joined #openstack-keystone11:23
*** rodrigods has quit IRC11:24
*** rodrigods has joined #openstack-keystone11:24
*** Nirupama has quit IRC11:31
*** fhubik has joined #openstack-keystone11:35
openstackgerritDavid Stanek proposed openstack/keystone: Updates TOTP release note  https://review.openstack.org/28352011:35
openstackgerritDavid Stanek proposed openstack/keystone: Renamed TOTP passcode generation function  https://review.openstack.org/28352111:35
openstackgerritDavid Stanek proposed openstack/keystone: WIP - Add validation for totp credentials  https://review.openstack.org/28352211:35
openstackgerritDavid Stanek proposed openstack/keystone: WIP - credential algorithms  https://review.openstack.org/28352311:35
*** Nirupama has joined #openstack-keystone11:39
*** henrynash has quit IRC11:41
*** mancdaz has joined #openstack-keystone11:42
*** josecastroleon has quit IRC11:42
*** GB21 has quit IRC11:45
*** davechen1 has joined #openstack-keystone11:50
*** davechen has quit IRC11:52
*** EinstCrazy has joined #openstack-keystone11:52
*** mancdaz has quit IRC11:56
*** subscope has joined #openstack-keystone11:58
*** mancdaz has joined #openstack-keystone11:58
*** Nirupama has quit IRC12:01
*** Nirupama has joined #openstack-keystone12:16
*** davechen1 has left #openstack-keystone12:23
*** spzala has joined #openstack-keystone12:26
*** raildo-afk is now known as raildo12:26
*** lhcheng has joined #openstack-keystone12:30
*** ChanServ sets mode: +v lhcheng12:30
*** josecastroleon has joined #openstack-keystone12:30
*** spzala has quit IRC12:30
raildostevemar: are you around? it's about: https://review.openstack.org/#/c/243585/12:31
patchbotraildo: patch 243585 - keystone - API support for project cascade update12:31
*** fhubik is now known as fhubik_brb12:31
* raildo love this patchbot12:31
*** gordc has joined #openstack-keystone12:34
*** lhcheng has quit IRC12:34
*** jorge_munoz has joined #openstack-keystone12:34
*** links has quit IRC12:38
*** jorge_munoz has quit IRC12:39
*** shoutm has joined #openstack-keystone12:46
*** shoutm_ has quit IRC12:47
*** fesp has joined #openstack-keystone12:49
*** mvk has quit IRC12:49
*** mvk has joined #openstack-keystone12:50
*** henrynash has joined #openstack-keystone12:50
*** ChanServ sets mode: +v henrynash12:51
*** shoutm has quit IRC12:51
*** fesp has quit IRC12:51
*** fesp has joined #openstack-keystone12:53
*** martinus___ has joined #openstack-keystone12:55
*** shoutm has joined #openstack-keystone12:57
*** henrynash has quit IRC13:01
*** vinaym213 has quit IRC13:03
*** subscope has quit IRC13:05
*** fesp has quit IRC13:05
dstanekdolphm: i was just looking at the shadow users patch trying to figure out why the expression is there and if it works; do you know if it does?13:13
*** pauloewerton has joined #openstack-keystone13:13
dolphmdstanek: i asked rderose that the other day -- it's part of / required for the hybrid property, but i haven't read that deeply into the docs13:15
dolphmdstanek: http://docs.sqlalchemy.org/en/latest/orm/extensions/hybrid.html#defining-expression-behavior-distinct-from-attribute-behavior13:15
dolphmdstanek: we're not doing anything special with the expression other than referencing a different attribute13:16
dolphm(from a different table)13:16
Anticimexmarekd: what was the issue with lxml vs SAML2?  looking at https://review.openstack.org/#/c/242512/13:17
patchbotAnticimex: patch 242512 - keystoneauth - Switch saml2 from lxml to built-in xml13:17
dstanekdolphm: yeah, that's what concerns me. wring a test now, but my initial test is that it works just as well to return None13:17
dolphmdstanek: as in, sqlalchemy writes to the correct (new) table anyway?13:20
*** fhubik_brb is now known as fhubik13:21
dolphmor rather, reads13:21
dstanekdolphm: oh, interesting. we are not really using the expression (at least in the subset of tests i ran), but sqlalchemy turns a filter on User.name to a join.13:21
*** subscope has joined #openstack-keystone13:22
dstaneks/to/into/13:22
dstanekdolphm: there's no problem with the patch other than maybe a hidden performance penalty for using those attributes13:23
*** links has joined #openstack-keystone13:23
dolphmdstanek: a performance penalty beyond joins?13:29
dstanekdolphm: just the join13:29
dolphmdstanek: i would like to have benchmark numbers between liberty and mitaka for a few user operations (including group membership crud)13:30
dstanekdolphm: that's a good call. i'm not worried to much about the join. it's just that it now obvious that a join is happening13:31
*** subscope has quit IRC13:32
dstanekdolphm: "session.query(User).filter_by(name='?')" joins implicitly13:32
*** henrynash has joined #openstack-keystone13:32
*** ChanServ sets mode: +v henrynash13:32
dolphmdstanek: to be fair, how else would you expect that to succeed? :P13:32
*** josecastroleon has quit IRC13:35
dstanekdolphm: exactly :)13:36
*** fhubik is now known as fhubik_brb13:39
daemontoolodyssey4me, ping13:40
*** henrynash has quit IRC13:40
*** henrynash has joined #openstack-keystone13:41
*** ChanServ sets mode: +v henrynash13:41
odyssey4medaemontool pong13:41
daemontool{"error": {"message": "Unable to find valid groups while using mapping unica_map (Disable debug mode to suppress these details.)", "code": 401, "title": "Unauthorized"}}13:41
*** josecastroleon has joined #openstack-keystone13:41
daemontoolI moved forward13:41
raildohenrynash: hey :) I'm trying to understand your suggestion on https://review.openstack.org/#/c/243585 it's something like.. "just create a new policy check for a query string it is better solution than create a new API call"?13:41
daemontoolbut I'm getting that error now13:41
daemontoolfrom the browser13:41
daemontoolafter inserting creds to the idp login page13:41
*** fhubik_brb is now known as fhubik13:41
odyssey4medaemontool are you using a CLI tool, or browser to do the auth?13:41
daemontoolbrowser13:41
odyssey4meok, so browser13:41
henrynashraildo: so I just added two suggestions….(one of which is that)13:41
odyssey4meright, now each IDP works a little different13:42
daemontoolwe are using forgerock13:42
odyssey4meare you using Horizon's WebSSO capability to redirect you to the IDP auth page - or are you doing to the IDP first and it's redirecting you to Horizon?13:42
henrynashraildo: either you treat tree operations as somethinge “special” and they have their own plicy endpoint (even though the share the API with the non-cascade version)13:42
raildohenrynash: can we use something like this, right? https://github.com/openstack/keystone/blob/a9a47b62c87c7838bc06b0ce31974b7ba460353b/keystone/assignment/controllers.py#L65713:42
*** Nirupama has quit IRC13:43
odyssey4medaemontool actually, looking at your error message it's likely a mapping issue - have you put together a map in keystone for your IDP attributes to map to your attributes coming from the IDP?13:44
henrynashraildo: yes, the list_assignments API gets “split” into two different policy endpints, depending on whether ther ?include_subtree query param is specified13:44
*** fhubik is now known as fhubik_brb13:44
*** edmondsw has joined #openstack-keystone13:45
*** subscope has joined #openstack-keystone13:45
daemontoolodyssey4me,  we are using this url http://localhost:5000/v3/OS-FEDERATION/identity_providers/{idp_id}/protocols/{protocol_id}/auth13:45
odyssey4medaemontool while the specifics regading the OSA config in the first paragraph won't apply to you, the explanation of everything afterwards and the CLI examples will: http://docs.openstack.org/developer/openstack-ansible/install-guide/configure-federation-mapping.html13:45
daemontoolfrom the browser13:46
daemontooland it redirects us to the forgerock login web ui13:46
odyssey4medaemontool and forgerock is on the same host?13:46
daemontoolodyssey4me,  ok I think I did that let me check13:46
daemontoolty13:46
daemontoolnope13:46
daemontoolwe use the right fqdn13:46
daemontoolit's on a dedicated node13:46
odyssey4medaemontool ok, but the browser needs to have the right referrer too, I would expect13:47
odyssey4meie you can't use 'localhost' in your URL13:47
*** wolsen has joined #openstack-keystone13:47
*** wolsen has quit IRC13:47
raildohenrynash: Do you think we can have a problem if an operator use different roles in this two different policy endpoints? in other words, sounds odd a user can perform a delete operation and can't perform a cascade? (or vice versa)13:47
daemontoolodyssey4me,  yes I copied and pasted that url from the docs guide13:47
daemontoolour url contain an fqdn13:48
daemontooland the uri is that one13:48
odyssey4medaemontool ok cool, just checking :)13:48
daemontoolgood good :)13:48
daemontoolthe referer header is there13:48
daemontoolin the http header13:48
daemontoolwe are using saml tracker13:48
daemontooltracer13:48
daemontoolto see the content13:49
daemontoolI think the problem is on the mapping13:49
henrynashraildo: so it’s certainly possible of course, but that’s down to the policy writer……13:49
daemontoolit cannot find a valid group13:49
daemontoolas it  is written in the error13:49
daemontoolbut I'm not sure at this point13:49
daemontoolhow to map/change that13:49
daemontoolodyssey4me,  do you want me to paste the mappings here?13:49
odyssey4medaemontool yep, I dunno if mod_mellon has something like mod_shib does which allows you to see current sessions and their data13:49
odyssey4medaemontool pastebin it, then share the URL13:50
henrynashraildo: I guess the quetsion is whether the /cascde policy endpoint covers the top project and all its chiildren….I think it should13:50
daemontoolodyssey4me,  http://paste.openstack.org/show/487890/13:55
*** subscope has quit IRC13:55
dancnHello, trying to run tox -e py27 on a fresh git clone -b stable/kilo keystone I was hit by conflicting pip dependencies as detailed in https://bugs.launchpad.net/oslo.concurrency/+bug/1543425 Do you have a suggestion for a quick way to run the keystone test?  Thanks in advance!13:58
openstackLaunchpad bug 1543425 in oslo.concurrency "stable/kilo: fixtures 1.2.0 isn't compatible with testtools 2.0.0" [Undecided,New]13:58
dolphmdstanek: any concerns worth -1 / -2?13:58
dolphmdstanek: oooh, just saw your +213:59
*** mvk has quit IRC14:00
dstanekdolphm: no real concerns14:00
*** mvk has joined #openstack-keystone14:01
dolphmdstanek: hybrid property + expression basically just saving us from rewriting a bunch of existing code into managing explicit joins. i'm torn (that is, i don't have enough data either way) as to whether we should consider the use of hybrid properties to be tech debt or something valuable we should keep.14:01
*** petertr7_away is now known as petertr714:02
*** pcaruana has quit IRC14:02
*** ninag has joined #openstack-keystone14:03
dstanekdolphm: normally i would say that they should be removed because in my experience there will be a problem in the future since it's not obvious that a join will happen14:03
dolphmdstanek: i think we'll run into that too; or a non-optimal join of some sort14:03
dstanekdolphm: in this case we really hide the use of that model behind the driver interface and since that's in the same file it should be less problematic14:03
dancnoh, there is also an open keystone bug: https://bugs.launchpad.net/neutron/+bug/1541879 but the patch seems abandoned14:03
openstackLaunchpad bug 1541879 in neutron "Neutron devstack gate fails to install keystone due to fresh testtools" [Critical,Confirmed] - Assigned to Ihar Hrachyshka (ihar-hrachyshka)14:03
odyssey4medaemontool ok, my first suggestion is to take the rule out for the group mapping - just to simplify the mapping and eliminate one variable - let's get a single user working before adding complexity14:04
*** subscope has joined #openstack-keystone14:04
odyssey4medaemontool also, 'sso_admins' != 'sso-admins' and additionally I'm not sure that the rule will do a regex or whether it requires a full match... that'll be for later once you have a single user working14:05
raildohenrynash: ok, thanks :) I'll follow this suggestion to create a policy check for cascade14:05
dstanekdancn: any reason not to update your test dependencies?14:05
henrynashraildo: ok14:05
rodrigodsraildo, henrynash, this rule should be exclusive to domain admins, right?14:05
dolphmdancn: the patch https://review.openstack.org/#/c/276307/ looks to be abandoned because it's stable/kilo that broke, not master14:05
patchbotdolphm: patch 276307 - neutron - Cap version of testtools to fix gate (ABANDONED)14:05
*** spzala has joined #openstack-keystone14:05
dolphmdancn: the patch was to the wrong branch14:05
henrynashrodigods: I would imagine that this would be the default we would put in the policy file, yes14:06
raildorodrigods: makes sense14:06
dstanekodyssey4me: daemontool: i'm not sure how the environment vars are created from the saml, but the ony_one_of looks strange to me14:06
rodrigodshenrynash, raildo cool14:06
*** jasonsb has quit IRC14:06
odyssey4medstanek any_one_of is an option according to http://docs.openstack.org/developer/keystone/mapping_combinations.html#mapping-conditions unless I'm misunderstanding what you're saying (cc daemontool )14:07
marekdAnticimex: no issue14:08
daemontoolodyssey4me, looking...14:08
*** richm has joined #openstack-keystone14:08
marekdAnticimex: lxml didn't have an issue - there was a plan to get rig of it.14:08
marekdAnticimex: the python'x xml didn't work for me on my adfs instance.14:08
Anticimexmarekd: roger, thanks14:09
odyssey4medaemontool also note that in http://docs.openstack.org/developer/openstack-ansible/install-guide/configure-federation-mapping.html#identity-service-federation-attribute-mapping we set out a complete rule - a remote user which has a 'upn' (uid in your case) is mapped to a local user where we map out the name, group and domain group.14:09
dstanekodyssey4me: yes, exactly. i think what happens is we get an environment vars that we slip into a list and then any against that list.14:09
odyssey4medaemontool in your case a user and group are being mapped seperately, and I don't think that works14:10
daemontoolodyssey4me,  ok14:10
marekdAnticimex: willing to try that out?14:10
marekdAnticimex: have access to ADFS instances?14:10
Anticimexno, no ADFS14:10
AnticimexSAML214:10
marekdADFS is a product14:11
Anticimexyeah, i realized14:11
marekdActive Directory Federated Services14:11
Anticimexbut no, don't have it. using shibboleth14:11
marekdAnticimex: ok14:11
Anticimexsome of our customeres-to-be may have it though, so there is interest14:11
Anticimexbut not this week :]14:11
*** jaosorior has quit IRC14:11
marekdAnticimex: ok, current plugin works14:11
Anticimexcool14:11
*** jaosorior has joined #openstack-keystone14:12
marekdAnticimex: are you deploying federated access in production?14:13
Anticimexi'm trying to determine how much of head ache i will have based on our saml2 mapping, to use the old clients such as neutron14:13
Anticimexwe map federated users via an admin or members group to a project, per domain14:13
Anticimexlike a top level project14:13
Anticimexhorizon sort of works, but now trying to understand the python clients, as not all features are in openstackclient yet14:14
Anticimexmarekd: yeah, we met in tokyo if you may recall14:14
dancndolphm: thanks, I will try to apply it stable/kilo locally and maybe propose it14:14
dolphmdancn: are the stable/kilo gate jobs failing though?14:15
dolphmdancn: make sure all your code is up to date (devstack and everything else)14:15
dancndolphm: according to the bug report yes: The gate of stable/kilo is broken now like the following14:15
dancndolphm: I am pretty new to keystone development, I have only a keystone checkout, I guess this should be enough for my testing pourpose14:17
dolphmdancn: i'm worried the bug report got fixed without being closed; i'm looking for the gate job now14:19
daemontoolodyssey4me, another bit of information, from the keystone log, I see the following14:20
daemontoolDEBUG keystone.contrib.federation.utils [-] mapped_properties: {'group_ids': [], 'user': {'domain': {'id': 'Federated'}, 'type': 'ephemeral'}, 'group_names': []} process /usr/lib/python2.7/site-packages/keystone/contrib/federation/utils.py:48114:20
daemontool2016-02-23 15:18:03.219 2963 WARNING keystone.common.wsgi [-] Authorization failed. Unable to find valid groups while using mapping unica_map14:20
daemontoolbut that mapped properties are different from the ones we have14:20
daemontool:/14:20
odyssey4medaemontool yes, I think what's happening is that your user is being mapped, but the user mapping has no group in it14:21
odyssey4medaemontool as far as I know, the mapping is always first based on the user attribute... so your group mapping rule will never be hit14:21
odyssey4medaemontool I think it uses the first found rule, then ignores all subsequent rules14:22
daemontoolah ok14:22
daemontoolthat make sense14:22
dolphmdancn: well i found the job i was looking for, and have a failed log of it from 6 days ago (nothing more recent), but confused as to why there's no history in jenkins14:24
dolphmdancn: https://jenkins.openstack.org/job/periodic-keystone-python27-kilo/14:24
dolphmdancn: build logs (look at the date column) http://logs.openstack.org/periodic-stable/periodic-keystone-python27-kilo/14:25
openstackgerritMerged openstack/keystone: Shadow users - Separate user identities  https://review.openstack.org/27857014:25
dolphmdancn: latest build is successful http://logs.openstack.org/periodic-stable/periodic-keystone-python27-kilo/a993507/console.html14:26
*** esp has joined #openstack-keystone14:27
dancndolphm: thanks for investigating, also the cerry pick of the patch does not apply to stable/kiko14:28
dstanekstevemar: is there a list of the reseller stuff that we really want merged? the bp is listed for m3, but there are so many unmergable reviews associated with it14:29
dancndolphm: I will dobule check that my tox env was not created with the master branch14:29
*** links has quit IRC14:30
*** su_zhang has joined #openstack-keystone14:30
*** links has joined #openstack-keystone14:31
*** jsavak has joined #openstack-keystone14:31
dolphmdancn: that's also not the devstack job, but it's the one i remember failing recently14:31
*** esp has quit IRC14:32
dolphmdancn: tox --recreate will create fresh tox environments14:32
dancndolphm: unfortunately tox --recreate still fails, I noticed the cap chage Ife7b2f9894db9c9466ab4960549bbdee3bbe99bd in test-requiremenents.txt made by the bot, will investigate a bit more14:34
dancndolphm: I will try to compare the py27 installed output from the gate and mine14:38
*** jsavak has quit IRC14:44
*** jsavak has joined #openstack-keystone14:44
dolphmdancn: tox in keystone itself?14:45
dolphmdancn: can you paste your tox output?14:45
dancnthe diff are aioeventlet 0.4 vs 0.5.1 and wheel 0.24.0 cs 0.29.014:45
dolphmstevemar: bknudson: nkinder: what do we do about all these obvious & redundant security vulnerability reports that forever trickle in? they're getting sillier and sillier14:45
dancndolphm: yes tox in keystone itself, will paste in few sec!14:46
*** ayoung has quit IRC14:46
bknudsondolphm: I don't have a solution. It's good that we're only getting silly vulnerability reports.14:46
bknudsondolphm: maybe some docs that we can point to? That would probably be more work.14:47
bknudson(more work than making a comment on the bug report)14:47
dolphmbknudson: i feel like we need to spend a summit session producing a security page in our docs that outlines our well known weaknesses and recommendations against them14:47
dolphmbknudson: and cite external specs / discussions / etc from there14:48
dolphmsort of a state-of-the-union14:48
marekdAnticimex: yeah, i do remember now :-)14:48
bknudsondolphm: That would help. At least we'd have something to point to. Can't expect security scanners that just push a button to read the docs, though.14:48
dolphmdancn: i'm running tox -e py27 on stable/kilo now -- i assume that's how you're seeing a failure?14:49
*** mylu has joined #openstack-keystone14:49
stevemardolphm: i was thinking about that same topic recently in the latest bug triage14:49
dolphmbknudson: no, but it gives us one place to link to immediately close reports without any further undue process14:49
*** shoutm has quit IRC14:49
bknudsondolphm: y, since they're already publically disclosed it's easy to close security bugs.14:50
dolphmstevemar: is a summit session appropriate? i bet we could have a productive brain dump of tribal knowledge really quickly14:50
dolphmand then go from tribal knowledge to citations14:50
dolphmin code review14:50
dancndolphm: yes tox -e py27 on stable/kilo!14:51
stevemardstanek: i thought i cleaned that up14:51
stevemardstanek: this should be the only patch for reseller left: https://review.openstack.org/#/c/231289/5414:52
patchbotstevemar: patch 231289 - keystone - Projects acting as domains14:52
*** ninag has quit IRC14:52
dstanekstevemar: maybe i went to the bp and went to the last topic that was posted14:52
stevemardstanek: or as it's been called -- reseller part 114:52
dolphmdancn: is this what you're seeing? http://cdn.pasteraw.com/lmvqwv78a8s96ur87a1lnvueurtj9qb14:52
dancndolphm: here is my output: http://paste.openstack.org/show/487898/14:52
*** ninag has joined #openstack-keystone14:52
dstanekstevemar: https://review.openstack.org/#/q/topic:bp/reseller+is:open14:52
stevemardstanek: for https://blueprints.launchpad.net/keystone/+spec/reseller i put a little (merged) or (abandoned) next to each one that was closed14:53
*** mylu has quit IRC14:53
dancndolphm: yes the error is the same14:53
*** ninag has quit IRC14:53
*** ninag has joined #openstack-keystone14:53
*** slberger has joined #openstack-keystone14:53
dstanekstevemar: ok, so my link is correct. just a few unmergable things14:54
*** dims has joined #openstack-keystone14:54
*** sdake has joined #openstack-keystone14:55
stevemardstanek: yeah, but apparently those are not necessary for mitaka, according to the guys working on it :)14:55
stevemarjust that last one i linked is needed14:55
stevemardolphm: i'd be okay with a list of known vulnerabilities page on keystone docs14:55
stevemar"things we won't fix"14:55
*** mylu has joined #openstack-keystone14:56
dolphmstevemar: not necessarily things we won't fix, but things we're well aware of that you don't need to report14:56
tristanCor why not pointing at OpenStack Security Notes (ossn) for known issues ?14:56
dolphmthere's a pile of specs asking for things like account lockout after repeated failed login attempts, for example. it'd give us a place to cite them all14:57
stevemardolphm: yeah, thats worded more nicely14:57
dolphmtristanC: ++14:57
dolphmtristanC: that's a good place to start14:57
stevemardolphm: there are these bugs i found to be security related: https://bugs.launchpad.net/keystone/+bugs?field.tag=security14:57
stevemarwhy is "sample policies" tagged with security14:58
dstanekstevemar: the 'projects acting as domains' one?14:58
stevemardstanek: yes14:58
stevemardolphm: you tagged "sample policies" as security related :P14:58
dolphmstevemar: improves flexibility of RBAC?14:58
stevemari guess, but that's more policy related14:59
dstanekhtruta: are you working on an update for that? ^14:59
stevemar*points to the bikeshed*14:59
*** GB21 has joined #openstack-keystone15:00
stevemardolphm: i'm finally checking my email for the first time today, now i know why you brought up this topic :]15:00
dolphmstevemar: yeah... it's becoming a pet peeve15:01
*** sigmavirus24_awa is now known as sigmavirus2415:01
*** jsavak has quit IRC15:01
dancndolphm: isn't strange that py27 installed list: testtools==2.0.0 when in test-requirements.txt we have testtools!=1.2.0,<2.0.0,>=0.9.36 ? Any hint?15:03
dstanekdancn: that was installed in your .tox/py27 venv?15:04
*** tomoiaga1 has joined #openstack-keystone15:05
dancndstanek: yes15:05
*** jsavak has joined #openstack-keystone15:05
*** dave-mcc_ has joined #openstack-keystone15:05
stevemardhellmann: think it's a good idea to bump the minimum version of cliff to the latest release?15:05
*** ninag_ has joined #openstack-keystone15:05
dancndstanek: here is the full output: http://paste.openstack.org/show/487898/15:06
stevemardhellmann: since there was the `out of range` bug that was fixed15:06
dstanekdancn: what branch are you using?15:07
*** ekarlso- has joined #openstack-keystone15:07
dancndstanek: fresh checkout of stable/kilo15:07
*** links has quit IRC15:07
*** tomoiaga has quit IRC15:07
*** fhubik_brb has quit IRC15:07
*** ekarlso has quit IRC15:07
*** ninag has quit IRC15:07
*** GB21 has quit IRC15:07
*** dave-mccowan has quit IRC15:08
*** subscope has quit IRC15:11
openstackgerritRon De Rose proposed openstack/keystone: Shadow users - Shadow federated users  https://review.openstack.org/27916215:12
dolphmdstanek: i reproduced it as well15:13
dancndolphm, dstanek I do not know how to do a pip dependency analisys, but doing in a fresh venv pip install -r requirements.txt leads to a venv with testtools==2.0.015:14
dstanekdolphm: strange. i just did a "git co gerrit/stable/kilo" and tox -epy27 is currently running tests15:14
dancnpip -r req*.txt test-req*.txt find the conflict too late15:15
dolphmdstanek: hmm15:15
dolphmdstanek: with tox -r ?15:15
dstaneki completely deleted my .tox directory15:15
*** shoutm has joined #openstack-keystone15:16
dstanekhmmm...i did get testtools 2.0.0, but not conflict15:17
*** pcaruana has joined #openstack-keystone15:18
dstanekdolphm: dancn: the test-requirements.txt doesn't constrain to <2.0.015:19
dstanekdolphm: dancn: http://paste.openstack.org/show/487905/15:19
dstanekdolphm: dancn: c4dc133 is the sha that i am using15:20
*** pcaruana has quit IRC15:20
*** pcaruana has joined #openstack-keystone15:21
stevemardolphm: ohhhh dayummmm shadow merged15:21
*** pcaruana|afk| has joined #openstack-keystone15:21
dancndstanek: I have this line in test-requirements.txt testtools!=1.2.0,<2.0.0,>=0.9.36, do you mean that it does not work?15:21
dancn15:21
*** knikolla has joined #openstack-keystone15:22
dstanekdolphm: i have a different value15:23
dstanekdancn: ^15:23
dstanekdancn: what does 'git rev-parse HEAD' show?15:23
dancndstanek: 47102e53aaa8c8cde1067cb900a20542a23268be15:23
*** tomoiaga1 has quit IRC15:24
dstanekdancn: very odd15:25
*** petertr7 is now known as petertr7_away15:27
dstanekdancn: how did you do the checkout and is your git up-to-date? i just confirmed that i was using the correct sha http://git.openstack.org/cgit/openstack/keystone/log/?h=stable/kilo15:27
*** timcline has quit IRC15:27
*** pcaruana|afk| has quit IRC15:29
openstackgerritBrant Knudson proposed openstack/keystone: Test for UWSGI (DO NOT MERGE EVER)  https://review.openstack.org/28363515:31
dancnIIRC git clone and then git branch stable/kilo15:31
dancndstanek: ^^^15:31
dstanekdancn: which repo did you clone? i want to reproduce15:32
dancndstanek: originhttps://git.openstack.org/openstack/keystone15:32
morganbknudson: +2/+A >.>15:32
bknudsonmorgan: now I know how to get reviews15:33
*** jorge_munoz has joined #openstack-keystone15:33
morganbknudson: haha15:33
bknudsonI'll make them like trolling headlines15:33
morganexactly15:34
bknudsonObama doesn't want you to see this15:34
morganhahaha15:34
*** martinus___ has quit IRC15:34
dstanekdancn: i get a different sha for the origin/stable/kilo branch. did you create a local stable/kilo?15:34
dancndstanek, ah, well, now I remember better, then I tried to apply the patch referenced at: https://bugs.launchpad.net/neutron/+bug/1541879 using cherry pich15:36
openstackLaunchpad bug 1541879 in neutron "Neutron devstack gate fails to install keystone due to fresh testtools" [Critical,Confirmed] - Assigned to Ihar Hrachyshka (ihar-hrachyshka)15:36
*** pcaruana has quit IRC15:37
dancndstanek: it failed and I did git reset --hard (I guess)15:37
dancndstanek: by the way, I just tested in a fresh venv pip install -r requirements.txt -r test-requirements.txt and it uses pip freeze shows: testtools==1.9.015:38
dstanekdancn: cool, i'm glad you have the issue resolved15:39
*** timcline has joined #openstack-keystone15:41
*** porunov has quit IRC15:41
dancndstanek: well, it is not yet resolved... I am just trying to find why tox install testools=2.0.0 and pip alone seems to to the right thing.  But tox, not yet!15:41
*** petertr7_away is now known as petertr715:41
dstanekdancn: i thought you were saying that when you updated to the right branch that it worked15:42
*** daemontool_ has joined #openstack-keystone15:44
dstanekdancn: have you gotten the correct branch yet?15:44
dancndstanek: it worked for pip install -r, but I do not know why 'py27 installdeps' of tox install leads to a different result.  I guess that tox does not call pip install but resove the dependencies in another way?15:44
stevemarbknudson: click bait review titles15:44
htrutadstanek: not at this exact moment. But I'll rebase them now15:45
*** jaugustine has joined #openstack-keystone15:45
dancndstanek: to avoid confusion please give me the exact command you want me to do for getting the stable/kilo! thanks15:46
dstanekdancn: 'git co origin/stable/kilo'15:46
*** daemontool has quit IRC15:46
openstackgerrithenry-nash proposed openstack/keystone: Projects acting as domains  https://review.openstack.org/23128915:47
dancndstanek: ok, turned out to be a no-op: git reflog15:48
dancn47102e5 HEAD@{0}: checkout: moving from stable/kilo to origin/stable/kilo15:48
dancn47102e5 HEAD@{1}: checkout: moving from master to stable/kilo15:48
dancn15:48
dstanekdancn: 47102e5 is the correct sha15:48
dstanekdancn: i'm also using tox 2.1.1 on the machine that works15:49
*** pcaruana has joined #openstack-keystone15:49
dstanekdancn: then i just 'rm -rf .tox' and 'tox -e py27 --notest'15:49
dancndstanek: running...15:50
dancngot:   congratulations :)15:51
dancndstanek: ^^^15:51
dancndstanek:  but if I do only tox -e py27 I will see the original error: pkg_resources.ContextualVersionConflict: (fixtures 1.2.0 ...15:52
dstanekdancn: i don't see that. my tests just start running15:53
dolphmstevemar: bknudson: "Fixed bug with this one weird patch"15:53
dancndstanek: dolphm was also able to reproduce: http://cdn.pasteraw.com/lmvqwv78a8s96ur87a1lnvueurtj9qb few mins ago...15:54
stevemardolphm: https://twitter.com/stevebot/status/70215832780401049615:54
dancndstanek: I think the problem lies in the package dependecy resolution, but I to not know pip and tox enough to investigate it further15:56
dstanekdancn: if the --notest worked, i don't know how it would not work without that option15:57
*** pushkaru has joined #openstack-keystone15:57
*** gokrokve has joined #openstack-keystone15:58
*** vinm213 has joined #openstack-keystone15:58
*** petertr7 is now known as petertr7_away15:58
*** phalmos has joined #openstack-keystone16:01
bknudsonwhy is "one" a trigger? I haven't figured that out.16:02
bknudsonhttps://xkcd.com/1283/16:04
*** wanghua has joined #openstack-keystone16:04
*** mvk has quit IRC16:05
*** mvk has joined #openstack-keystone16:06
*** shoutm has quit IRC16:07
*** tobasco has quit IRC16:09
*** EinstCrazy has quit IRC16:13
*** jsavak has quit IRC16:13
*** subscope has joined #openstack-keystone16:14
*** jsavak has joined #openstack-keystone16:14
*** phalmos has quit IRC16:16
*** mylu has quit IRC16:19
*** mylu has joined #openstack-keystone16:20
*** clenimar has joined #openstack-keystone16:20
*** rderose has joined #openstack-keystone16:22
dancndstanek: could you show me the output of “.tox/py27/bin/pip freeze | egrep 'testtools|fixtures'”  in your checkout?  I see: fixtures==1.2.016:23
dancntesttools==2.0.016:23
dancnThanks in advance!16:23
dancn16:23
dstanekdancn: i have the same16:25
*** subscope has quit IRC16:27
*** petertr7_away is now known as petertr716:27
*** belmoreira has quit IRC16:27
dancndstanek: thanks, I was speculating that you may have had an older version of testtools because of some cache (it seems that the only available version is 2.0.0 on pypi, but this is not the case...16:27
dancnand to be fair pip is able to install 1.9.0 version using a cache: [...] Using cached testtools-1.9.0-py2.py3-none-any.whl but tox not...16:29
*** dims has quit IRC16:37
*** gokrokve has quit IRC16:39
*** shoutm has joined #openstack-keystone16:40
stevemardolphm: dstanek https://review.openstack.org/#/c/283325/ all-ibm patch16:44
patchbotstevemar: patch 283325 - keystone - Fix project-related forbidden response messages16:44
*** GB21 has joined #openstack-keystone16:44
*** subscope has joined #openstack-keystone16:45
*** su_zhang has quit IRC16:46
*** su_zhang has joined #openstack-keystone16:46
*** spandhe has joined #openstack-keystone16:48
*** bdossant has quit IRC16:49
*** jsavak has quit IRC16:49
*** su_zhang has quit IRC16:50
*** jistr has quit IRC16:51
*** jsavak has joined #openstack-keystone16:51
*** mylu has quit IRC16:54
dancndstanek, dolphm thanks for you help, I do not found the problem and the solution but I found a way to identify them!  If I move the testtools requirements line to the top of requirements.txt tox works... so now I have to bisect the first correct position of testtools...  do you think that this is worth doing it?  I already started16:56
*** mylu has joined #openstack-keystone16:58
dolphmdancn: strange, it must be one of our dependencies expecting a newer version of testtools?16:59
*** jsavak has quit IRC16:59
dolphmdancn: IIRC, the gate is capable of keeping such breaking requirements out of the gate's pypi mirrors, even if they're available in pypi16:59
*** bjornar_ has joined #openstack-keystone16:59
dolphmdancn: i've never had to deal with that behavior myself16:59
bjornar_I read httpd/keystone.py is deprecated as of Mitaka in favor of keystone-wsgi-admin and keystone-wsgi-public and may be removed in O .. where is keystone-wsgi-* located and why removed?17:00
*** jsavak has joined #openstack-keystone17:00
dolphmbjornar_: it's an entrypoint defined by setup.cfg17:00
dolphmbjornar: they're just arbitrary deployment files that can either be included in keystone itself (and easier to discovery via entry points), or you can write your own if you want to customize it; moving them to entry points prevents us from breaking deployers when we mess with them in the future (which we've done before)17:02
bjornar_dolphm, ok. Another question. I am trying to run keystone with just the keystone-paste.ini file, and it seems something is trying to load /etc/keystone/keystone.conf .. but I get some complaints:17:03
dolphmbjornar: keystone will read it's configuration file regardless of whether or not you deploy it with paste17:04
bjornar_no such option in group DEFAULT: trust17:05
*** dan_nguyen has joined #openstack-keystone17:07
*** gokrokve has joined #openstack-keystone17:07
*** dims has joined #openstack-keystone17:09
bjornar_dolphm, any idea?17:09
dolphmbjornar_: do you have a configuration option named "trust" defined in your keystone.conf ?17:09
dancndstanek, dolphm: well, really strange, in order to make tox run fine, the testtools line should be in requirements.txt (position independent), if I put in test-requirements.txt, even at first line, I have a failure!  I do not have an explanation by I think I will open a bug.17:10
stevemarbjornar_: specifically in the DEFAULT section?17:10
stevemarbjornar_: what version of openstack are you using?17:10
bjornar_its master..17:10
bjornar_uwsgi --venv /usr/src/venv_keystone/ --ini-paste keystone-paste.ini --paste-name main -s tmp17:11
bjornar_dolphm, not a option, but a section17:11
*** phalmos has joined #openstack-keystone17:11
*** browne has joined #openstack-keystone17:12
samueldmqhenrynash: hi!17:13
*** csoukup has joined #openstack-keystone17:13
henrynashsamueldmq: hi17:13
samueldmqhenrynash: so looks like we share the same view on 24358517:13
samueldmqchange 24358517:13
samueldmqbot please ? change #24358517:13
*** shoutm has quit IRC17:14
morgansamueldmq: patch 24358517:14
patchbotmorgan: https://review.openstack.org/#/c/243585/ - keystone - API support for project cascade update17:14
samueldmqarrgh, okay https://review.openstack.org/#/c/243585/ henrynash17:14
patchbotsamueldmq: patch 243585 - keystone - API support for project cascade update17:14
samueldmqmorgan: ooookay17:14
samueldmq:)17:14
henrynashsamuedlmq: oj17:14
henrynashok, even17:15
samueldmqhenrynash: so, as I see it: if we want to enforce policy for each project, do it by getting a "fake" token for those projs17:15
samueldmqhenrynash: at least for doing the enforce thing, so it's the same as you were getting a token on each subproject17:15
*** diazjf has joined #openstack-keystone17:15
bjornar_dolphm, any idea here?17:15
henrynashsamuedlmq: yes…and that feels a bit scary17:16
henrynashsamuedlmq: we’ve certainly never done that before17:16
dolphmbjornar_: it sounds like there's a mismatch between what's in your keystone.conf and what keystone is expecting - can't comment further without seeing your keystone.conf17:16
*** mylu has quit IRC17:16
*** gyee has joined #openstack-keystone17:16
*** ChanServ sets mode: +v gyee17:16
morganbjornar_: i am guessing [trust] lost it's '[' and ']' in the config?17:17
samueldmqhenrynash: basically if  https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L7417:17
bjornar_dolphm, its not about keystone.conf I think, since its ok when running with keystone-all17:17
morganbut what dolphm said. seeing the config will help (please strip passwords)17:17
samueldmqhenrynash: _build_policy_check_credentials could get a user an a project and build the credentials from there (aside from the token_id as it does today)17:17
henrynashsamueldmq: yep, you need to recreate that for each project you are cgecking17:17
samueldmqhenrynash: we should be fine17:18
morganor it's how uwsgi processes something?17:18
samueldmqhenrynash: exactly, I will give it a try17:18
samueldmqhenrynash: looks like we're on the same page17:18
bjornar_morgan, I think it is not a config issue, since the same config is fine with keystone-all .. but it might be something with uwsgi or I dont really know, perhaps you know where this error could come from?17:18
morganbjornar_: is trust the first section in your config file?17:19
morganand you're not passing --config-file or whatever to the cli, right?17:19
bjornar_morgan, no, [DEFAULT] is the first..17:19
morgansorry, after [DEFAULT]17:19
* morgan assumed default was first.17:19
bjornar_now it is.. no change17:20
henrynashsamueldmq: what if the domain admin wnats to restrict cacaded operations to  a specist role?17:20
bjornar_and not passing any option, only "uwsgi --venv /usr/src/venv_keystone/ --ini-paste keystone-paste.ini --paste-name main -s tmp"17:20
henrynashsamuedlmq: I think we still need to preserve that option……somehow…so if we make it just like a regualr update, I;m not sure how they would do that…17:21
morganbjornar_: sec. looking at something17:21
samueldmqhenrynash: hm yes, that makes snse too, I guess it depends on how we see that operation17:22
*** daemontool_ has quit IRC17:22
samueldmqhenrynash: from authz perspective, if we see it as a shortcut to a bunch of update calls, the proposed way makes sense17:22
samueldmqhenrynash: if we see it as a new operation, maybe a new policy entry17:23
samueldmqhenrynash: but if we do a new policy entry, how do we check one has authz on all the projects ?17:23
morganbjornar_: and youre paste-ini has a uwsgi section?17:23
morganbjornar_: iirc --ini-paste needs a uwsgi section17:23
samueldmqhenrynash: we'd be at the other side of the issue17:23
henrynashsamueldmq: I agree with your classification….and if we see it as the 2nd type, then you don’t worry about the roles on each project17:24
morganoh i see you're doing --paste-name17:24
morgannvm17:24
bjornar_morgan, I dont know, does it?17:24
morganwhich doesn't seem to be a uwsgi option17:24
morganaccording to the uwsgi docs, yes17:24
samueldmqhenrynash: in the first approach, we can also do that by combining the provided ?cascade (appears as a filter in the policy check?)17:24
henrynashsamuedlmq: if we can do the 1st way, then that’s interesting….if we find peopel compaining that they really want a sepaate policy control, we can do that17:24
morgani don't think you actually want uwsgi to manage the paste-ini for you, i think you want it to just run the wsgi file17:25
bjornar_seems atleast  self.group is None in NoSuchOptError17:25
morganand let keystone manage the paste-ini17:25
samueldmqhenrynash: makes sense to me17:25
morganwhcih is why config options aren't registered properly in all cases17:25
*** josecastroleon has quit IRC17:25
samueldmqhenrynash: thinking further, may that apply to inherited assignments too ?17:25
morganyou need to use the keystone wsgi entry point, as it does a lot of setup17:25
henrynashsamieldmq: if you were (in the 1st case) to but ‘cascade=True” into teh taget dict you pass the policy engine, then peopel coudl refernce it in the rule (and, fot instance, ban the use of tree opreations if they wanted)17:26
morganand will consume the paste-ini in /etc/keystone (by default)17:26
samueldmqhenrynash: like: someone in a parent has no access to me, but he can assign a role to me!17:26
bjornar_morgan, ok, so I could do that in the keystone-paste.ini ?17:26
samueldmqhenrynash: yes17:26
morganok so, you just need to use something like: (sec)17:27
henrynashsamueldmq: or, more likely, perhaps require some higher powered role to do cascades…17:27
*** mylu has joined #openstack-keystone17:27
*** sdake_ has joined #openstack-keystone17:28
samueldmqhenrynash: yes, so the higher powered role to do cascades17:28
morganuwsgi --venv /usr/src/venv_keystone/ --py <path to the keystone wsgi entry script> -s tmp17:28
samueldmqhenrynash: this is what we do for grating inherited role assignments17:28
samueldmqhenrynash: because we don't check that use can assign roles in every project in the subtreee17:28
morgani think17:28
morganchecking docs17:28
*** ayoung has joined #openstack-keystone17:29
*** ChanServ sets mode: +v ayoung17:29
henrynashsamueldmq: for granting, no, we don;t check that….and not sure we wour want to17:29
bjornar_morgan, but do I need the entry script actually? could it not be done in the paste?17:29
*** phalmos has quit IRC17:30
henrynashsamueldmq: or we create a chicken and egg problem for big hierarchies17:30
samueldmqhenrynash: would make sense not requiring that for grant and DO require that for cascade ops ?17:30
*** sdake has quit IRC17:30
morganbjornar_: i wouldn't try it in the paste17:30
morgan bjornar_ well it might be doable, but honestly, never tried loading that much data into the paste17:31
henrynashsamueldmq: so there is a difference between inherited and cascade…..inherited allie to new projects created AFTER you make teh assignment call, while cascade only operates on existing projects17:31
morganbjornar_: soo.. no idea what issues you're going to run into17:31
morganit might be --wsgi-file not --py btw17:31
samueldmqhenrynash: maybe it does, so starting to check permission on every node is more restrictive17:31
morgani'd need to go look at devstack to see what devstack supports/does17:31
samueldmqhenrynash: so we start more restrictive and loosen it later if asked17:31
samueldmqhenrynash: hmm, and that doesn't make sense to inherited roles anyway, because those roles apply to future projects too, so that would likely endup too complex17:32
morganbjornar_: you likely would need to replicate the stuff done in the wsgi entry script in your paste-ini somehow, and add a uwsgi section somehow17:32
*** sdake_ is now known as sdake17:33
henrynashsamuedlmq: for cascade, probably right17:33
morganbjornar_: like i said, i have not spent any time on doing that kind of stuff17:33
*** subscope has quit IRC17:33
samueldmqhenrynash: yes, and for role assingments, leave it as it is :)17:33
bjornar_morgan, dont think I need any uwsgi section actually.. just need that the entrypoint does the required setup17:33
henrynashsamueldmq: …and if you pass the project entity AND teh cascade option into target dict, I can see how to write a prolicy rule that is strict or relaxed17:33
morganbjornar_: if you are using paste-ini under uwsgi like that with the --ini-paste option, i think you do need it.17:34
morgani think17:34
samueldmqhenrynash: I am not sure17:34
*** mylu has quit IRC17:34
morganagain, i haven't spent much time on this17:34
samueldmqhenrynash: because the logic of iterating over all subnodes and checking policy is in the code17:34
henrynashsamuedlmq: eg. you could write cascade(True) and domain_id(proejct.domainid) and role:x17:34
samueldmqhenrynash: so not sure it can be more relaxed17:34
samueldmqhenrynash: hm yes and that will be true for all projects, since they have the same parent17:35
henrynashsamuedlmq: which would mean use a domain scoped token with role X to issue cascade ops17:35
samueldmqsame domain17:35
samueldmqhenrynash: ++17:35
*** therve has joined #openstack-keystone17:36
therveHi!17:36
samueldmqhenrynash: btw, I submitted another patch to expose this bug in the current impl17:36
samueldmqhenrynash: https://review.openstack.org/#/c/28316817:36
samueldmqtherve: hey17:36
therveLooks like we have a recent failure in Heat integration tests due to a recent merge17:36
therveIt fails with "Column 'password' cannot be null"17:36
*** GB21 has quit IRC17:37
thervePresumably because of https://review.openstack.org/#/c/278570/17:37
patchbottherve: patch 278570 - keystone - Shadow users - Separate user identities (MERGED)17:37
bjornar_morgan, So I got it to work atleast with the keystone.py example file, but that is depricated.. how am I supposed to initialize it, what do you recommend?17:37
morganbjornar_: there is a file automatically ceated via pbr17:37
therverderose, ^^^17:37
morganbjornar_: that replaces the keysotne.py file17:37
rderosetherve: yes17:38
rderosewhat's up17:38
samueldmqayoung: dstanek: dolphm: you guys may have some insight related to therve's issue on heat integration ^17:38
samueldmqrderose: ^ you too :)17:38
therverderose, http://logs.openstack.org/97/283297/1/check/gate-heat-dsvm-functional-orig-mysql-lbaasv1/5c446f1/logs/apache/keystone.txt.gz?level=ERROR17:38
morganbjornar_: https://github.com/openstack/keystone/blob/master/setup.cfg#L75-L7617:38
*** su_zhang has joined #openstack-keystone17:38
*** mylu has joined #openstack-keystone17:38
morganbjornar_: will be installed in the same place as keystone-all i think17:38
ayoungYep...looks like it17:38
therveLooks like the enforcement to non-NULL breaks compatibility17:38
ayounglet's revert it for now, and try again17:39
henrynashsamueldmq, ayoung: time, I think, t get https://review.openstack.org/#/c/231289/ in17:39
patchbothenrynash: patch 231289 - keystone - Projects acting as domains17:39
dstanektherve: so you were creating users with no passwords?17:39
morganwe need to make the default something like !*! or similar to a shadow file17:39
morganayoung: ^17:39
thervedstanek, I think so yes, let me check17:39
morganayoung: if a user has no password17:39
ayoungmorgan, ++17:39
samueldmqhenrynash: yes,  I will take a look at that too17:39
bjornar_morgan, but the scripts have not been written yet?17:39
ayoungsomething wonky with my IRC client...back in a flash17:39
samueldmqhenrynash: that and cascade things are on my top priority for this week17:39
*** ayoung has quit IRC17:39
morganmight be as much/less work than a revert17:39
morganbjornar_: those are written when you install keystone17:40
henrynashsamueldmq: great17:40
*** ayoung has joined #openstack-keystone17:40
*** ChanServ sets mode: +v ayoung17:40
morganayoung: might be as much/less work than revert17:40
samueldmqmorgan: hm, like storing a fake null value, as we did for domain roles17:40
dolphmsamueldmq: rderose: it shouldn't be creating a password row at all, if there's no password. the password being non-nullable is not the issue17:40
morgansamueldmq: more like an /etc/shadow for a disabled user17:40
ayoungmorgan, yep17:41
dolphmsamueldmq: ... a fake null value?17:41
dolphmwhat on earth does that mean17:41
ayounglet me look at that review again..not sure how it passed CI17:41
rderosedolphm: correct17:41
samueldmqdolphm: a special null value should explain better17:41
morgandolphm: sounds like some odd issues.17:41
morgansamueldmq: no, i'm wrong.17:41
morganou shouldn't need a password entry17:41
dolphmsamueldmq: not really - what does that mean exactly?17:41
morgansomething is trying to create one with a null value17:41
samueldmqdolphm: like <<<keystone.null.domain>>>17:41
morgansamueldmq: not needed17:42
dolphmsamueldmq: can you link me to this tragedy?17:42
samueldmqdolphm: but that in the case what morgan said was correct17:42
bjornar_morgan, ok.. not when I build a wheel ..17:42
morganbjornar_: it might be somewhere else17:42
morgani don't know.17:42
samueldmqdolphm: example https://review.openstack.org/#/c/264533/28/keystone/common/sql/migrate_repo/versions/089_add_root_of_all_domains.py17:42
patchbotsamueldmq: patch 264533 - keystone - Allow project domain_id to be nullable at the mana... (MERGED)17:42
samueldmqdolphm: NULL_DOMAIN_ID = '<<keystone.domain.root>>'17:43
morganbjornar_: it should be created with a wheel, i just don't know where it goes17:43
morgansamueldmq: like i said, not needed for password17:43
bjornar_morgan, its nowhere in my venv17:43
ayoungnah, there should not be a row in the user table with a password field if there is no password...17:43
morgansamueldmq: that was a very specific case.17:43
thervedstanek, Actually, we don't, we disable an existing user17:43
samueldmqmorgan: yep, just passing the links to dolphm17:43
dstanektherve: and that removes the password?17:43
samueldmqmorgan: dolphm: and yes, that was for concurrency things17:43
samueldmqsame as henrynash did for domain roles17:43
thervedstanek, That ought to be something on keystone side17:44
morgandolphm: that was needed because NULL isn't part of a unique constraint in mysql17:44
ayoungI am going to guess that everytime we create a user, we are going to trigger a password creation the way that patch works17:44
samueldmqmorgan: ++17:44
ayounghttps://review.openstack.org/#/c/278570/39/keystone/identity/backends/sql.py  line 71217:44
patchbotayoung: patch 278570 - keystone - Shadow users - Separate user identities (MERGED)17:44
ayoung7117:44
morganayoung: yeah likey need to not create a password record if password is null17:44
rderoseayoung it shouldn't17:44
morganayoung: even esaier if that is a minor logic issue17:45
ayoungrderose, I think only create if Password != None17:45
*** jorge_munoz has quit IRC17:45
dolphmmorgan: that's pretty awful17:45
dstanekayoung: i think you are right17:46
morgandolphm: so if we want unique constraints on a column, NULL is not considered, therefore you can have unlimited numbers of duplication on the non-null column17:46
rderoseayoung dstanek that would fix it or don't set password to None :)17:46
morgandolphm: and it's a known behavior mysql supports17:46
ayoungrderose, I bet it is marshalling code doing it, not human effort17:46
dstanekrderose: if setting to a Falsy value delete the password?17:46
*** petertr7 is now known as petertr7_away17:47
ayoungrderose, 1: write a test17:47
ayoungtest should fail17:47
ayoung2:  Write a check in there that shows test now passes.17:47
ayoungReady, set, GO!17:47
samueldmqmorgan: dolphm: yes, "is that since the uniqueness constraint contains a nullable value, we actually store a special value (as opposed to None) in the sql attribute so as to still use the sql uniqueness constraint to ensure we do not have race conditions in multi-process keystone configurations."17:48
samueldmqfrom https://review.openstack.org/#/c/261870/17:48
patchbotsamueldmq: patch 261870 - keystone - Add CRUD support for domain specific roles (MERGED)17:48
dstanekayoung: rderose: two tests at least. creating with a Falsy password and updating the password to a Falsy value17:48
dolphmsamueldmq: morgan: i understand the problem; still don't like the solution17:49
bjornar_morgan, it is true that those are nowhere to be found in the whl17:49
morganbjornar_: it's a pbr thing, it's created like a console script17:49
samueldmqdolphm: we can easily fix it if we find a better solution, since the special value is hidden and not even visible at manager level17:49
morganif it isn't being created, it might be a PBR bug17:49
rderoseayoung dstanek should I just create small patch for this?17:50
henrynashstevemar: you up for an osc question?17:50
dstanekrderose: yep17:51
ayoungrderose, yes17:51
henrynash(or anyone else who knows osc well?)17:51
dolphmsamueldmq: like undoing the merge of tables back to a model that accurately modeled the domain<-project relationship?17:51
morgandolphm: not really different than the default domain, but we never leak this thing to the outside17:51
dstanektherve: did you make a bug for this?17:51
* morgan shrugs17:51
morgani think the default domain is a trainwreck as well.17:51
dolphmexcept the default domain is not magic17:52
morganbut eh.17:52
morgandolphm: i disagree, it is a lot of magic17:52
morgandolphm: this is likewise about the same, it's a real record in the db same as the default domain.17:52
dolphmand this was just described as "a special null value"17:52
morganit just is never leaked outside of the driver17:53
dolphmyet17:53
morganso, it's an implementation detail in the driver.17:53
dolphmin the data*17:53
morganat this point undoing the is_domain stuff is a ton of work, but would net the same thing.17:54
morgani'd support that too.17:54
* morgan really doesn't have a horse in this race.17:54
*** mvk has quit IRC17:56
*** su_zhang has quit IRC17:58
*** su_zhang has joined #openstack-keystone17:58
bretonmeeting17:59
stevemarkeystone meeting time17:59
*** lhcheng has joined #openstack-keystone17:59
*** ChanServ sets mode: +v lhcheng17:59
*** pushkaru has quit IRC18:02
*** pushkaru has joined #openstack-keystone18:03
*** jsavak has quit IRC18:06
*** jsavak has joined #openstack-keystone18:07
*** pushkaru has quit IRC18:09
*** gokrokve has quit IRC18:09
*** mylu has quit IRC18:09
*** wanghua has quit IRC18:14
*** vgridnev has joined #openstack-keystone18:19
*** spzala has quit IRC18:20
*** haneef has quit IRC18:25
*** su_zhang has quit IRC18:30
*** su_zhang has joined #openstack-keystone18:30
*** mylu has joined #openstack-keystone18:31
*** jsavak has quit IRC18:31
*** su_zhang has quit IRC18:31
*** su_zhang has joined #openstack-keystone18:32
*** phalmos has joined #openstack-keystone18:32
*** mylu has quit IRC18:33
*** rk4n has quit IRC18:35
*** jsavak has joined #openstack-keystone18:35
*** mylu has joined #openstack-keystone18:36
*** vgridnev has quit IRC18:37
*** vgridnev has joined #openstack-keystone18:38
*** vinm213 has quit IRC18:41
*** mylu has quit IRC18:47
*** dave-mcc_ is now known as dave-mccowan18:52
*** jsavak has quit IRC18:55
*** jsavak has joined #openstack-keystone18:56
*** ninag_ has quit IRC18:56
*** ninag has joined #openstack-keystone18:56
*** subscope has joined #openstack-keystone18:56
*** spzala has joined #openstack-keystone18:58
openstackgerritRon De Rose proposed openstack/keystone: Fixes a bug when setting a user's password to null  https://review.openstack.org/28374618:58
*** jaosorior has quit IRC18:59
dstanekbreton: lol, ok18:59
gyeedstanek, you have a personal story to tell with regarding to 'mixin'? :D18:59
ayoungrderose, on https://review.openstack.org/#/c/283746/1/keystone/tests/unit/test_backend_sql.py  did you run the test first and ssee it fail, prior to writing the code?18:59
patchbotayoung: patch 283746 - keystone - Fixes a bug when setting a user's password to null18:59
rderoseayoung: of course :)19:00
rderoseayoung yes19:00
*** spzala has quit IRC19:00
*** jsavak has quit IRC19:00
*** jsavak has joined #openstack-keystone19:01
*** spzala has joined #openstack-keystone19:01
ayoungrderose, cool looking now19:01
*** ninag has quit IRC19:02
ayoungrderose, why this logic instead of just skipping: self.local_user and self.local_user.passwords:19:02
ayoung                self.local_user.passwords = []19:02
rderoseayoung, if local_user is null, then can't reference local_user.passwords19:03
ayoungrderose, so why set it equal to an empty array?  I am sure there is a reason19:04
dimsbknudson : does the yaml+oslo.policy need to land for Mitaka? https://review.openstack.org/#/q/topic:yaml19:04
bknudsondims: nothing depends on it.19:05
henrynashstevemar: got a second to answer an osc question?19:05
bknudsonjust makes things easier to use19:05
rderoseayoung if the user was created with a password and then updates with a null password, then remove the old password19:05
rderoseayoung does that make sense?19:05
ayoungOK  it makes sense19:05
rderoseayoung: cool19:05
dimsbknudson : ack, then first thing for Newton then19:06
bknudsonwaiting for newton is safer at this point19:06
*** ninag has joined #openstack-keystone19:07
*** josecastroleon has joined #openstack-keystone19:07
openstackgerritMerged openstack/keystone: Avoid using `len(x)` to check if x is empty  https://review.openstack.org/28137419:08
*** subscope has quit IRC19:08
*** petertr7_away is now known as petertr719:10
ayoungrderose, +2A19:12
rderoseayoung: :)19:12
rderoseayoung: and thanks19:13
*** rderose has quit IRC19:13
*** pushkaru has joined #openstack-keystone19:17
*** vgridnev has quit IRC19:19
stevemarhenrynash: back19:21
*** clenimar has quit IRC19:23
*** vgridnev has joined #openstack-keystone19:24
ayounglbragstad, where are we with https://review.openstack.org/#/c/258650/19:26
patchbotayoung: patch 258650 - keystone - [WIP]Make fernet default token provider19:26
stevemardims: bknudson definitely wait til N for the yaml support19:30
henrynashstevemar: actually I’m slinking off to dinner, so be back on later19:30
stevemarhenrynash: alrighty19:30
bknudsonbon apetit19:30
henrynashah merci, mes amis19:32
bjornar_Can I ask why you chose fernet, and not a improved version of it?19:34
bjornar_I mean.. a version that for example has information about token expire time19:34
dolphmbjornar_: define "improved"?19:34
bjornar_so one could check it early and cheeply19:35
*** su_zhang has quit IRC19:35
*** su_zhang has joined #openstack-keystone19:36
dolphmbjornar_: we include the expiration in the payload, but fernet's model is to use the token's creation time + a TTL determined by the client. i'd like to move to that model anyway19:36
bjornar_The basic idea is ok, I guess19:36
dolphmthe creation time is available in plain text19:36
bjornar_but expiration should be in plain text19:36
bjornar_..as well19:36
morganbjornar_: i disagree19:36
bjornar_morgan, why?19:36
*** josecastroleon has quit IRC19:37
bjornar_morgan, I think it is wrong that expired tokens are "expensive"19:37
morganbjornar_: the token format is opaque because we change internals of the token itself as needed. the token format data [internal] should not be introspected directly19:37
morganask keystone if you need the data19:37
bjornar_Yeah, I think the token format in general is fine19:37
dolphmbjornar_: clients can introspect the creation time, apply a TTL, and decide whether or not to validate it against keystone "cheaply"19:38
morganthe token payload data beyond being fernet is not a contract19:38
bjornar_I just see a problem with expiration .. but true, dolphm19:38
morganso HMAC(create_time, AES_ENCRYPTED_PAYLOAD)19:38
dolphmbjornar_: what's the problem?19:38
dstanekbjornar_: how short is you ttl that it's a performance problem?19:38
bjornar_dolphm, but requires frontend to know about ttl19:39
morganyou could configure the app that needs to introspec the token to do create_time + ttl compared to now()19:39
bjornar_I just say that expiration time is more important than creation time19:39
morganbjornar_: then ask keystone. again, i am very much against the token payload being a contract19:39
dolphmbjornar_: i'd be happy to hear your reasoning19:39
morganwe tried this with PKI and it means we're locked in. also Fernet spec doesn't really allow it19:40
*** su_zhang has quit IRC19:40
bjornar_I think the general fernet token is fine, and I have infact implemented a version of it myself19:40
bjornar_The only thing I dislike is that you have to do "heavy" calculations to figure if a expired token is valid19:41
morganbjornar_: fernet is a published spec. not something we can easily change without reimplementing the code to generate it19:41
bjornar_this could be done alot cheaper with a "based-on" approach19:41
bjornar_and fernet is not a RFC19:41
morganit is not an RFC, it is a published spec19:41
bjornar_its afaik something used inhouse19:41
morgani am against re-implementing code for the sake of limited benefit19:42
bjornar_im against using bad specs when we could have better ;)19:42
bjornar_its not that important, really19:42
bjornar_but I have a point19:42
morgani disagree with your point and classification of it being a bad spec19:42
morganif we're making more of a departure we should remove bearer tokens19:43
bjornar_I dont mean its a _bad_ spec19:43
morganwe tried more data available for anyone to introspect from the token payload, and it really is a bad idea19:43
bjornar_just as everything could be a bit better19:43
*** timcline_ has joined #openstack-keystone19:43
morganit was a trainwreck. we intentionally chose to ensure that the payload was opaque so we weren't locked into someone directly looking at the payload19:44
morganthe data format is optimised in a way to limit the size of the token id (based on the payload)19:44
bjornar_but that would still be true with Version ‖ Timestamp || TTL ‖ IV ‖ Ciphertext19:45
morganand it allows us to make changes internally to the payload without breaking people19:45
morganagain i disagree, this means we can change the timestamp to be an int or a bytepack, or anything else19:45
morganerm TTL.19:45
bjornar_but thats the spec19:45
morganno the spec is HMAC(create_time, AES_ENCRYPTED)19:46
morgananyway.19:46
bjornar_anyway19:46
dolphmbjornar_: so you don't value distributed systems enforcing varying TTL's?19:46
bjornar_dolphm, yes....19:46
bjornar_dolphm, dont know how that relates.19:47
bjornar_Only thing I say is that with a ttl in plain, it would be cheaper to calculate expired tokens, thats all19:47
dolphmbjornar_: that's the use case for keeping the TTL as something that can be enforced client-side: distributed systems enforcing varying TTLs19:47
dolphmbjornar_: you're assuming all clients should enforce the same ttl19:48
bjornar_dolphm, on the same token?19:48
dolphmyes19:48
morganbjornar_: either you trust keystone, or you don't19:48
bjornar_dolphm, so you have the same token with different ttls?19:48
morganif you're trusting keystone to enforce the TTL, you don't care about the TTL being different on different systems19:48
bjornar_its not important tho, a minor detail anyway19:49
morgani also feel like this is an over optimisation19:49
morganand would force us to carry a lot more code.19:50
*** jsavak has quit IRC19:50
dolphmbjornar_: that is how fernet is designed, yes. we are not currently taking advantage of that behavior, but we could move in that direction fairly easily.19:50
bjornar_I actually liked the ideas with CMS, but see that it does not scale when object grows19:50
bjornar_morgan, the small nice thing is ofcorse that "everyone" could reject expired without asking ks19:51
*** fawadkhaliq has joined #openstack-keystone19:52
*** jsavak has joined #openstack-keystone19:53
dolphmbjornar_: almost like you can do today =)19:55
bjornar_dolphm, ok?19:55
dolphmbjornar_: you can also opt to distribute the HMAC keys more beyond keystone as another performance optimization19:56
morganyou can also opt to distribute the AES keys too if you want19:57
*** su_zhang has joined #openstack-keystone19:57
morganbut we don't guarantee the payload format is a contract.19:58
*** su_zhang has quit IRC19:58
morganoutside of keystone19:58
bjornar_I reported a bug a month ago with keystone-manage19:58
*** su_zhang has joined #openstack-keystone19:59
bjornar_the help is incorrect: --bootstrap-username and so on does not work19:59
morgani believe that was fixed.19:59
bjornar_I believed too19:59
morganalso --bootstrap is very new / has not been released yet.19:59
morgani mena it landed i think between m2 and m319:59
openstackgerritMerged openstack/keystone: Updates TOTP release note  https://review.openstack.org/28352019:59
bjornar_its not in master20:00
bjornar_the fix I mean20:00
morganfairly certain --bootstrap-username worked .20:00
morganwhen the code was written20:00
morganbut anyway, there are things that will be looked at before RC.20:00
morganso likely that'll get flagged.20:01
bjornar_keystone-manage: error: unrecognized arguments: --boostrap-username root20:01
morganboostrap?20:01
morganbootstrap20:01
bjornar_oh, damnit20:01
morganhehe20:01
bjornar_hehe.. I have written that tho whole time20:01
morganno worries20:02
*** jsavak has quit IRC20:02
bjornar_(but it was a bug once)20:02
*** vgridnev has quit IRC20:02
*** su_zhang has quit IRC20:03
*** jsavak has joined #openstack-keystone20:03
stevemarbetter than bookstrap20:04
bjornar_or.. strapon20:04
*** gyee has quit IRC20:12
*** subscope has joined #openstack-keystone20:16
stevemarayoung: question, nkinder is west coast right?20:16
ayoungstevemar, yeah northern Cali near Shasta20:16
stevemarayoung: cool cool20:16
ayoungnot bay area20:16
nkinderstevemar: yep20:18
nkindernot too far from the bay area20:19
*** spzala has quit IRC20:21
*** spzala has joined #openstack-keystone20:22
*** spzala_ has joined #openstack-keystone20:24
*** spzala has quit IRC20:26
*** spzala has joined #openstack-keystone20:27
dstanekstevemar: morgan: this is what i was talking about the other day: https://review.openstack.org/#/c/283522/ credential validation20:28
patchbotdstanek: patch 283522 - keystone - WIP - Add validation for totp credentials20:28
*** spzala_ has quit IRC20:28
openstackgerritHenrique Truta proposed openstack/keystone-specs: Fix cascade operations documentation  https://review.openstack.org/27483620:29
*** su_zhang has joined #openstack-keystone20:29
*** spzala has quit IRC20:31
*** su_zhang has quit IRC20:34
*** mylu has joined #openstack-keystone20:50
*** dims has quit IRC21:01
*** lhcheng has quit IRC21:01
*** dims has joined #openstack-keystone21:03
henrynashstevemar: hi….you have a few moments now, by any chance?21:04
stevemarhenrynash: for you, anytime21:04
henrynashstevemar: aww, shucks21:04
henrynashstevemar: so, osc21:04
*** mylu has quit IRC21:05
henrynashstevemar: trying to understand how something like: os project show test21:05
henrynashstevemar: actually works21:05
stevemarhenrynash: like the code path?21:05
henrynashstevemar: yep….so in osc/projects.py I see how we call find_resource21:06
henrynashstevemar: osc/project.py (sorry(21:06
henrynashstevemar: which (in utils.find_resource) does this kind of try client.get with some options, and if that doesn;t work try client.find21:07
*** lhcheng has joined #openstack-keystone21:08
*** ChanServ sets mode: +v lhcheng21:08
henrynashsteevmar: so the path I can’t quiet work out, is when you do: osc project show —domain A test21:08
henrynashstevemar: there’s code in osc/project.py to ge tthe domain_id for A and pass it into the find_resource21:09
stevemarhenrynash: let me look at that, i think you're talking about the common utils21:09
henrynashstevemar: but specifies domain_id….and if you look in keystoneclient/projects……the get method doesn’t take a domain, so I assume it falls into the list method…which wants a parameter called “domain” not “domain_id”…..21:10
stevemarhenrynash: you talking about this: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/project.py#L82-L85 ?21:10
stevemarhenrynash: or over here: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/project.py#L112-L114 ?21:11
henrynashstevemar: yes, taht’s for create….21:11
henrynashstevemar: or line 323 for teh show command21:12
stevemarhenrynash: to 323 is the find_resource function...21:13
stevemarhenrynash: like you thought, it tries a get GET calls and falls back to a LIST call, in an attempt to find things21:13
henrynashstevemar: indeed….21:13
stevemarthe find_domain() function, is really there to be a helper function, we pass in the parsed_args and either return a valid domain object or None21:14
henrynashstevemar: and if you look in keystoneclient/v3/projects.py21:14
henrynashstevemar: then the list methods takes domain not domain_id as a named param21:14
*** timcline_ has quit IRC21:15
stevemarhenrynash: line?21:15
henrynash9321:15
*** timcline_ has joined #openstack-keystone21:15
henrynashhttps://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/projects.py21:16
openstackgerritRon De Rose proposed openstack/keystone: Shadow users - Shadow federated users  https://review.openstack.org/27916221:17
*** rderose has joined #openstack-keystone21:17
henrynashstevemar: the same is true for show users…..I don’t quite understand teh named parameter mismatch21:17
*** boris-42 has joined #openstack-keystone21:18
*** timcline_ has quit IRC21:19
henrynashstevemar: before looking at it, I expected to find teh keystoneclient projects.get() method to access a domain_id….but it doesn’t do thay either21:20
henrynash(…to accept a domain_id…)21:20
stevemarhenrynash: hmm21:24
*** jsavak has quit IRC21:24
henrynashstevemar: for create project we DO pass it as domain (not domain_id)….but for create it isn’t a named param, so it doesn’t matter anyway21:26
stevemarhenrynash: i think we do funky stuff here: https://github.com/openstack/python-openstackclient/blob/823ba770e0baafa707c89723c576db060b1b4742/openstackclient/identity/common.py#L93-L12821:27
*** mylu has joined #openstack-keystone21:28
henrynashstevemar: not entirely sure what that does….other than if Forbidden makes a fake local represenation of the entity21:30
openstackgerritSteve Martinelli proposed openstack/keystone-specs: Fix cascade operations documentation  https://review.openstack.org/27483621:31
*** gyee has joined #openstack-keystone21:32
*** ChanServ sets mode: +v gyee21:32
openstackgerritRon De Rose proposed openstack/keystone: Shadow users - Shadow federated users  https://review.openstack.org/27916221:33
openstackgerritSteve Martinelli proposed openstack/keystone-specs: Fix cascade operations documentation  https://review.openstack.org/27483621:34
henrynashstevemar: …although that isn’t used to get the project (just the domain)21:34
stevemarhenrynash: maybe we're getting lucky and just calling list with kwargs and not the actual named parameter?!21:36
*** knikolla has quit IRC21:36
henrynashstevemar: which would mean that if you have duplicate project names in mutiple domains, you’d get a list back rather than the one you were asking for?21:37
*** sdake has quit IRC21:37
stevemarhenrynash: i don't think so.. i think we're luckily using the filters21:37
*** mylu has quit IRC21:37
stevemarhenrynash: i think we're using the "domain_id=blah" query filter in GET /v3/projects21:38
stevemarinstead of the actual positional arg21:38
stevemarthat ksc exposes21:38
henrynashstevemar: ahh, its in kwargs so gets passe in anyway!21:38
stevemarhenrynash: i think so21:38
henrynashstevemar: oh, brother21:39
*** fawadkhaliq has quit IRC21:39
*** mylu has joined #openstack-keystone21:39
stevemarhenrynash: hey, no one has noticed so far hee21:39
henrynashstevemar: ok, at least I’m not losing my marbles....21:40
*** mylu has quit IRC21:40
*** su_zhang has joined #openstack-keystone21:40
stevemarhenrynash: not yet21:41
*** spzala_ has joined #openstack-keystone21:41
henrynashstevemar: true, plenty of time for that....21:41
*** tsymanczyk has quit IRC21:41
*** tsymancz1k has quit IRC21:41
henrynashstevemar: ok, thx….I came across this for domain specifi roles (of coruse)….so now can see how to do this….I might come abck in and fix up osc for this oevrall problem21:42
*** timcline_ has joined #openstack-keystone21:49
*** mylu has joined #openstack-keystone21:50
openstackgerritRon De Rose proposed openstack/keystone: Shadow users - Shadow federated users  https://review.openstack.org/27916221:50
*** mylu has quit IRC21:52
ayoungstevemar, so I had mentally handed off Fernet-default to lbragstad but he's tied up for a while.  I'm going to try and get that done21:55
openstackgerritBrant Knudson proposed openstack/keystone: Fix project-related forbidden response messages  https://review.openstack.org/28332521:55
openstackgerritBrant Knudson proposed openstack/keystone: Move resource manager tests out of test_backend  https://review.openstack.org/28382221:55
*** ninag has quit IRC21:56
*** ninag has joined #openstack-keystone21:57
openstackgerritSteve Martinelli proposed openstack/keystone: Implied roles index with cascading delete  https://review.openstack.org/28192121:58
stevemarayoung: that would be wonderful21:58
ayoungstevemar, its close21:58
stevemarayoung: i just cleaned up ^21:58
ayoungstevemar, nice21:59
stevemarayoung: i'm going to test it manually21:59
stevemarayoung: i asked davechen to remove the rally stuff, it wasn't working anyway :(22:00
*** ninag has quit IRC22:01
*** lhcheng has quit IRC22:02
*** dims has quit IRC22:02
openstackgerritBrant Knudson proposed openstack/keystone: db_sync doesn't create default domain  https://review.openstack.org/28204222:02
ayoungstevemar, looks good.  +2 is conditional on manual testing of course, but I assume you won't let it go through early22:02
*** josecastroleon has joined #openstack-keystone22:02
stevemarayoung: yep22:04
stevemarsigh, gotta leave, be online later22:04
openstackgerritBrant Knudson proposed openstack/keystone: db_sync doesn't create default domain  https://review.openstack.org/28204222:07
*** su_zhang has quit IRC22:07
openstackgerritBrant Knudson proposed openstack/keystone: Remove migration_helpers.get_default_domain  https://review.openstack.org/28204922:07
*** su_zhang has joined #openstack-keystone22:08
*** edmondsw has quit IRC22:09
*** pauloewerton has quit IRC22:10
mc_nairanyone know if there are currently Tempest tests which flex the hierarchical projects functionality (e.g. creates and deletes nested projects)? I'm having trouble finding any currently, but would be nice to confirm.22:12
*** sigmavirus24 is now known as sigmavirus24_awa22:13
*** jaugustine has quit IRC22:15
*** diazjf has quit IRC22:17
*** mylu has joined #openstack-keystone22:19
*** timcline_ has quit IRC22:19
*** lhcheng has joined #openstack-keystone22:20
*** ChanServ sets mode: +v lhcheng22:20
*** david8hu has quit IRC22:22
*** sdake has joined #openstack-keystone22:30
*** ninag has joined #openstack-keystone22:32
*** josecastroleon has quit IRC22:32
rderosedolphm: wondering if we could meet re: shadowing federated users?22:34
*** petertr7 is now known as petertr7_away22:34
*** ninag has quit IRC22:36
*** mvk has joined #openstack-keystone22:39
*** spzala_ has quit IRC22:40
*** mylu has quit IRC22:40
*** dims has joined #openstack-keystone22:40
*** mylu has joined #openstack-keystone22:41
dstanekgyee: you're killing me!22:42
dstanekgyee: i like the idea of grouping all of the totp algorithm stuff in one place instead of three.22:43
dstanekgyee: others may not like it, but that's why it's currently a wip22:44
dstanekrderose: gate jobs have been started on your bug fix!22:44
openstackgerritBrant Knudson proposed openstack/keystone: Reference config values at runtime  https://review.openstack.org/28384222:45
*** subscope has quit IRC22:48
*** timcline_ has joined #openstack-keystone22:51
rderosedstanek: cool22:51
*** su_zhang has quit IRC22:52
*** su_zhang has joined #openstack-keystone22:53
*** timcline_ has quit IRC22:55
*** rderose has quit IRC22:55
openstackgerritBrant Knudson proposed openstack/keystone: Reference config values at runtime  https://review.openstack.org/28384222:56
gyeedstanek, sorry, just got back22:57
gyeedstanek, that code belongs to the plugin itself22:57
dstanekgyee: all of it?22:57
gyeethe password part22:58
*** mancdaz has quit IRC22:58
*** dstanek has quit IRC22:58
*** dulek has quit IRC22:58
*** marekd has quit IRC22:58
*** richm has quit IRC22:58
*** mariusv has quit IRC22:58
*** sileht has quit IRC22:58
*** patchbot has quit IRC22:58
*** ngupta has quit IRC22:58
*** akscram has quit IRC22:58
*** Ephur has quit IRC22:58
*** hogepodge has quit IRC22:58
*** mvk has quit IRC22:58
*** spandhe has quit IRC22:58
*** pcaruana has quit IRC22:58
*** topol_ has quit IRC22:58
*** Daviey has quit IRC22:58
*** opilotte- has quit IRC22:58
*** dhellmann has quit IRC22:58
*** Dave has quit IRC22:58
*** dims has quit IRC22:58
*** lhcheng has quit IRC22:58
*** ayoung has quit IRC22:58
*** csoukup has quit IRC22:58
*** jed56 has quit IRC22:58
*** lbragstad_ has quit IRC22:58
*** mnaser has quit IRC22:58
*** markvoelker has quit IRC22:58
*** d34dh0r53 has quit IRC22:58
*** ryanpetrello has quit IRC22:58
*** mhu has quit IRC22:58
*** Guest51435 has quit IRC22:58
*** eglute has quit IRC22:58
*** BlackDex has quit IRC22:58
*** DuncanT has quit IRC22:58
*** raorn has quit IRC22:58
*** dtroyer has quit IRC22:58
*** darrenc has quit IRC22:58
*** bradjones has quit IRC22:58
*** clayton has quit IRC22:58
*** lifeless has quit IRC22:58
*** tjcocozz_ has quit IRC22:58
*** jidar has quit IRC22:58
*** boris-42 has quit IRC22:58
*** pushkaru has quit IRC22:58
*** slberger has quit IRC22:58
*** gordc has quit IRC22:58
*** jamielennox has quit IRC22:58
*** amakarov_away has quit IRC22:58
*** chlong_ has quit IRC22:58
*** errr has quit IRC22:58
*** sigmavirus24_awa has quit IRC22:58
*** andrewbogott has quit IRC22:58
*** zigo has quit IRC22:58
*** rvba has quit IRC22:58
*** martinus__ has quit IRC22:58
*** mtreinish has quit IRC22:58
*** ktychkova has quit IRC22:58
*** dobson has quit IRC22:58
*** ianw has quit IRC22:58
*** gyee has quit IRC22:58
*** phalmos has quit IRC22:58
*** henrynash has quit IRC22:58
*** ccard__ has quit IRC22:58
*** SpamapS has quit IRC22:58
*** rdo has quit IRC22:58
*** miguelgrinberg has quit IRC22:58
*** ktychkova_ has quit IRC22:58
*** john5223 has quit IRC22:58
*** david_cu has quit IRC22:58
*** pkarikh_ has quit IRC22:58
*** gsilvis has quit IRC22:58
*** rm_work has quit IRC22:58
*** jraim has quit IRC22:58
*** tpeoples has quit IRC22:58
*** agireud has quit IRC22:58
*** EmilienM has quit IRC22:58
*** adam_g has quit IRC22:58
*** andreaf has quit IRC22:58
*** gus has quit IRC22:58
*** cloudnull has quit IRC22:58
*** Anticimex has quit IRC22:58
*** flaper87 has quit IRC22:58
*** pumaranikar has quit IRC22:58
*** sudorandom has quit IRC22:58
*** dancn has quit IRC22:58
*** bigjools has quit IRC22:58
*** mjb has quit IRC22:58
*** mdavidson has quit IRC22:58
*** mfisch has quit IRC22:58
*** freerunner has quit IRC22:58
*** gerhardqux has quit IRC22:58
*** ramishra has quit IRC22:58
*** comstud has quit IRC22:58
*** mylu has quit IRC22:58
*** dan_nguyen has quit IRC22:58
*** toddnni has quit IRC22:58
*** d0ugal has quit IRC22:58
*** tristanC has quit IRC22:58
*** kevinbenton has quit IRC22:58
*** morgan has quit IRC22:58
*** yarkot has quit IRC22:58
*** hockeynut has quit IRC22:58
*** zeus has quit IRC22:58
*** breton has quit IRC22:58
*** mordred has quit IRC22:58
*** rha has quit IRC22:58
*** browne has quit IRC22:58
*** ekarlso- has quit IRC22:58
*** Oku_OS has quit IRC22:58
*** jdennis has quit IRC22:58
*** Nakato has quit IRC22:58
*** anteaya has quit IRC22:58
*** krotscheck has quit IRC22:58
*** bknudson has quit IRC22:58
*** grassy has quit IRC22:58
*** _fortis has quit IRC22:58
*** fpatwa has quit IRC22:58
*** iurygregory has quit IRC22:58
*** blogan has quit IRC22:58
*** sshen has quit IRC22:58
*** mkoderer__ has quit IRC22:58
*** arunkant has quit IRC22:58
*** BAKfr has quit IRC22:58
*** BrAsS_mOnKeY has quit IRC22:58
*** hughsaunders has quit IRC22:58
*** dolphm has quit IRC22:58
*** DinaBelova has quit IRC22:58
*** afazekas has quit IRC22:58
*** smurke has quit IRC22:58
*** pleia2 has quit IRC22:58
*** timburke has quit IRC22:58
*** bapalm has quit IRC22:58
*** Tridde has quit IRC22:58
*** baffle has quit IRC22:58
*** kfox1111 has quit IRC22:58
*** rmstar has quit IRC22:58
*** smcginnis has quit IRC22:58
*** navidp has quit IRC22:58
*** odyssey4me has quit IRC22:58
*** skoude has quit IRC22:58
*** nonameentername has quit IRC22:58
*** boltR has quit IRC22:58
*** huats_ has quit IRC22:58
*** zzzeek has quit IRC22:58
*** jasondotstar has quit IRC22:58
*** jgriffith has quit IRC22:58
*** redrobot has quit IRC22:58
*** lennyb_ has quit IRC22:58
*** crinkle has quit IRC22:58
*** briancurtin has quit IRC22:58
*** zhiyan has quit IRC22:58
*** ctracey has quit IRC22:58
*** raildo has quit IRC22:58
*** serverascode has quit IRC22:58
*** xek has quit IRC22:58
*** lbragstad has quit IRC22:58
*** charz has quit IRC22:58
*** johnthetubaguy has quit IRC22:58
*** ChanServ has quit IRC22:58
*** sdake is now known as jpeeler22:58
*** jpeeler is now known as 64MAAECDI23:00
*** johnthetubaguy has joined #openstack-keystone23:01
*** charz has joined #openstack-keystone23:01
*** lbragstad has joined #openstack-keystone23:01
*** xek has joined #openstack-keystone23:01
*** raildo has joined #openstack-keystone23:01
*** ctracey has joined #openstack-keystone23:01
*** serverascode has joined #openstack-keystone23:01
*** zhiyan has joined #openstack-keystone23:01
*** briancurtin has joined #openstack-keystone23:01
*** crinkle has joined #openstack-keystone23:01
*** redrobot has joined #openstack-keystone23:01
*** jgriffith has joined #openstack-keystone23:01
*** jasondotstar has joined #openstack-keystone23:01
*** zzzeek has joined #openstack-keystone23:01
*** boltR has joined #openstack-keystone23:01
*** huats_ has joined #openstack-keystone23:01
*** skoude has joined #openstack-keystone23:01
*** odyssey4me has joined #openstack-keystone23:01
*** nonameentername has joined #openstack-keystone23:01
*** navidp has joined #openstack-keystone23:01
*** smcginnis has joined #openstack-keystone23:01
*** rmstar has joined #openstack-keystone23:01
*** lennyb_ has joined #openstack-keystone23:01
*** Dave has joined #openstack-keystone23:01
*** dhellmann has joined #openstack-keystone23:01
*** opilotte- has joined #openstack-keystone23:01
*** Daviey has joined #openstack-keystone23:01
*** topol_ has joined #openstack-keystone23:01
*** pcaruana has joined #openstack-keystone23:01
*** spandhe has joined #openstack-keystone23:01
*** mvk has joined #openstack-keystone23:01
*** jidar has joined #openstack-keystone23:01
*** tjcocozz_ has joined #openstack-keystone23:01
*** lifeless has joined #openstack-keystone23:01
*** bradjones has joined #openstack-keystone23:01
*** clayton has joined #openstack-keystone23:01
*** darrenc has joined #openstack-keystone23:01
*** dtroyer has joined #openstack-keystone23:01
*** raorn has joined #openstack-keystone23:01
*** DuncanT has joined #openstack-keystone23:01
*** BlackDex has joined #openstack-keystone23:01
*** eglute has joined #openstack-keystone23:01
*** Guest51435 has joined #openstack-keystone23:01
*** ryanpetrello has joined #openstack-keystone23:01
*** mhu has joined #openstack-keystone23:01
*** d34dh0r53 has joined #openstack-keystone23:01
*** markvoelker has joined #openstack-keystone23:01
*** 32NAAC6RR has joined #openstack-keystone23:01
*** mnaser has joined #openstack-keystone23:01
*** jed56 has joined #openstack-keystone23:01
*** csoukup has joined #openstack-keystone23:01
*** ayoung has joined #openstack-keystone23:01
*** lhcheng has joined #openstack-keystone23:01
*** dims has joined #openstack-keystone23:01
*** comstud has joined #openstack-keystone23:01
*** ramishra has joined #openstack-keystone23:01
*** gerhardqux has joined #openstack-keystone23:01
*** freerunner has joined #openstack-keystone23:01
*** mfisch has joined #openstack-keystone23:01
*** mdavidson has joined #openstack-keystone23:01
*** mjb has joined #openstack-keystone23:01
*** bigjools has joined #openstack-keystone23:01
*** dancn has joined #openstack-keystone23:01
*** sudorandom has joined #openstack-keystone23:01
*** pumaranikar has joined #openstack-keystone23:01
*** flaper87 has joined #openstack-keystone23:01
*** Anticimex has joined #openstack-keystone23:01
*** gus has joined #openstack-keystone23:01
*** andreaf has joined #openstack-keystone23:01
*** cloudnull has joined #openstack-keystone23:01
*** adam_g has joined #openstack-keystone23:01
*** EmilienM has joined #openstack-keystone23:01
*** agireud has joined #openstack-keystone23:01
*** tpeoples has joined #openstack-keystone23:01
*** jraim has joined #openstack-keystone23:01
*** rm_work has joined #openstack-keystone23:01
*** asimov.freenode.net sets mode: +vv ayoung lhcheng23:01
*** DinaBelova has joined #openstack-keystone23:01
*** boris-42 has joined #openstack-keystone23:01
*** pushkaru has joined #openstack-keystone23:01
*** slberger has joined #openstack-keystone23:01
*** gordc has joined #openstack-keystone23:01
*** jamielennox has joined #openstack-keystone23:01
*** amakarov_away has joined #openstack-keystone23:01
*** chlong_ has joined #openstack-keystone23:01
*** errr has joined #openstack-keystone23:01
*** sigmavirus24_awa has joined #openstack-keystone23:01
*** andrewbogott has joined #openstack-keystone23:01
*** zigo has joined #openstack-keystone23:01
*** rvba has joined #openstack-keystone23:01
*** martinus__ has joined #openstack-keystone23:01
*** mtreinish has joined #openstack-keystone23:01
*** ktychkova has joined #openstack-keystone23:01
*** dobson has joined #openstack-keystone23:01
*** ianw has joined #openstack-keystone23:01
*** asimov.freenode.net sets mode: +v jamielennox23:01
*** 64MAAECDI is now known as sdake23:01
*** mancdaz has joined #openstack-keystone23:01
*** dulek has joined #openstack-keystone23:01
*** marekd has joined #openstack-keystone23:01
*** dstanek has joined #openstack-keystone23:01
*** richm has joined #openstack-keystone23:02
*** mariusv has joined #openstack-keystone23:02
*** sileht has joined #openstack-keystone23:02
*** patchbot has joined #openstack-keystone23:02
*** ngupta has joined #openstack-keystone23:02
*** akscram has joined #openstack-keystone23:02
*** Ephur has joined #openstack-keystone23:02
*** hogepodge has joined #openstack-keystone23:02
dstanekgyee: so i would put the three totp related functions in three separate parts of the code base?23:02
*** browne has joined #openstack-keystone23:03
*** ekarlso- has joined #openstack-keystone23:03
*** Oku_OS has joined #openstack-keystone23:03
*** jdennis has joined #openstack-keystone23:03
*** Nakato has joined #openstack-keystone23:03
*** anteaya has joined #openstack-keystone23:03
*** krotscheck has joined #openstack-keystone23:03
*** bknudson has joined #openstack-keystone23:03
*** _fortis has joined #openstack-keystone23:03
*** grassy has joined #openstack-keystone23:03
*** fpatwa has joined #openstack-keystone23:03
*** iurygregory has joined #openstack-keystone23:03
*** blogan has joined #openstack-keystone23:03
*** mkoderer__ has joined #openstack-keystone23:03
*** sshen has joined #openstack-keystone23:03
*** arunkant has joined #openstack-keystone23:03
*** BAKfr has joined #openstack-keystone23:03
*** pleia2 has joined #openstack-keystone23:03
*** BrAsS_mOnKeY has joined #openstack-keystone23:03
*** hughsaunders has joined #openstack-keystone23:03
*** dolphm has joined #openstack-keystone23:03
*** afazekas has joined #openstack-keystone23:03
*** smurke has joined #openstack-keystone23:03
*** timburke has joined #openstack-keystone23:03
*** bapalm has joined #openstack-keystone23:03
*** Tridde has joined #openstack-keystone23:03
*** baffle has joined #openstack-keystone23:03
*** kfox1111 has joined #openstack-keystone23:03
*** asimov.freenode.net sets mode: +vo bknudson dolphm23:03
*** toddnni has joined #openstack-keystone23:03
*** d0ugal has joined #openstack-keystone23:03
*** tristanC has joined #openstack-keystone23:03
*** kevinbenton has joined #openstack-keystone23:03
*** morgan has joined #openstack-keystone23:03
*** yarkot has joined #openstack-keystone23:03
*** hockeynut has joined #openstack-keystone23:03
*** zeus has joined #openstack-keystone23:03
*** breton has joined #openstack-keystone23:03
*** mordred has joined #openstack-keystone23:03
*** rha has joined #openstack-keystone23:03
*** asimov.freenode.net sets mode: +v morgan23:03
*** mylu has joined #openstack-keystone23:03
*** dan_nguyen has joined #openstack-keystone23:03
*** sigmavirus24_awa has quit IRC23:04
*** gsilvis_ has joined #openstack-keystone23:04
*** gyee has joined #openstack-keystone23:06
*** phalmos has joined #openstack-keystone23:06
*** henrynash has joined #openstack-keystone23:06
*** ccard__ has joined #openstack-keystone23:06
*** SpamapS has joined #openstack-keystone23:06
*** rdo has joined #openstack-keystone23:06
*** miguelgrinberg has joined #openstack-keystone23:06
*** ktychkova_ has joined #openstack-keystone23:06
*** john5223 has joined #openstack-keystone23:06
*** david_cu has joined #openstack-keystone23:06
*** pkarikh_ has joined #openstack-keystone23:06
*** gsilvis has joined #openstack-keystone23:06
*** asimov.freenode.net sets mode: +vv gyee henrynash23:06
dstanekgyee: so i would put the three totp related functions in three separate parts of the code base?23:06
*** ChanServ has joined #openstack-keystone23:06
*** asimov.freenode.net sets mode: +o ChanServ23:06
*** ChanServ sets mode: +ov morgan dstanek23:06
*** miguelgrinberg has quit IRC23:07
*** gsilvis has quit IRC23:07
*** david_cu has quit IRC23:07
*** SpamapS has quit IRC23:07
*** bjornar_ has quit IRC23:08
gyeedstanek, the base32 check is the only code that is shared23:08
*** miguelgrinberg has joined #openstack-keystone23:08
*** exploreshaifali has joined #openstack-keystone23:08
*** exploreshaifali has quit IRC23:08
*** sigmavirus24_awa has joined #openstack-keystone23:08
dstanekgyee: i know the other two are each only used in one place, but to me it's better to group the full totp concept together23:08
*** david_cu has joined #openstack-keystone23:09
*** lhcheng has quit IRC23:09
*** SpamapS has joined #openstack-keystone23:09
gyeedstanek, one may even argue that the base32 requirement will be punted to the credential provider (i.e. barbican) later on23:11
dstanekgyee: eventually maybe23:11
gyeeas they are expected to be encrypted23:12
*** phalmos has quit IRC23:12
dstanekgyee: but i suspect that they won't want to understand and validate all credential type and would instead just store what they are told23:12
*** darrenc is now known as darrenc_afk23:13
*** pushkaru has quit IRC23:13
gyeedstanek, honestly, I suspect our credential APIs will be deprecated in the not to near future :)23:13
*** pushkaru has joined #openstack-keystone23:13
gyeewe have no encryption for DAR what so ever right now23:13
dstanekgyee: sure, but that doesn't change the design principle23:14
gyeemy point is TOTP is should encapsulated into the plugin itself23:14
gyeenot spread out into multiple places23:14
dstanekgyee: why in the plugin?23:15
gyeeplugins are expected to be self-contained23:15
dstanekgyee: you'd rather have the credentials and test import the plugin?23:16
gyeeplugins are really an interface23:16
dstanekgyee: why self-contained?23:16
gyeedstanek, so deployers can disable/remove for whatever legal reasons23:16
gyeesame as EC2/S3 that we are having trouble with23:17
dstanekgyee: you mean remove the code?23:17
gyeeyes23:17
gyeenot ship the plugin code23:17
dstanekthat's crazy to support23:17
gyeeso they have a choice23:17
*** slberger has left #openstack-keystone23:17
dstanekmost of the auth plugins we have are not self-contained23:17
*** pushkaru has quit IRC23:18
*** pushkaru has joined #openstack-keystone23:18
dstanekthey can always delete the plugin itself if they are paranoid about accidentally enabling it.23:18
gyeethey need to be23:18
gyeenot if they have to also delete stuff in credentials23:18
dstanekwhy would anyone need to do that?23:18
*** pumarani__ has joined #openstack-keystone23:19
gyeedstanek, take a look at the ec3/s3 patches that morgan put up23:19
gyeeec223:19
gyeeplugins design principals are a lot like contrib23:19
*** pumarani__ has quit IRC23:19
gyeethey should be optional and self-contained23:19
*** pumarani__ has joined #openstack-keystone23:20
*** pushkaru has quit IRC23:20
dstanekgyee: what is the business case for that?23:20
dstanekgyee: right now most are not self contained23:20
gyeedstanek, we need to make them self-contained23:20
dstanekgyee: so put the entirety of keystone.oauth1 into the oauth plugin?23:21
gyeedstanek, can you imagine changing Apache in order to get mod_xyz working?23:21
dstanekgyee: i don't understand that analogy.23:22
dstanekgyee: mod_xyz is using shared code out of apache to do some of its work23:22
dstanekgyee: i don't see any open ec2 patches23:23
gyeeimagine TOTP is mod_xyz23:23
gyeeI think Morgan may've abandoned the patches23:24
gyeelet me dig them up23:24
gyeedstanek, https://review.openstack.org/#/c/274973/23:26
patchbotgyee: patch 274973 - keystone - Move s3 Extension to core (ABANDONED)23:26
*** pumarani__ has quit IRC23:26
gyeedstanek, and this one https://review.openstack.org/#/c/275280/23:27
patchbotgyee: patch 275280 - keystone - Move EC2 extension to core (ABANDONED)23:27
*** lhcheng has joined #openstack-keystone23:28
*** ChanServ sets mode: +v lhcheng23:28
dstanekgyee: what does that have to do with auth plugins?23:28
gyeeself-contained principal23:29
dstanekgyee: if you, as a depoyer, want to remove totp from your system out of fear then you would have to actually delete code from cryptography as it is what actually has the algorithm23:29
dstanekgyee: i actually have a similar patch for some of the ec2 credentials stuff that i started last week. never finished enough to push to gerrit23:31
*** csoukup has quit IRC23:31
gyeedstanek, we introduced a bp sometime back to have a generic signature-based plugin, unfortunately, it didn't get enough support23:32
gyeeit was based on the same principal as token pipeline23:33
dstanekgyee: what does 'generic signature-based' mean?23:33
gyeedstanek, if you take a look at EC3, S3, tempurl, formpost, etc, they all shared a common mechanism, which is HMAC signature for token23:34
gyeewe basically need to translate protocol-specific to protocol-neutral prior to signature validation23:36
*** mylu has quit IRC23:36
dstanekgyee: why? i don't think i'm getting the full picture. do you have a link to the proposal?23:37
gyeelet me dig, its been a while23:38
gyeelike more than 2 years23:38
*** gordc has quit IRC23:41
navidplbragstad,23:42
*** mylu has joined #openstack-keystone23:43
gyeedstanek, is a version https://blueprints.launchpad.net/keystone/+spec/generic-signature-validation23:53
dstanekgyee: ah, you just want those modules to be implemented in terms of auth plugins23:58
*** rderose has joined #openstack-keystone23:59
dstanekgyee: even keystone.contrib.ec2 isn't very self-contained23:59

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