Wednesday, 2015-09-30

*** openstackgerrit has quit IRC00:01
*** openstackgerrit has joined #openstack-keystone00:02
*** openstackstatus has quit IRC00:02
*** openstack has joined #openstack-keystone00:03
*** openstackstatus has joined #openstack-keystone00:03
*** ChanServ sets mode: +v openstackstatus00:03
*** mylu has quit IRC00:06
*** mylu has joined #openstack-keystone00:06
*** devlaps has quit IRC00:09
*** dsirrine has quit IRC00:10
openstackgerritEric Brown proposed openstack/keystone: Multiple URLs may be specified for ldap url  https://review.openstack.org/22864400:10
*** geoffarnold has quit IRC00:11
*** mylu has quit IRC00:13
*** mylu has joined #openstack-keystone00:14
*** mylu has quit IRC00:14
*** jvarlamova has quit IRC00:15
*** mylu has joined #openstack-keystone00:15
*** shadower has quit IRC00:23
*** shadower has joined #openstack-keystone00:23
*** dsirrine has joined #openstack-keystone00:25
openstackgerritayoung proposed openstack/keystone-specs: Catalog scoped roles  https://review.openstack.org/22847700:32
*** mylu has quit IRC00:32
ayoungrichm, https://review.openstack.org/#/c/228644/2  multiple LDAP urls?  Is that an AD thing?00:33
*** sdake_ has joined #openstack-keystone00:38
*** stevemar has joined #openstack-keystone00:40
*** ChanServ sets mode: +o stevemar00:40
*** wwwjfy_ has quit IRC00:41
*** sdake has quit IRC00:43
gyeeayoung, afaik, Java JNDI supports multiple LDAP URLS for redundancy00:48
gyeenot sure if that's the same on the python side00:48
ayounggyee, on https://review.openstack.org/#/c/125704/  I state under the00:48
ayoungDeveloper Impact00:48
ayoung----------------00:48
ayoungIn the future, policy files can take advantage of the hierarchical nature of00:48
ayoungroles and avoid rules like domain_admin_or_project_admin.00:48
ayounggyee, I read through the bug report.  Looks OK, but not sure how much trouble I'm willing to go through to test.00:49
gyeeyeah, testing will be tough00:49
gyeeayoung, for the policy stuff, we either going to have fine grained policy or centralized policy00:50
*** dsirrine has quit IRC00:51
gyeeotherwise, hierarchical roles or virtual roles won't be very useful00:51
*** su_zhang has quit IRC00:52
*** su_zhang has joined #openstack-keystone00:52
*** sdake_ has quit IRC00:53
gyeeanyway, the idea of multiple LDAP URLs sound like an oxymoron as LDAP by design is *centralized*, *highly available*, and "fast lookup".00:54
ayounggyee, I know.00:54
ayounggyee, I think the multiple URLs is a HA/Failover thing00:55
ayoungif it works, we should support it.  Its come up a few times.  Might avoid someone having to run HA proxy infront of their LDAP server00:55
gyeefor HA, we should be talking to a VIP which is LB across multiple nodes00:55
ayounggyee, that has been the story thus far, but Keystone really should not be driving that.  If an org has a setup already, it might be outside the Keystone operators control00:56
*** _cjones_ has quit IRC00:56
ayounggyee, on the implied roles thing; this is a baby step.  I'00:56
ayoungI'm trying to make *any* progreasa here, and this is the smallest step I can conceive.00:57
*** browne has quit IRC00:57
gyeeI am not oppose to supporting it, we have to be flexible anyway00:57
gyeewe can't force operator to do things certain way00:57
*** EinstCrazy has joined #openstack-keystone00:58
gyeeayoung, oh I am all for improving role management00:58
gyeebut I also think that this is a cross-project thingy00:59
*** ankita_wagh has quit IRC01:01
*** brad[] has joined #openstack-keystone01:05
openstackgerritayoung proposed openstack/keystone-specs: Implied  Roles  https://review.openstack.org/12570401:06
ayounggyee, this is a prereq.  Policy and roles are cross project01:07
gyeeayoung, I see01:08
gyeeso the plan is get this done in Keystone first, then work on the individual projects01:09
ayounggyee, I also want to split the policy fioles  into two parts01:09
*** wwwjfy has joined #openstack-keystone01:09
ayoungone part will be matching the scope.  THat should not be changed. THe second is the role, and that can then be dynamically generated01:09
gyeeusing overlay01:09
gyeeone concern I have is Horizon01:10
ayoungoverlay?  you mean the policy thing?  Maybe, although I could also see the role part of policy becoming URL based instead of API01:10
ayoungHow is that?01:10
gyeeas of now they are still manually importing policy files01:10
gyeeayoung, I mean how does oslo.policy using the two parts, by overlay right?01:11
gyeeI thought we have this capability in oslo policy already no?01:11
ayounggyee, maybe.  But it does not have to be.  I could see the role check being done in middleware, and the scope check being done in the python code layer.  Often the scope check needs to fetch the object from the database01:12
ayoungbut, to start with..yeah, probably overlay.  Although that might not work;  opverlay reaplces a rule, and these need to be anded together01:12
gyeeayoung, you mean like this? https://github.com/openstack/swift/blob/master/swift/common/middleware/keystoneauth.py#L40801:15
gyeeayoung, so there are Swift and Barbican ACL and role checks middleware01:16
ayounggyee, I think so...looks sort of right01:16
gyeeI think there's opportunity to unify them01:16
gyeeinto one general purpose authorization middleware01:16
ayounggyee, that is why I've backed off on policy until we have hierarchical roles.  And I think we need the catalog-role-assignments too01:17
ayoungcatalog-role-assignments splits the project based APIs from the ones that are endpoint management...01:17
gyeeyou mean endpoint scoping?01:19
gyeesure01:19
ayounggyee, although the catalog-role-assignments approach makes splitting policy harder.01:19
ayounggyee, yeah...endpoint scoping01:19
*** davechen1 has joined #openstack-keystone01:23
richmayoung: the multiple URL thing corresponds to the -H argument of openldap commands01:27
richm-H ldapuri01:27
richm              Specify  URI(s)  referring to the ldap server(s); a list of URI,01:27
richm              separated by whitespace or commas is expected;01:27
ayoungrichm, so his change looks sane?  I've kindof come to that conclusion01:27
ayoungthat is what the bug report says, too01:27
* morgan wasn't aware that python-ldap elegantly handled that01:27
*** su_zhang has quit IRC01:28
morganwithout a bunch of extra logic wrapped around it01:28
richmayoung: it is sane to support multiple ldap URIs, yes01:28
ayoungrichm, I added yo as a reviewer.  I think he still has some kinks to work out, but a general thumbs up on the approach from you would make it easier for other reviewes to bless it01:29
ayoungmorgan, same here...I think it will make people happy01:29
richmdoes keystone allow you to specify an LDAP URI with the suffix as in ldap://host:port/dc=example,dc=com ?01:30
*** morgan is now known as notreallymorgan01:30
*** notreallymorgan is now known as morgan01:30
richmif so, this will require admins to specify the LDAP URI with the commas escaped as per LDAP URL escaping01:31
morganrichm: i think so?01:31
ayoungrichm, Keystone does not parse the URIs itslef, so it would allow that01:31
richm. . . which they are probably already doing if they are using ldapsearch -H with multiple URLs anyway01:31
morganrichm: but i don't think python-ldap can support ldap://<host>, ldap://<host>01:31
morganat least i am really not sure that it does01:32
ayoungmorgan, according to the bug report it can01:32
* morgan remembers writing terribad code around that because it didn't work 01:32
ayounghttps://bugs.launchpad.net/keystone/+bug/150063101:32
openstackLaunchpad bug 1500631 in Keystone "ldap url option actually supports multiple URIs" [Low,In progress] - Assigned to Eric Brown (ericwb)01:32
morganayoung: yeah I saw the bug01:32
ayoungl = ldap.initialize('ldap://localhost:389,ldaps://ldaps.company.com:636')01:32
ayoung l.simple_bind_s()01:32
ayoung(97, [], 1, [])01:32
morgani just remember python-ldap doing weeeeeiiirrdd things01:32
morganwhere like if the first one timed out it took ages to connect to the second one01:33
*** fawadkhaliq has joined #openstack-keystone01:33
morganit's not a connect to both and return first success or anything, but just horrible delays when the primary was out01:33
morganbetter to use haproxy as i recall01:33
morganbut again it has been a while01:33
* morgan shrugs01:33
gyeethe production LDAP server I dealt with in the past have only one URL and supports startTLS01:34
gyeeonly need to burn one hole in the firewall instead of multiple :)01:35
*** mylu has joined #openstack-keystone01:45
stevemarmorgan: according to the docs it works01:51
jamielennoxgyee: sorry just -1ed the global enforcement patch01:57
*** sdake has joined #openstack-keystone01:58
jamielennoxmorgan, bknudson: can you have a look at https://review.openstack.org/#/c/225516/ - it's a cherry-pick to stable01:59
*** agireud has quit IRC02:00
jamielennoxalso, easy ones: https://review.openstack.org/#/c/224975/ https://review.openstack.org/224407 https://review.openstack.org/22916102:00
gyeejamielennox, that's fine, I am OK with it as separate middleware02:00
gyeethanks for the review02:00
jamielennoxgyee: not even trying that any more, it's been so long02:01
gyeejamielennox, all I need is enforcement at middleware, AuthToken or otherwise02:02
gyeeI am very much open to suggestions on the deployment side02:02
jamielennoxgyee: i have the start of ideas for that02:02
*** stevemar has quit IRC02:02
jamielennoxa general way to fix the policy checking at decorator time02:03
gyeeayoung and I were chatting about generic authorization middleware earlier02:03
jamielennoxi think we can do it either there or auth_token02:03
jamielennoxvia the _user plugin02:03
gyeeI like the general direction, just haven't thought about the details02:03
jamielennoxhave auth_token middleware enforce that some policy has been checked on get_response()02:04
jamielennoxor similar02:04
jamielennoxstill thinking about that one, but i spent a chunk of the morning ripping up the AuthContext stuff02:04
jamielennoxneed to have a chat with someone about how we fix oslo.context02:04
gyeetoken validation -> build auth context -> authorization -> service02:04
gyeejamielennox, Swift and Barbican also support ACLs, which is based on attribute matching02:06
gyeeI am sure we can generalize them with oslo policy02:06
jamielennoxright, but can we do auth_token middleware, oslo.context and oslo.policy in keystone in a way that other services can replicate02:06
gyeeyeah that would be nice02:07
ayoungI'm seeing rpc_backend = nova.openstack.common.rpc.impl_qpid02:07
ayoung  and similar in Neutron.  Did they not get the memo that oslo-messaging is a separate library, or does no one care?  Or Maybethuis is Kilo code....02:07
jamielennoxi've got the auth_token bit, ttrying to figure out the context bit now, not sure on the policy yet02:07
ayoungyeah.....Kilo02:08
jamielennoxayoung: nova.openstack.common implies oslo-incubator , must have been about when it split02:12
gyeedidn't we deprecated the incubator stuff?02:12
*** stevemar has joined #openstack-keystone02:12
*** ChanServ sets mode: +o stevemar02:12
jamielennoxgyee: kilo02:12
gyeeah02:13
dims_gyee: ayoung: those are rpc aliases that are still supported even now - http://git.openstack.org/cgit/openstack/neutron/tree/neutron/common/rpc.py#n4102:17
*** stevemar has quit IRC02:17
ayoungdims_, are there any examples of how to configure using the new config options?  Specifically, the amqp driver?02:18
*** ngupta_ has joined #openstack-keystone02:18
*** ngupta has joined #openstack-keystone02:18
jamielennoxah ok, they're just aliases though, so they still point to the correct oslo.messaging driver underneath02:19
gyeedims_, k, gotcha02:19
dims_y02:19
dims_ayoung: amqp driver, best bet is to catch kgiusti02:20
dims_ayoung: or flaper8702:20
*** spandhe has quit IRC02:20
ayoungdims_, heh...yeah, talked with kgiusti earlier today.  Was wondering if anyone actually documented how to use any of these...02:20
ayounglooks like the number of config options is slightly larger than the docs say...02:21
dims_ayoung: it would be one of them who should :)02:21
ayoungdims_, but,  even if it were amqp or rabbit, what would I start with?02:22
ayoungdims_, I'm working with packstack which still uses the embedded  nova and neutron specific values for qpid_driver  (or rabbit_)02:23
dims_ayoung: i usually pick what's in devstack, i look at the configuration files in a DSVM CI job02:23
ayoungok...I can start with that02:23
ayoungdims_, you got a link?02:25
*** ngupta has quit IRC02:26
dims_ayoung: example rabbitmq config for nova.conf - http://logs.openstack.org/64/227564/4/check/gate-tempest-dsvm-full/4eac836/logs/etc/nova/nova.conf.txt.gz02:27
ayoungdims_, ok thanks...that works...02:27
ayoungrpc_backend = rabbit  is still global.  I guess I replace that with rpc_backend = amqp.  Where is the URL....02:28
dims_ayoung: neutron - http://logs.openstack.org/64/227564/4/check/gate-tempest-dsvm-neutron-large-ops/009056b/logs/etc/neutron/neutron.conf.txt.gz02:28
dims_hang on let me find if there's a CI job for amqp02:28
*** ngupta_ has quit IRC02:29
*** ngupta has joined #openstack-keystone02:29
*** lhcheng has quit IRC02:29
ayoungrabbit_hosts = 127.0.0.102:30
ayoung   Must be something comparable for amqp...02:30
ayoungdims_, so http://git.openstack.org/cgit/openstack/oslo.messaging/tree/oslo_messaging/_drivers/protocols/amqp/opts.py  seems like it would be tehe set of options, but I don't see something that maps to the URL or host or something02:32
ayoungunless it is server_request_prefix but that seems odd02:33
ayounghttp://git.openstack.org/cgit/openstack/oslo.messaging/tree/oslo_messaging/_drivers/amqp.py  has a coupole more...but no URL..02:33
*** lhcheng has joined #openstack-keystone02:33
*** ChanServ sets mode: +v lhcheng02:33
*** ankita_wagh has joined #openstack-keystone02:34
ayounghttp://git.openstack.org/cgit/openstack/oslo.messaging/tree/oslo_messaging/_drivers/base.py#n23  has conn pool02:34
*** stevemar has joined #openstack-keystone02:36
*** ChanServ sets mode: +o stevemar02:36
ayounghttp://logs.openstack.org/96/204696/1/check/gate-oslo.messaging-dsvm-functional-amqp1-f21/6fae401/logs/etc/nova/nova.conf.txt.gz  has RPC backedn Rabbit... Doesn't seem very functional to me02:38
dims_ayoung: that's not a good one02:39
dims_ayoung: have you seen the devstack plugin for amqp yet? https://github.com/kgiusti/amqp1-devstack/tree/master/devstack02:39
dims_it actually moved in http://git.openstack.org/cgit/openstack/devstack-plugin-amqp1/tree/devstack02:40
ayoungdims_, there is no config of the services in there, though02:40
ayoungdims_, do we not need to set the rpc_driver in each service anymore?  Can they now autodiscover it?02:41
ayoungdims_, scary, isn't it?02:45
dims_ayoung: the right thing to do is get ken and flavio to define a experimental job with devstack+tempest with the qpidd plugin enabled tomorrow and then we can inspect that ci environment02:47
dims_i got to drop off will ping them tomorrow02:47
ayoungdims_, I was working with ken today...will beat him up about this tomorrow...but thanks02:47
dims_cool02:47
*** richm has quit IRC02:48
*** stevemar has quit IRC02:49
*** stevemar has joined #openstack-keystone02:50
*** ChanServ sets mode: +o stevemar02:50
gyeenighty night, y'all, (late) dinner time for me02:52
*** gyee has quit IRC02:52
ayoungdims_, found it:02:53
ayounghttp://git.openstack.org/cgit/openstack/oslo.messaging/tree/oslo_messaging/transport.py#n3802:53
*** stevemar has quit IRC02:54
*** dims_ has quit IRC02:57
ayoungjamielennox, cloud-init continues to reset the /etc/resolv.conf files...03:10
*** davechen has joined #openstack-keystone03:16
openstackgerritLance Bragstad proposed openstack/keystone: Consolidate the fernet provider validate_v3_token()  https://review.openstack.org/19687703:18
jamielennoxayoung: i've notcied that03:18
ayoungjamielennox, we can safely uninstall cloud-init once it's done its work03:18
jamielennoxi think we could override it from network-scripts as well03:18
*** davechen1 has quit IRC03:19
jamielennoxalso it's getting that value from the project configuration03:19
jamielennoxnetwork configuration03:19
jamielennoxso you could set it there i guess, it's just kind of the wrong way about03:19
jamielennoxalso because i'm not sure it is cloud-init as opposed to just network manager doing a dhcp lease03:22
lbragstaddolphm: dstanek morgan thoughts on the comment here - https://review.openstack.org/#/c/196877/25/keystone/token/provider.py03:22
*** stevemar has joined #openstack-keystone03:22
*** ChanServ sets mode: +o stevemar03:22
*** stevemar_ has joined #openstack-keystone03:24
*** ChanServ sets mode: +o stevemar_03:24
dolphmlbragstad: the difference between _validate_token() and validate_token() is the caching boundary03:24
lbragstaddolphm: so we need to have it?03:24
dolphmlbragstad: it's more efficient to cache the result of a single token alone than it is to cache the result of single_token + belongsTo03:24
*** lhcheng has quit IRC03:25
dolphmlbragstad: and besides, belongsTo is a kwarg, so it can't be cached without changing that03:25
lbragstadgotcha03:25
dolphmlbragstad: you're the one that's adding validate_non_persistent_token which is the one that seems weird to me ;) so i can't comment on that03:25
lbragstaddolphm: yeah, I'm just looking for feedback to make it simpler03:26
dolphmlbragstad: the difference in doc strings and method signatures between validate_non_persistent_token and validate_v3_token leaves me scratching my head03:26
lbragstaddolphm: bknudson suggested that we rename validate_v3_token_reference back to validate_v3_token03:27
*** stevemar has quit IRC03:27
dolphmtoken ID vs token_ref and non-persistent implied-v3 vs v3?03:27
*** wwwjfy has quit IRC03:27
dolphmlbragstad: why are we validating token dicts instead of just token strings? what is there to validate?03:28
lbragstaddolphm: you mean validating the token reference?03:28
lbragstaddolphm: I'm not sure I can answer that03:28
*** wwwjfy has joined #openstack-keystone03:28
dolphmlbragstad: i assume it's a reference to a complex object, and that object is a dict?03:28
*** stevemar_ has quit IRC03:28
lbragstaddolphm: yeah, its the reference we pull the sql03:29
lbragstador where ever keystone is storing the tokens03:29
dolphmlbragstad: if it came from sql, it should be valid, no?03:29
morgandolphm: hmm wait let me read the scrollback03:29
*** agireud has joined #openstack-keystone03:29
lbragstaddolphm: well, it still puts it through the expiration checks and stuff...03:30
* dolphm forgets how silly the token table is03:30
morganok03:30
*** lhcheng has joined #openstack-keystone03:30
*** ChanServ sets mode: +v lhcheng03:30
morganso we have to verify things like domain exists03:30
morganproject exists03:30
morganetc03:30
morganetc03:30
morganthats what the bulk is doing03:30
morganfor validate v2/v303:30
dolphmbecause the token table is entirely a blob - right03:31
morganyep03:31
lbragstadmorgan: that's why we pull the token from persistence?03:31
*** lhcheng_ has joined #openstack-keystone03:31
morganlbragstad: pulling from persistence saves *some* of the heavy lifting03:31
*** lhcheng has quit IRC03:31
morganwe don't reconstruct the SC03:31
morganwe don't reconstruct some of ther other icky parts03:31
*** stevemar has joined #openstack-keystone03:31
*** ChanServ sets mode: +o stevemar03:31
morganbut we do validate things exists/should be there03:31
morgandolphm: and we can't use FKs etc.03:32
morganwe *could* make all tokens just look like fernet tokens in the DB (except PKI... but meh)03:32
dolphmha03:32
morganinteresting idea...03:32
morganactually03:32
lbragstadmorgan: so make token validation *always* rebuild everything, like it has to with fernet?03:33
dolphmuse fernet on the backend? lol03:33
morgandolphm: maaaybe?03:33
morgan;)03:33
lbragstadand then we only validate token ID strings... validating a token object/dict wouldn't make sense.03:33
morganlbragstad: so i think step 1 is still only ever "issue" v3 tokens then convert to v203:33
morgani would even go as far as saying we should stop storing v2 tokens and convert "on the fly" as needed (even for PKI) so it really is a shim layer03:34
morganwe could simply use fernet for everything except the PKI token stuff and even that.. we *technically* could just make fernet the workhorse and reconstruct everything each time as needed03:35
morganand then start streamlining the token construction03:35
morgandolphm: iiiiinttterrrrrresting ideas03:35
* morgan also likes thinking that it'll be stevemar's job to tell us "no that is terrible" if it is03:36
* dolphm leaves morgan to his late night ideas03:37
lbragstaddolphm: morgan well, i just needed to rebase that patch and it got me thinking... should be passing now and have current comments addressed03:38
stevemarmorgan: everything is terrible all the time03:38
*** sdake has quit IRC03:38
stevemarlbragstad: dolphm umm, more background?03:40
lbragstadstevemar: I was rebasing https://review.openstack.org/#/c/196877/25/keystone/token/provider.py03:40
lbragstadand I left a comment.03:40
*** sdake has joined #openstack-keystone03:41
stevemarlbragstad: you're gonna end up needed a validate_non_persistent_v2_token03:45
stevemarand validate_non_persistent_v3_token03:45
*** sdake has quit IRC03:46
*** links has joined #openstack-keystone03:53
*** ankita_wagh has quit IRC03:55
*** ankita_wagh has joined #openstack-keystone03:56
*** dims has joined #openstack-keystone03:57
stevemarjamielennox: marekd no takers? https://review.openstack.org/#/c/224993/ :)04:00
stevemardid you want to see proof of it working? :)04:00
jamielennoxstevemar: i guess i trust you04:01
stevemarjamielennox: tricked! it's all broken and undocumented!04:02
*** dims has quit IRC04:03
jamielennoxstevemar: it and everything else04:05
stevemarjamielennox: sad but true04:06
stevemarjamielennox: i can't wait for 2.0.0 of ksc!04:07
stevemarwe're gonna piss off so many people when we remove the CLI04:07
jamielennoxstevemar: i've no idea how we're going to manage that one04:07
stevemarit's going to be fantastic04:07
jamielennoxi thought we'd get a feature branch and quick cut over04:07
jamielennoxbut no, we have to pass it through04:07
*** davechen1 has joined #openstack-keystone04:08
stevemarjamielennox: you referring to your giant patch?04:08
stevemarfeature branches stink04:08
jamielennoxno i won't do it as a giant patch04:08
jamielennoxbut i thought we'd be able to delare a v2 branch04:08
jamielennoxapparently that wsa disallowed and we should do them as normal reviews04:09
jamielennoxask morgan for more details04:09
* morgan hides04:09
morganHEY THIS IS MY ROCK04:09
morganno asking me to come out from under it :P04:09
*** davechen has quit IRC04:10
*** kiran-r has joined #openstack-keystone04:11
*** fawadkhaliq has quit IRC04:12
*** davechen has joined #openstack-keystone04:15
stevemarmorgan: for the liberty-backport-potential tag, did you just create those to boot out some bugs to M?04:16
morganstevemar: yep04:16
morganstevemar: basically if it looked like something that almost landed for liberty04:16
morgani tagged it04:16
stevemarmorgan: okie dokie, that's kosher04:16
morganfeel free to drop the tag if you want04:16
morgan:)04:16
*** davechen1 has quit IRC04:18
*** hidekazu has joined #openstack-keystone04:19
stevemarmorgan: nah its fine04:21
stevemardstanek: around?04:21
*** kiran-r has quit IRC04:22
*** fawadkhaliq has joined #openstack-keystone04:34
*** fawadkhaliq has quit IRC04:35
*** fawadkhaliq has joined #openstack-keystone04:35
*** ayoung has quit IRC04:36
*** links has quit IRC04:36
*** grantbow has quit IRC04:37
*** grantbow has joined #openstack-keystone04:39
*** fawadkhaliq has quit IRC04:41
*** mylu has quit IRC04:46
*** ngupta has quit IRC04:47
*** browne has joined #openstack-keystone04:51
openstackgerritEric Brown proposed openstack/keystone: Multiple URLs may be specified for ldap url  https://review.openstack.org/22864405:02
*** thiagop has quit IRC05:08
*** kfox1111 has quit IRC05:09
*** iurygregory has quit IRC05:10
*** lhcheng_ has quit IRC05:12
openstackgerritMerged openstack/keystoneauth: add openid connect plugins  https://review.openstack.org/22499305:12
*** links has joined #openstack-keystone05:12
*** tellesnobrega is now known as tellesnobrega_af05:22
*** gildub has joined #openstack-keystone05:25
gildubjamielennox, hi - Bring back https://bugs.launchpad.net/keystone/+bug/1475091 to the table05:26
openstackLaunchpad bug 1475091 in Keystone "Missing name field for trusts" [Wishlist,Won't fix]05:26
gildubjamielennox, after trying different approaches, it turns out this is a [BLOCKER] for using trusts in openstack puppet05:27
openstackgerritSteve Martinelli proposed openstack/keystonemiddleware: Move response status check to the call  https://review.openstack.org/22788305:28
jamielennoxgildub: yea, not sure what to do there05:28
gildubjamielennox, bring it to the weekly meeting topics, ayoung wasn't convinced but something needs to be done.05:29
jamielennoxgildub: yea, i see that you need something to add there05:30
jamielennoxand the problem with name and desc05:30
gildubjamielennox, the commit message of https://review.openstack.org/200996 is explicit05:30
*** lhcheng has joined #openstack-keystone05:32
*** ChanServ sets mode: +v lhcheng05:32
gildubjamielennox, when puppet runs as a daemon, which is mostly the case in production, then every time the puppet catalog would be executed, all the trusts declared in the catalog will created (added), an infinity of trusts is going to be there very quickly, this is not acceptable for puppet users.05:32
gildub^ s/will created/will be created/05:33
gildubjamielennox, I'm updating the bug accordingly05:34
openstackgerritSteve Martinelli proposed openstack/keystone: Show v3 endpoints in v2 endpoint list  https://review.openstack.org/21587005:35
jamielennoxstevemar: thoughts ^05:35
stevemarjamielennox: gildub looking at the patch and bug05:37
gildubstevemar, thanks. BTW thanks for pushing review 215870!05:38
*** Nirupama has joined #openstack-keystone05:39
* stevemar goes to see what 215870 is05:39
stevemaroh that one, yeah - i want it in05:39
gildubstevemar, :)05:39
stevemarin liberty, i'll backport it05:40
*** su_zhang has joined #openstack-keystone05:40
*** hrou has quit IRC05:40
stevemargildub: why does puppet need trusts?05:41
*** errr has quit IRC05:41
stevemari'm trying to decide if trusts need to be domain scoped, i don't think they need to be05:41
stevemarsince they should be used to delegate roles between domains, then they should be "above" that, and globally unique named05:42
stevemarlhcheng: you're alive!05:42
*** lsmola has joined #openstack-keystone05:42
lhchenghey stevemar!05:43
lhchengI've picked up my passport today, ready to go for Japan :)05:43
stevemarwoo hoo lhcheng05:43
stevemarlhcheng: i need to bug you about osc reviews when you have a few minutes05:44
lhchengsure, I was just looking at the v2-v3 endpoint patch05:44
stevemarlhcheng: oh yeah, do that instead :)05:45
lhchengthe patch you fixed above.05:45
stevemarthen this patch chain - hehe https://review.openstack.org/#/c/222046/05:45
lhchengyeah this patch is rc potential :)05:45
lhchengwhen do we target to wrap up rc2?05:46
*** mylu has joined #openstack-keystone05:47
lhchengstevemar: perfect timing, I just enabled swift on my devstack :)05:49
jamielennoxstevemar: no we don't want to domain scope trusts05:52
*** mylu has quit IRC05:53
*** errr has joined #openstack-keystone05:54
gildubstevemar, why not having trust in puppet? But a real case need has been driven by heat, which needs the trust created so it can go ahead05:55
gildubstevemar, re  https://review.openstack.org/215870, great looking forward for it.06:01
*** stevemar has quit IRC06:04
*** stevemar has joined #openstack-keystone06:04
*** ChanServ sets mode: +o stevemar06:04
*** stevemar has quit IRC06:08
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Zanata  https://review.openstack.org/22811906:09
*** mflobo has joined #openstack-keystone06:11
*** mflobo has left #openstack-keystone06:11
*** sileht has quit IRC06:17
*** ParsectiX has joined #openstack-keystone06:25
*** sileht has joined #openstack-keystone06:28
*** Nirupama has quit IRC06:32
*** Nirupama has joined #openstack-keystone06:33
*** jaosorior has joined #openstack-keystone06:41
*** GB21 has joined #openstack-keystone06:48
openstackgerritDave Chen proposed openstack/keystone: Using the right format to render the docstring correctly  https://review.openstack.org/22622506:50
*** mylu has joined #openstack-keystone06:50
*** ParsectiX has quit IRC06:54
*** ParsectiX has joined #openstack-keystone06:54
*** mylu has quit IRC06:54
*** su_zhang has quit IRC06:55
*** topol has joined #openstack-keystone06:55
*** ChanServ sets mode: +v topol06:55
*** Nirupama has quit IRC06:56
*** topol has quit IRC07:00
openstackgerritDave Chen proposed openstack/keystone: Using the right format to render the docstring correctly  https://review.openstack.org/22622507:00
*** afazekas_ has joined #openstack-keystone07:01
*** ankita_w_ has joined #openstack-keystone07:03
*** jlvillal has quit IRC07:05
*** ankita_wagh has quit IRC07:06
*** browne has quit IRC07:09
*** roxanagh_ has joined #openstack-keystone07:10
*** pnavarro has joined #openstack-keystone07:12
*** roxanagh_ has quit IRC07:17
*** roxanagh_ has joined #openstack-keystone07:17
*** Nirupama has joined #openstack-keystone07:22
*** urulama has quit IRC07:24
*** roxanagh_ has quit IRC07:24
*** urulama has joined #openstack-keystone07:24
*** roxanagh_ has joined #openstack-keystone07:25
*** henrynash has joined #openstack-keystone07:29
*** ChanServ sets mode: +v henrynash07:29
*** roxanagh_ has quit IRC07:31
*** davechen has left #openstack-keystone07:32
*** Nirupama has quit IRC07:34
openstackgerritHidekazu Nakamura proposed openstack/keystone: Update development environment set up doc  https://review.openstack.org/22302007:38
*** afazekas_ has quit IRC07:40
*** gildub has quit IRC07:48
*** henrynash has quit IRC07:55
*** jvarlamova has joined #openstack-keystone07:55
*** henrynash has joined #openstack-keystone07:55
*** jvarlamova has quit IRC07:55
*** jvarlamova has joined #openstack-keystone07:55
*** ParsectiX has quit IRC08:00
*** fhubik has joined #openstack-keystone08:02
*** jistr has joined #openstack-keystone08:02
*** Nakato has quit IRC08:03
*** lhcheng has quit IRC08:03
*** Nakato has joined #openstack-keystone08:03
*** e0ne has joined #openstack-keystone08:03
*** ankita_w_ has quit IRC08:05
*** ankita_wagh has joined #openstack-keystone08:05
*** ParsectiX has joined #openstack-keystone08:05
*** brad[] has quit IRC08:07
openstackgerritTony Wang proposed openstack/keystone: Show v3 endpoints in v2 endpoint list  https://review.openstack.org/21587008:10
*** ankita_wagh has quit IRC08:15
*** ankita_wagh has joined #openstack-keystone08:15
*** stevemar has joined #openstack-keystone08:16
*** ChanServ sets mode: +o stevemar08:16
*** ankita_wagh has quit IRC08:20
*** markvoelker has quit IRC08:20
*** stevemar has quit IRC08:21
*** brad[] has joined #openstack-keystone08:52
*** agireud has quit IRC08:54
*** ParsectiX has quit IRC08:56
*** henrynash has joined #openstack-keystone08:58
*** ChanServ sets mode: +v henrynash08:58
*** e0ne has quit IRC09:00
*** e0ne has joined #openstack-keystone09:00
*** EinstCrazy has quit IRC09:01
*** ParsectiX has joined #openstack-keystone09:02
*** katkapilatova has joined #openstack-keystone09:03
*** aix has joined #openstack-keystone09:06
*** urulama has quit IRC09:09
*** urulama has joined #openstack-keystone09:09
*** markvoelker has joined #openstack-keystone09:21
*** markvoelker has quit IRC09:26
*** henrynash has quit IRC09:28
*** EinstCrazy has joined #openstack-keystone09:28
*** dims has joined #openstack-keystone09:32
*** dims has quit IRC09:39
openstackgerritDave Chen proposed openstack/keystone: Deprecate local conf in paste-ini  https://review.openstack.org/13412409:40
*** EinstCrazy has quit IRC09:40
*** dims has joined #openstack-keystone09:42
*** marzif has joined #openstack-keystone09:51
*** lhcheng has joined #openstack-keystone09:52
*** ChanServ sets mode: +v lhcheng09:52
*** lhcheng has quit IRC09:57
*** rajesht_ has joined #openstack-keystone09:58
*** topol has joined #openstack-keystone10:01
*** ChanServ sets mode: +v topol10:01
*** fhubik is now known as fhubik_brb10:01
*** rajesht has quit IRC10:01
*** marzif has quit IRC10:03
*** topol has quit IRC10:06
*** EinstCrazy has joined #openstack-keystone10:07
*** jaosorior has quit IRC10:07
*** ParsectiX has quit IRC10:10
*** pnavarro has quit IRC10:18
*** jasondotstar_afk is now known as jasondotstar10:19
*** e0ne has quit IRC10:36
*** mylu has joined #openstack-keystone10:51
*** mylu has quit IRC10:56
*** ParsectiX has joined #openstack-keystone10:59
*** e0ne has joined #openstack-keystone11:18
*** BAKfr has quit IRC11:18
*** EinstCra_ has joined #openstack-keystone11:19
openstackgerritHidekazu Nakamura proposed openstack/keystone: Remove unused get_user_projects()  https://review.openstack.org/22936911:20
*** nisha has joined #openstack-keystone11:20
*** EinstCrazy has quit IRC11:21
*** BAKfr has joined #openstack-keystone11:21
*** pnavarro has joined #openstack-keystone11:22
*** markvoelker has joined #openstack-keystone11:22
*** itlinux has joined #openstack-keystone11:25
*** itlinux has quit IRC11:26
*** itlinux has joined #openstack-keystone11:26
*** markvoelker has quit IRC11:27
*** GB21_ has joined #openstack-keystone11:40
*** lhcheng has joined #openstack-keystone11:41
*** ChanServ sets mode: +v lhcheng11:41
*** gordc has joined #openstack-keystone11:42
*** GB21 has quit IRC11:44
*** lhcheng has quit IRC11:45
*** iurygregory has joined #openstack-keystone11:53
*** GB21_ has quit IRC11:56
*** jaosorior has joined #openstack-keystone11:59
*** fhubik_brb is now known as fhubik11:59
*** Ephur has joined #openstack-keystone12:00
*** markvoelker has joined #openstack-keystone12:03
*** lhcheng has joined #openstack-keystone12:05
*** ChanServ sets mode: +v lhcheng12:05
*** htruta` is now known as htruta12:05
openstackgerritDave Chen proposed openstack/keystonemiddleware: update middlewarearchitecture.rst  https://review.openstack.org/21916212:06
*** lhcheng has quit IRC12:10
*** tellesnobrega_af is now known as tellesnobrega12:12
*** raildo-afk is now known as raildo12:12
openstackgerritDave Chen proposed openstack/keystonemiddleware: update middlewarearchitecture.rst  https://review.openstack.org/21916212:19
*** pnavarro has quit IRC12:20
*** aix has quit IRC12:22
*** pnavarro has joined #openstack-keystone12:22
*** pnavarro has quit IRC12:34
*** amakarov_away is now known as amakarov12:39
*** marzif has joined #openstack-keystone12:43
openstackgerritMarek Denis proposed openstack/keystone: Skip rows with empty remote_ids  https://review.openstack.org/20656112:44
*** pnavarro has joined #openstack-keystone12:47
*** richm has joined #openstack-keystone12:51
openstackgerritAlexander Makarov proposed openstack/keystonemiddleware: Move response status check to the call  https://review.openstack.org/22788312:51
amakarovjamielennox, hi! Please, update your +2, if you don't mind ^^12:52
*** edmondsw has joined #openstack-keystone12:54
*** aix has joined #openstack-keystone12:55
*** tellesnobrega is now known as tellesnobrega_af12:59
*** pauloewerton has joined #openstack-keystone13:01
openstackgerritMarek Denis proposed openstack/keystoneauth-saml2: Standardize federated auth token scoping  https://review.openstack.org/17722713:02
*** GB21 has joined #openstack-keystone13:11
*** raildo is now known as raildo-afk13:12
*** hrou has joined #openstack-keystone13:12
*** geoffarnold has joined #openstack-keystone13:14
*** jecarey has joined #openstack-keystone13:14
*** geoffarn_ has joined #openstack-keystone13:15
*** nisha has quit IRC13:17
*** geoffarnold has quit IRC13:18
*** dsirrine has joined #openstack-keystone13:23
openstackgerritRajesh Tailor proposed openstack/keystone: Fix order of arguments in assertDictEqual  https://review.openstack.org/22942113:24
openstackgerritLance Bragstad proposed openstack/keystone: Consolidate the fernet provider validate_v3_token()  https://review.openstack.org/19687713:27
*** doug-fish has quit IRC13:27
*** ayoung has joined #openstack-keystone13:28
*** ChanServ sets mode: +v ayoung13:28
openstackgerritLance Bragstad proposed openstack/keystone: Consolidate the fernet provider issue_v2_token()  https://review.openstack.org/19764713:30
*** su_zhang has joined #openstack-keystone13:30
*** alejandrito has joined #openstack-keystone13:30
openstackgerritHenrique Truta proposed openstack/keystone: List projects filtering by is_domain flag  https://review.openstack.org/15839813:30
openstackgerritHenrique Truta proposed openstack/keystone: Remove domain table references  https://review.openstack.org/16593613:31
openstackgerritHenrique Truta proposed openstack/keystone: Bye Bye Domain Table  https://review.openstack.org/16185413:31
openstackgerritHenrique Truta proposed openstack/keystone: Add is_domain in token response  https://review.openstack.org/19733113:31
openstackgerritHenrique Truta proposed openstack/keystone: Change policy to comply with is_domain in token  https://review.openstack.org/20606313:31
*** raildo-afk is now known as raildo13:33
*** jsavak has joined #openstack-keystone13:33
*** su_zhang has quit IRC13:34
*** urulama has quit IRC13:35
*** geoffarn_ has quit IRC13:35
*** urulama has joined #openstack-keystone13:35
*** geoffarnold has joined #openstack-keystone13:35
*** tellesnobrega_af is now known as tellesnobrega13:37
*** marzif has quit IRC13:43
*** doug-fish has joined #openstack-keystone13:43
*** cjschaef has joined #openstack-keystone13:44
htrutahey bknudson, are you around? regarding the comment you've made at https://review.openstack.org/#/c/215167/7/keystone/resource/backends/ldap.py13:45
*** BAKfr has quit IRC13:45
bknudsonhtruta: I am around for a few minutes13:45
*** ngupta has joined #openstack-keystone13:46
htrutabknudson: ok... we've added the pragma no cover because you suggested here: https://review.openstack.org/#/c/213273/7/keystone/resource/backends/ldap.py13:47
*** doug-fish has quit IRC13:47
htrutabknudson: should we keep it or not?13:47
*** doug-fish has joined #openstack-keystone13:48
bknudsonhtruta: I think you should write a unit test to cover that line rather than ignore it from the coverage report13:48
*** su_zhang has joined #openstack-keystone13:48
bknudsonjust call the method with a ref that's not a dict or list.13:48
*** dims has quit IRC13:49
*** dims has joined #openstack-keystone13:49
htrutabknudson: ok. can I call it directly from the test? or is it from a backend call?13:49
bknudsonhtruta: you can call whatever you want in a unit test.13:50
htrutabknudson: ok. I'll do that and try to split the patch (more)13:50
htrutathanks13:50
*** doug-fish has quit IRC13:52
*** doug-fish has joined #openstack-keystone13:54
*** zzzeek has joined #openstack-keystone13:54
*** stevemar has joined #openstack-keystone13:56
*** ChanServ sets mode: +o stevemar13:56
*** geoffarnold has quit IRC13:56
*** geoffarnold has joined #openstack-keystone13:57
*** nisha_ has joined #openstack-keystone13:57
*** sigmavirus24_awa is now known as sigmavirus2413:59
*** LukeHinds has joined #openstack-keystone14:01
stevemarjamielennox: thoughts on the name of keystoneauth_saml2? should it be keystoneauth-saml214:01
*** topol has joined #openstack-keystone14:03
*** ChanServ sets mode: +v topol14:03
*** BAKfr has joined #openstack-keystone14:05
*** jsavak has quit IRC14:06
*** jsavak has joined #openstack-keystone14:07
*** itlinux has quit IRC14:08
marekddstanek: Hi, I fixed the migration script and added a test for that: https://review.openstack.org/#/c/20656114:10
dstanekmarekd: great thx14:10
*** j_king has joined #openstack-keystone14:12
*** ParsectiX has quit IRC14:13
stevemarmarekd: nice add :)14:14
*** roxanagh_ has joined #openstack-keystone14:15
*** pnavarro has quit IRC14:16
marekdstevemar: thank you, sir.14:16
marekd:)14:17
marekdnow go ahead and review, please :-)14:17
*** j_king has left #openstack-keystone14:17
amakarovstevemar, hi! I've updated https://review.openstack.org/#/c/227883/ - would you please update your +2 there before anybody merge something breaking the tests? :)14:17
*** geoffarnold has quit IRC14:17
*** geoffarnold has joined #openstack-keystone14:18
*** jsavak has quit IRC14:20
*** jsavak has joined #openstack-keystone14:21
stevemaramakarov: will do sir!14:22
*** roxanagh_ has quit IRC14:24
*** panbalag has joined #openstack-keystone14:25
*** urulama has quit IRC14:25
*** panbalag has left #openstack-keystone14:25
*** urulama has joined #openstack-keystone14:25
stevemaramakarov: +2!14:26
amakarovstevemar, yay!14:26
marekdamakarov: and anther +2 from me.14:26
amakarovmarekd, stevemar: thank you, honoured colleagues! :)14:29
*** pnavarro has joined #openstack-keystone14:30
*** pnavarro has quit IRC14:31
*** pnavarro has joined #openstack-keystone14:31
stevemaramakarov: <314:32
marekdhehe14:32
*** su_zhang has quit IRC14:34
bknudsonstevemar: I don't think you can import keystoneauth-saml214:34
marekdbknudson: import where?14:34
bknudsonin a python script14:35
*** doug-fish has quit IRC14:35
*** geoffarnold is now known as geoffarnoldX14:35
marekdbknudson: a little bit or context?14:35
marekdbknudson: ksa-saml2 doesn't have patch merged that depends on ksa14:36
bknudsonif you "import keystoneauth-saml2", "keystoneauth-saml2.plugin" it's not going to work14:36
marekdbecause it should be "import keystoneauth_saml2"14:36
bknudsonmarekd: that would work... stevemar was wondering why it's not keystoneauth-saml2 instead.14:37
stevemarbknudson: yeah, i realized that this morning14:38
stevemarwhich is why i approved it now14:38
marekdbknudson: let me double check but i am pretty convinced i was already using ksa-saml2 in my scripts.14:38
*** geoffarnoldX has quit IRC14:38
stevemarmarekd: nah you can't, i think14:38
marekdhttps://review.openstack.org/#/c/186854/ finally!14:38
stevemarbknudson: the project itself is keystoneauth-saml2, just not the top level dir14:39
openstackgerritMerged openstack/keystoneauth-saml2: Depend on keystoneauth  https://review.openstack.org/18685414:39
stevemarthat makes sense, since it's the same as the oslo bits, like oslo_log14:39
*** geoffarnold has joined #openstack-keystone14:39
bknudsonin oslo it's oslo.log -> oslo_log14:39
marekdstevemar: bknudson ++14:40
bknudsonwe also have python-keystoneclient -> keystoneclient...14:40
stevemaryep14:40
bknudsonI think that's in setup.cfg?14:40
*** su_zhang has joined #openstack-keystone14:40
*** agireud has joined #openstack-keystone14:41
*** slberger has joined #openstack-keystone14:41
*** doug-fish has joined #openstack-keystone14:41
*** su_zhang has quit IRC14:42
*** roxanagh_ has joined #openstack-keystone14:45
*** doug-fish has quit IRC14:46
*** itlinux has joined #openstack-keystone14:46
*** doug-fish has joined #openstack-keystone14:47
marekdbknudson: https://github.com/openstack/keystoneauth-saml2/blob/master/setup.cfg#L2314:49
marekdprobably (?)14:50
*** csoukup has joined #openstack-keystone14:51
*** doug-fish has quit IRC14:51
bknudsonmarekd: I think that's it.14:52
*** phalmos has joined #openstack-keystone14:52
openstackgerritMerged openstack/keystone-specs: Clarify documentation about scope  https://review.openstack.org/22479214:53
*** kiran-r has joined #openstack-keystone14:55
*** doug-fish has joined #openstack-keystone15:00
*** geoffarnold has quit IRC15:00
*** geoffarn_ has joined #openstack-keystone15:01
*** r-daneel has joined #openstack-keystone15:01
*** diazjf has joined #openstack-keystone15:01
*** nisha_ has quit IRC15:01
*** fhubik is now known as fhubik_brb15:02
*** pnavarro has quit IRC15:03
*** jsavak has quit IRC15:05
*** jsavak has joined #openstack-keystone15:05
*** browne has joined #openstack-keystone15:06
*** jistr has quit IRC15:07
lbragstadjamielennox: what kind of error do you see when you don't pass in PBR_VERSION - https://review.openstack.org/#/c/224407/1 ?15:07
*** browne has quit IRC15:10
*** sdake has joined #openstack-keystone15:10
*** phalmos has quit IRC15:16
*** dims_ has joined #openstack-keystone15:16
*** kiran-r has quit IRC15:17
*** fhubik_brb is now known as fhubik15:19
*** kiran-r has joined #openstack-keystone15:20
*** dims has quit IRC15:20
*** browne has joined #openstack-keystone15:20
*** geoffarn_ has quit IRC15:21
*** links has quit IRC15:21
*** geoffarnold has joined #openstack-keystone15:22
*** katkapilatova has left #openstack-keystone15:22
openstackgerritJulien Danjou proposed openstack/keystone: wsgi: fix base_url finding  https://review.openstack.org/22646415:22
*** itlinux has quit IRC15:23
*** ChanServ sets mode: +v marekd15:29
*** jsavak has quit IRC15:30
*** jsavak has joined #openstack-keystone15:31
*** BAKfr has quit IRC15:36
*** akanksha_ has joined #openstack-keystone15:40
*** BAKfr has joined #openstack-keystone15:41
*** marzif has joined #openstack-keystone15:41
stevemardstanek: my most stanek of friends, i had a question about https://review.openstack.org/#/c/167675/15:41
*** Sam-I-Am has joined #openstack-keystone15:42
Sam-I-Amhowdy15:42
*** jecarey_ has joined #openstack-keystone15:43
*** cjschaef_ has joined #openstack-keystone15:43
*** geoffarn_ has joined #openstack-keystone15:43
Sam-I-Amworking on updating the install guide for liberty and running into some v2/v3 bootstrapping problems15:43
*** doug-fis_ has joined #openstack-keystone15:43
*** geoffarnold has quit IRC15:43
*** jecarey__ has joined #openstack-keystone15:44
*** jecarey has quit IRC15:44
*** cjschaef__ has joined #openstack-keystone15:44
*** cjschaef has quit IRC15:44
*** doug-fi__ has joined #openstack-keystone15:44
dstanekstevemar: ok, i'll have a look see15:44
*** roxanagh_ has quit IRC15:44
stevemardstanek: oh i didn't write anything out yet, just wanted to better understand it15:45
*** roxanagh_ has joined #openstack-keystone15:45
dstanekah, ok15:45
Sam-I-Amdstanek: moo.15:45
*** doug-fish has quit IRC15:46
*** doug-fis_ has quit IRC15:48
*** cjschaef_ has quit IRC15:48
*** jecarey_ has quit IRC15:48
Sam-I-Amanyone?15:48
Sam-I-Amdstanek: pretty sure there's some kind of bug here15:50
dstanekSam-I-Am: what's up?15:50
Sam-I-Amtrying to bootstrap keystone ... service, endpoints, initial project/user15:51
Sam-I-Amhistorically, its been OS_URL=http://blah:35357/v2.0 and OS_TOKEN=admin (or whatever is in keystone.conf)15:51
Sam-I-Amall of this uses v215:51
Sam-I-Amwhile working on putting more v3 into the install guide, i found out that the openstack client changes the command line arguments for endpoint creation depending on whether you're using v2 or v3 (which is awesome)15:52
Sam-I-Ami prefer to keep some consistency for our users, so showing them how to create endpoints one way and then changing it will confuse them and cause people to file bugs15:52
Sam-I-Amso, i tried to use OS_URL=http://blah:35357/v315:53
*** BAKfr has quit IRC15:53
Sam-I-Amthat alone doesnt work, and also requires OS_IDENTITY_API_VERSION=315:53
Sam-I-Amso far so good.. i can create a service and endpoints15:53
Sam-I-Amhowever, if i try to create a user, i get 401 auth required15:53
Sam-I-Ameven though i'm using auth type token_endpoint15:54
dims_stevemar: hmm, seems like https://review.openstack.org/#/c/221738/ did not make it into a python-keystoneclient release yet.15:54
dims_stevemar: that will help with this nova review - https://review.openstack.org/#/c/229368/15:54
Sam-I-Amso i'm not sure why i'm getting asked for auth when i'm bypassing it in bootstrap mode15:54
dstanekSam-I-Am: so you can create services and endpoints, but not users?15:55
Sam-I-Amif i try to use /v2.0 with os_identity_api_version=3, i can create users but not endpoints/services15:55
*** BAKfr has joined #openstack-keystone15:55
Sam-I-Amyeah15:55
*** fhubik has quit IRC15:55
dstanekSam-I-Am: do you have any debug logging going on to see what is happening? ideally from both the server and client15:56
Sam-I-Amdstanek: sure, hold on15:56
*** aix has quit IRC15:57
openstackgerritMerged openstack/keystonemiddleware: Move response status check to the call  https://review.openstack.org/22788315:57
Sam-I-Amdstanek: http://paste.openstack.org/show/q5vVpZ9FbnSYdCwgMpub/15:58
Sam-I-Amthats the client debug output15:58
*** mylu has joined #openstack-keystone15:59
*** nisha_ has joined #openstack-keystone15:59
dstanekSam-I-Am: almost seems as if it isn't really passing the token16:01
Sam-I-Amyeah16:01
Sam-I-Amlets look at the debug for service create...16:02
*** david8hu has quit IRC16:02
Sam-I-Amdstanek: http://paste.openstack.org/show/j8WOUOTeBQkwz1cGhz9f/16:03
*** lhcheng has joined #openstack-keystone16:03
*** ChanServ sets mode: +v lhcheng16:03
*** diazjf has quit IRC16:04
*** geoffarn_ has quit IRC16:04
*** diazjf has joined #openstack-keystone16:04
stevemardims_: hmmm?16:04
*** marzif has quit IRC16:04
*** geoffarnold has joined #openstack-keystone16:04
*** tonytan4ever has joined #openstack-keystone16:06
stevemardims_: okay, is this needed for liberty?16:06
*** dims_ has quit IRC16:06
stevemaror are you just asking for a ksc refresh for M?16:06
Sam-I-Amdstanek: http://paste.openstack.org/show/JwEwKKXcYaiCAf9DKPsG/16:07
Sam-I-Amdstanek: thats keystone server debug16:07
*** mylu has quit IRC16:07
*** jlvillal has joined #openstack-keystone16:10
*** raildo is now known as raildo-afk16:14
*** phalmos has joined #openstack-keystone16:14
*** gyee has joined #openstack-keystone16:22
*** ChanServ sets mode: +v gyee16:22
*** sweetjeebus has joined #openstack-keystone16:23
sweetjeebusHi all16:23
openstackgerritBrant Knudson proposed openstack/keystone: Documentation for other services  https://review.openstack.org/20480116:23
dstanekSam-I-Am: hmmm...are you providing a domain_id for the user you want to create?16:23
sweetjeebusI was sent here by one Mr. Kingshott to speak with #mdrnstrm, but I don't see him online16:24
sweetjeebusMaybe some of you have experience with my questions, though? Upgrading keystone.16:25
*** ankita_wagh has joined #openstack-keystone16:25
*** geoffarnold has quit IRC16:25
dstaneksweetjeebus: he's morgan in IRC16:25
sweetjeebusHey, cool. Thanks16:25
Sam-I-Amdstanek: no16:25
*** ankita_wagh has quit IRC16:25
*** geoffarnold has joined #openstack-keystone16:25
dstaneksweetjeebus: you should just ask your question and if somebody knows hopefully they'll respond16:26
Sam-I-Amlemmie try that16:26
sweetjeebus@morgan, are you here?16:26
dstaneksweetjeebus: not everyone's in the same timezone so you may have to wait a bit depending on the question16:26
*** ankita_wagh has joined #openstack-keystone16:26
sweetjeebusyeah, I understand16:26
sweetjeebusSo... maybe someone can answer this. I'm wondering about backwards compatibility of keystone client to keystone-db. If I'm currently running icehouse, can I upgrade the keystone-cluster to kilo and expect it to work without upgrading the db yet (for uptime purposes, I want to get my keystone servers upgraded and leave the db running).16:28
sweetjeebussorry, I said 'keystone client', but I mean 'keystone server'16:29
Sam-I-Amdstanek: --os-domain-name or other?16:29
Sam-I-Amdstanek: the docs are terribad16:29
Sam-I-Amas in, nonexistant as to the variants of domain name16:29
*** raildo-afk is now known as raildo16:30
*** doug-fi__ is now known as doug-fish16:30
sweetjeebusI'm about to try this upgrade, but I figured I'd ask about peoples' experience first.16:30
dstanekSam-I-Am: i think it's --domain, but i'd have to go look16:30
dstaneksweetjeebus: my guess is no, since we don't to anything to make sure new code works with old schema16:31
Sam-I-Amdstanek: it doesnt understand --domain16:31
Sam-I-Amdstanek: so far all combinations return a 40116:31
sweetjeebusha. That's about what I expected16:31
sweetjeebus+dstanek: thanks. I'll update you with the results of any testing I perform.16:32
dstanekSam-I-Am: hmm... i would have guessed 'openstack user create dstanek --password secrete --domain default' to work is the OS_TOKEN is set16:32
dstaneks/is the/if the/16:32
Sam-I-Amit does not16:33
*** dims_ has joined #openstack-keystone16:33
*** su_zhang has joined #openstack-keystone16:33
Sam-I-Amalso, they moved the username to the end of the argument list :/16:34
Sam-I-Ambut thats not the problem here16:34
dstanekwhat's the server log look like since you specified the domain?16:34
*** stevemar has quit IRC16:35
Sam-I-Amwell, --domain is not a valid switch, so we need to figure out which variant to use16:35
Sam-I-Ami thought os_default_domain, but that defaults to 'default' which is there already16:35
dstanekwhat version of openstack client are you using?16:35
Sam-I-Am1.716:35
Sam-I-Amwhich iirc is the latest tag16:36
*** henrynash has joined #openstack-keystone16:38
*** ChanServ sets mode: +v henrynash16:38
openstackgerritTony Wang proposed openstack/keystone: Show v3 endpoints in v2 endpoint list  https://review.openstack.org/21587016:39
Sam-I-Amdstanek: http://paste.openstack.org/show/Z9NSXopYgYoIM1txbMcN/16:40
Sam-I-Amdstanek: that includes the command i used with all possible domain flags set16:40
*** _cjones_ has joined #openstack-keystone16:42
*** _cjones_ has quit IRC16:42
*** _cjones_ has joined #openstack-keystone16:42
odyssey4meSam-I-Am do you perhaps have any OS_ env vars set?16:43
odyssey4meas I recall there are known conflicts16:43
*** nicodemos has joined #openstack-keystone16:43
openstackgerritMerged openstack/keystoneauth: Fix doc session example  https://review.openstack.org/22626216:44
*** lsmola has quit IRC16:44
dstanekSam-I-Am: hmm...that's strange - this is what i was remembering when i gave you that command  http://git.openstack.org/cgit/openstack-dev/devstack/tree/functions-common#n77316:44
dstanekSam-I-Am: that's how devstack sets it up (i think with OS_TOKEN)16:45
dstanekSam-I-Am: i dig deeper and see if i can reproduce16:45
Sam-I-Amhmm16:46
dstanekSam-I-Am: ok, got a new devstack setup so i can try this out16:48
Sam-I-Amdstanek: thats interesting... putting '--domain default' at the end seems to work16:49
Sam-I-Amdstanek: yet '--domain' is not documented anywhere16:49
Sam-I-Amincluding the help16:49
dstanekSam-I-Am: if it was documented then it would be easy. why would we want that?16:50
*** devlaps has joined #openstack-keystone16:50
dstanekSam-I-Am: maybe it has to be after the --os-* stuff16:50
Sam-I-Amdstanek: i am using env vars for the OS_ stuff16:51
Sam-I-Amso my command is just user create blah --password blah --domain default16:51
Sam-I-Ami wonder why --domain is not documented16:51
*** harlowja has quit IRC16:52
Sam-I-Amdstanek: well, at least we figured out how to make it work16:53
Sam-I-Amnot sure why passing env or --os-* arguments dont work in this specific case (they do once keystone is bootstrapped)16:53
*** flaper87 has quit IRC16:55
*** flaper87 has joined #openstack-keystone16:55
*** phalmos has quit IRC16:55
Sam-I-Amdstanek: time to try walking through all of the other bootstrapping steps to see anything else breaks16:56
*** henrynash has quit IRC17:01
*** roxanagh_ has quit IRC17:04
*** geoffarnold has quit IRC17:06
*** geoffarnold has joined #openstack-keystone17:07
*** stevemar has joined #openstack-keystone17:07
*** ChanServ sets mode: +o stevemar17:07
*** ankita_wagh has quit IRC17:11
*** e0ne has quit IRC17:14
*** LukeHinds has quit IRC17:15
*** aix has joined #openstack-keystone17:19
openstackgerritHenrique Truta proposed openstack/keystone: Create tests for set_default_is_domain in LDAP  https://review.openstack.org/22953617:20
*** jsavak has quit IRC17:23
*** jsavak has joined #openstack-keystone17:24
*** stevemar has quit IRC17:24
*** roxanagh_ has joined #openstack-keystone17:26
*** stevemar has joined #openstack-keystone17:26
*** ChanServ sets mode: +o stevemar17:26
*** ankita_wagh has joined #openstack-keystone17:27
*** jsavak has quit IRC17:28
*** geoffarn_ has joined #openstack-keystone17:28
*** geoffarnold has quit IRC17:28
*** roxanag__ has joined #openstack-keystone17:28
*** jsavak has joined #openstack-keystone17:29
*** roxanagh_ has quit IRC17:29
stevemardolphm: ayoung add a name to trusts? oui ou non?17:30
stevemari'm thinking it shouldn't be bad because we don't need to domain scope them17:31
openstackgerritMerged openstack/keystone: Update bandit blacklist_calls config  https://review.openstack.org/22532717:31
ayoungstevemar, nope17:32
stevemarayoung: esplain!17:32
ayoungstevemar, there is so much more we should do on the delegation front, lets focus on the real issue17:32
ayoungstevemar, see amakarov 's unified delegation spec17:32
ayoungstevemar, " don't need to domain scope" does not make sense...what do you mean by that?17:33
stevemarayoung: sorry, i picked a poor time for this conversation17:33
ayoungthere is no good time as PTL17:33
stevemari might have to run away for an hour17:34
stevemarmeh17:34
ayoungstevemar, https://review.openstack.org/#/c/189816/  read that first17:34
stevemarayoung: so, i figured trusts could be named, and the names could be globally unique, like roles17:34
ayoungand then we can discuss17:34
ayoungstevemar, you mean something like a trust named "all_users_trust_nova_to_fetch_images"17:35
ayounglike, use the name as a template?17:35
stevemarayoung: yes, when creating trust it should have a name field, the name can be "all_users_trust_nova_to..."17:36
*** diazjf has quit IRC17:36
stevemarapparently it's important for puppet, they are unable to do stuff and things without it very nicely17:37
stevemarhttps://bugs.launchpad.net/keystone/+bug/147509117:37
openstackLaunchpad bug 1475091 in Keystone "Missing name field for trusts" [Wishlist,Won't fix]17:37
ayoungstevemar, So instead of using a trust_id to execure the trust by id they need a name?17:37
ayoungstevemar, ah...this17:37
ayoungyeah, tell themn to stuff it17:37
stevemarayoung: that's not diplomatic :)17:38
ayoungI cannot flippuing stand puppet17:38
ayoungits like in another languaege or something17:38
openstackgerritMerged openstack/keystone: Fix order of arguments in assertDictEqual  https://review.openstack.org/22942117:38
ayoungnah...I understand the concern:  they don;'t want to have to read a value off of Keystone after they create somethign in order to be able to use it...its the same deal as endpoint ids17:39
*** roxanag__ has quit IRC17:39
*** ngupta has quit IRC17:39
ayoungstevemar,  and if there is a trust already created with that name?  Puppet is hosed17:40
ayoungthen they will want namespaces for trusts17:40
ayoungwe can do all that crap17:40
*** ngupta has joined #openstack-keystone17:41
amakarovayoung, about delegations: do you have any suggestion how to handle hierarchical projects (and roles)?17:45
*** nisha__ has joined #openstack-keystone17:45
amakarovayoung, Does it mean, that having role delegated on root project gives that role on the leaf project?17:46
bknudsonmorgan: do you know if dogpile.cache supports atomic operations (like memcache has incr for ints).17:46
*** nisha__ has quit IRC17:46
ayoungamakarov, that should be based on the same rules as HMT already proscribes.  One reason I called my thing implied rulesinstead of hierarchical was to avoid a naming clash there17:47
bknudsonI'm looking at the nova review to switch to oslo.cache -- https://review.openstack.org/#/c/203049/24/nova/api/ec2/__init__.py17:47
*** nisha__ has joined #openstack-keystone17:47
raildoamakarov, we handle with this using inherited roles... this is not enough for this delegate issue?17:47
ayoungamakarov, so, the role assignment is either for the project specified , the child nodes, or both17:47
ayoungraildo, is ^^ strictly speaking correct?17:47
dolphmlbragstad: have a link to your tempest patch?17:48
*** nisha_ has quit IRC17:48
amakarovayoung, this information supposed to be in the delegation, right?17:48
lbragstaddolphm: which patch?17:48
raildoayoung, you're right17:49
*** geoffarn_ has quit IRC17:49
*** nisha__ has quit IRC17:49
*** geoffarnold has joined #openstack-keystone17:49
amakarovraildo, please see https://review.openstack.org/#/c/198418/ - does it fit for HMT?17:49
*** nisha_ has joined #openstack-keystone17:50
raildoamakarov, looking17:50
ayoungamakarov, it should work for HTM role assignments.17:50
ayoungHMT17:50
amakarovraildo, ayoung I need to know if I can rely on this structure in delegations17:50
*** roxanagh_ has joined #openstack-keystone17:51
ayoungamakarov, projects are strictly hierarchical.  Your materialed path approach should uniquely identify the path.  Plus, the hierarchy is pretty rigid:  we don't allow moving projects around, so simpler case than you have addressed17:51
lbragstaddolphm: there is this, but it's already merged - https://review.openstack.org/#/c/220272/117:53
openstackgerritHenrique Truta proposed openstack/keystone: Add test case passing is_domain flag as False  https://review.openstack.org/22954917:53
*** syin has joined #openstack-keystone17:53
*** diazjf has joined #openstack-keystone17:53
amakarovayoung, I still haven't reviewed implied roles, are you implementing a network of roles?17:55
dolphmlbragstad: so should this pass without a depends-on? https://review.openstack.org/#/c/195780/17:55
ayoungamakarov, yes17:56
lbragstaddolphm: i'm not sure if it will pass,17:56
raildoamakarov, I think that I understand what ayoung are trying to say.... your solution are correct, but since we prohibit any updates in the hierarchy we can make this patch simpler...17:56
ayoungdolphm, did you see the spec I posted on Catalog Scoped roles?  I tried to extrapolate from what you had said in a previous conversation17:56
lbragstaddolphm: there is nothing proposed to keystone that will correct the issues exposed by your testing patch. There also isn't anything proposed to tempest for waits17:57
amakarovayoung, how do you suggest to traverse roles? Recursion?17:57
ayounghttps://review.openstack.org/#/c/228477/  dolphm when you get a chance17:57
*** stevemar has quit IRC17:57
dolphmayoung: i havent reviewed specs in a while17:57
ayoungamakarov, sort of17:57
*** stevemar has joined #openstack-keystone17:57
*** ChanServ sets mode: +o stevemar17:57
ayoungdolphm, we discussed the "project was deleted, resource is still around" issue and you said it felt like it should be a service admin's job to fix that17:58
amakarovraildo, it's a textbook tree implementation, actually :) It can be considered atomic17:58
dolphmayoung: no, i said it should be the service's job to listen for notifications17:59
ayoungdolphm, you said both.17:59
ayoungdolphm, there was the fact that we cannot guarantee deliver of the notifications.  THis was the backup for that17:59
dstanekayoung: dolphm: this is why ESBs were invented18:00
*** doug-fis_ has joined #openstack-keystone18:00
dolphm++ considering services arent listening today, there's not a problem to solve. but when there is, fix the message bus.18:01
ayoungdstanek, yeah, and we should pursue that as well, but we'll have an ice age here before all of the project get notifications handled correctly.  We are talking guaranteed delivery to a topic to all listeners, and that is just ....18:01
*** stevemar has quit IRC18:01
dolphmayoung: and you think they'll implement the "backup" solution first?18:02
ayoungdolphm, but this addresses a wider array of issues anyway.  For example, the Nova call to add a hypervisor is not scoped to a project18:02
ayoungdolphm, I think modifying policy is simpler than implementing a message listener18:02
dolphmtenant-less service-scoped tokens has a bp18:02
ayoungdolphm, so, this is the role-assignment piece to support that.18:04
*** doug-fish has quit IRC18:04
*** doug-fis_ has quit IRC18:04
dolphmlol18:05
ayoungdolphm, you know what it is called?  I'm not going to continue this if it is at cross purposes with another effort.  I'd rather see else is being proposed.18:08
dolphmi think we agree that it's a pain for tokens to explicitly convey authorization, but i'm not a fan of adding way more complexity as a solution18:09
*** geoffarnold has quit IRC18:10
*** geoffarnold has joined #openstack-keystone18:11
ayoungdolphm, who's idea was it to have roles scoped to projects in the first place?18:12
*** harlowja has joined #openstack-keystone18:13
*** e0ne has joined #openstack-keystone18:13
*** doug-fish has joined #openstack-keystone18:13
*** su_zhang has quit IRC18:15
dolphmayoung: i think that part makes sense - but it's the tokens scoped to a project that introduces all sorts of problems18:15
dolphmif tokens only conveyed identity and the user was free to authenticate themselves in the context of any project, then it'd be up to keystone to provide the authorization in that context, if any18:16
*** openstackgerrit has quit IRC18:16
dolphmso identity + tenant ID in the URL would suddenly make sense18:16
dolphmor identity + like an X-Project header of some kind specified by the client18:17
*** openstackgerrit has joined #openstack-keystone18:17
ayoungdolphm, if that were the case, we really wouldn't need tokens, either.  They would be optional for people that didn't want, say SAML18:17
ayoungor some other stnadard authentication mechanism18:17
dolphmright, saml would work too, it'd just be a very heavy as a general solution18:17
ayoungdolphm, you could always do password direct to Nova for an all-in-one deployment, the smaller side.18:18
*** phalmos has joined #openstack-keystone18:18
dolphmi'd rather move towards signature based requests than sending passwords in headers, but sure lol18:19
ayoungKerberos or X509 for the enterprise.   Tokens make sense for a very specific type of deployment18:19
ayoungdolphm, signature based would work for CLI18:19
dolphm? it works for http requests regardless of the interface or agent18:19
ayoungnot certain what the Horizon story would be there, but I guess Horizon could sign for the users.18:19
ayoungBrowser based crypto is ... uneven18:20
ayoungdolphm, I'd love it if we could build something base on code signing from the Browser.  Do you think it is a reality?18:20
dstanekayoung: that would mean the browser would be crafting the request to the backend services, right? why would you want that?18:21
ayoungdstanek, authentication.  If My private key signed the message, it came from me.  Period18:22
dolphmdstanek: that's what reach does18:22
dolphmdstanek: it's also the model most modern web apps use, including, say, facebook18:22
dstanekdolphm: so when i'm in reach it's actually formulating the http calls and signing them?18:23
*** e0ne has quit IRC18:23
ayoungwhat is reach?18:23
dolphmayoung: rackspace public cloud's version of horizon, which predates horizon18:24
dolphmdstanek: not signing, but yes18:25
ayoungwe can do client certs today.  Its not quite the same as a signed request, as the crypto is done in channel.  It means that if I call nova boot, Nova can authenticate me, but the call from nova to glance is unauthenticated. If GLance trusts nova, this is probably OK,  so long as we could have nova make the call also using a client cert, and glancewas told "Nova can impersonatye people for fetching images"18:26
dstanekhmm....i can't seem to find any API urls, only seems to build proxy urls18:26
*** roxanagh_ has quit IRC18:26
ayoungI  know Mozilla was working on a broader set of Crypo tools, but I don't see them,18:26
openstackgerritTom Cocozzello proposed openstack/keystone: Deprecate httpd/keystone.py  https://review.openstack.org/22197518:26
ayounghttps://developer.mozilla.org/en-US/docs/Archive/Security/Introduction_to_Public-Key_Cryptography18:26
ayoungWow that is bright18:27
dolphmayoung: there aren't many examples of request signing in javascript... but i found this one https://opensocial.atlassian.net/wiki/display/OSREF/Introduction+To+Signed+Requests18:27
ayoungdolphm, be careful...there are some JS based signing libraries out there, but they are doing centralized key management...which is not secure18:27
ayoungIts not a language thing so much as it needs to come from the users platform.18:28
dolphmayoung: what does centralized key management have to do with the security of a javscript library?18:28
dstanekfun fact about signing or any encryption in the browser. you have to have you key in browser memory and would be open to the types of cross tab attacks that have been done in the past.18:28
*** roxanagh_ has joined #openstack-keystone18:29
ayoungdolphm, private key should not leave the users control.  Its very hackable... there is a pretty famous esssay about it...let me see if I can find it18:29
dolphmdstanek: how's that different from cookies, session IDs, etc?18:29
dstanekmozilla fixed their stuff and theoretically chromes architecture prevents the attack, but i don't trust browsers anymore18:29
*** e0ne has joined #openstack-keystone18:29
ayoungI think this is it ... https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/18:30
dstanekdolphm: it's not. it that now your private key is compromised and not a session key or transient data18:30
*** aix has quit IRC18:30
morganbknudson: atomic in what context?18:31
dolphmhttp://alexbilbie.com/2014/11/oauth-and-javascript/18:31
dolphmdstanek: would the solution be to make them transient then?18:31
bknudsonmorgan: as in memcache's compare-and-swap http://neopythonic.blogspot.com/2011/08/compare-and-set-in-memcache.html18:32
*** geoffarnold has quit IRC18:32
*** geoffarn_ has joined #openstack-keystone18:32
bknudsontest-and-set ... whatever you want to call it18:32
morganNot in the same way. Dogpile doesnt support cas.18:32
*** roxanagh_ has quit IRC18:32
dstanekdolphm: you could. lots or security protocols rely on keys that are only supposed to last for a session18:32
bknudsonmmm. cookies.18:33
morganIt does locking to get around that. CAS is wierd in memcache and not universal for kvs18:33
*** roxanagh_ has joined #openstack-keystone18:34
ayoungdolphm, so, lets assume browser based signing is out for the moment.  That might not be such a huge deal.  The only problem they really solve is multi-hop.  And even then...its really kind of wonky, because glance would have to be able to read a nova-boot request and say "ah yes, that nova can grab that image by ID"18:36
ayoungso, tokens are a poor but light weight proxy for authentication18:36
ayoungif we were to reduce them to just that, then the question still reamains:  if a user is requesting an action, are they authorized18:37
ayoungIf that is an endpoint scoped action, should the authorization be on the endpoint, and not on some random project?  Or, should we make all endpoints be owned by some project, and make them know about their project iD?  I'm OK with either approach...I've suggested both at various times18:38
dolphmi don't know about the solution, but it's hard to address the problem at all without strictly defining authorization boundaries18:41
*** jaosorior has quit IRC18:42
*** wwwjfy has quit IRC18:42
*** wwwjfy has joined #openstack-keystone18:43
*** su_zhang has joined #openstack-keystone18:45
*** dims_ has quit IRC18:46
*** openstackgerrit has quit IRC18:46
*** lhcheng_ has joined #openstack-keystone18:46
*** aix has joined #openstack-keystone18:46
*** dims_ has joined #openstack-keystone18:46
*** openstackgerrit has joined #openstack-keystone18:47
*** lhcheng has quit IRC18:48
dolphmayoung: the simplest case is all services trusting each other regardless of tenancy, right? for example, i only trust nova to make these 3 calls, and not this 4th one, but i never care about which tenant nova wants to work with18:48
ayoungdolphm, right.18:49
ayoungnova can fetch any image it wants, but should never ask to store one...18:49
ayoungit can create a snapshot, though18:49
*** ayoung is now known as ayoung-meeting18:51
dolphmsure18:51
*** doug-fish has quit IRC18:52
*** doug-fish has joined #openstack-keystone18:52
*** tonytan4ever has quit IRC18:54
*** aix has quit IRC18:55
*** tonytan4ever has joined #openstack-keystone18:55
*** david-lyle has quit IRC18:55
*** david-lyle has joined #openstack-keystone18:55
*** ankita_wagh has quit IRC18:56
dolphmayoung-meeting: in that case, is there a simpler solution than https w/ client authentication? policy checks would have to be reduced to "is the client nova? if so, allow" (completely ignoring tenancy)18:57
ayoung-meetingdolphm, probably.  Its the service token thing, right?18:58
*** henrynash has joined #openstack-keystone18:58
*** ChanServ sets mode: +v henrynash18:58
dolphmi'm not considering tokens as an option unless they solve a problem that we can't solve otherwise18:58
ayoung-meetingany API can, potentially take a service token.  If the service token says it is ok, then ... still need a RBAC check on the user its doing it for18:59
ayoung-meetingdolphm, it could be basic-auth, so long as the password is shared only between nova and glance18:59
*** ankita_wagh has joined #openstack-keystone18:59
ayoung-meetingthere are multiple ways:  all that could be done on a private interface without authentication, access to the network is authentication enough19:00
ayoung-meetingI mean, I don;t love that as a solution, but it was done for years19:00
*** su_zhang has quit IRC19:01
dolphmi don't think network access is sufficient in 2015 :)19:02
dolphmayoung-meeting: but basic auth is a good counter example. upside: you could default the password to secrete :) the downsides: no request integrity verification, no strong client authentication.19:02
dolphmit'd be an insecure default to have enabled if you really want people to switch to something stronger19:03
*** mylu has joined #openstack-keystone19:03
dolphmso beyond devstack, you're going to want https anyway19:04
morgandolphm: basic auth or client-certs would be a good option19:05
morganFor "is this nova"19:05
morganFor example.19:05
dolphmayoung-meeting: familiar with this one? i think it's new to me http://tools.ietf.org/html/rfc427919:05
ayoung-meetingor SPNEGO for those that prefer Kerberos.  Once Barbican is deployed by defaulty, Client certs becomes lighter weight to19:05
ayoung-meetingdolphm, heh, that was KDS19:06
ayoung-meetingKite19:06
ayoung-meetingNot 100%  BUT roughly19:06
dolphmha19:06
dolphmit seems like this is trying to avoid the need for additional complexity like kite, as a compromise between performance vs security?19:08
dolphmand compexlity19:08
dolphm(i'm not sure how that l migrated over so far)19:08
syinHi, wondering if this is the right place for my question.  I'm looking at domain support in Neutron.  In Keystone, we have policy.v3cloudsample.json which have checks like "(domain_id:%(domain_id)s".  But I don't see a similar policy.json in Neutron.  How do I go about supporting domains in Neutron?  Is there a domain-enabled version of policy.json like in Keystone?19:10
syinAlso when I was tracing the code in Neutron, it looks like during policy check, the credentials of the user/requester doesn't even have domain_id in the dictionary.19:11
syinI'm looking at Kilo19:11
dolphmsyin: just curious, what's the use case for domain-level operations in neutron?19:12
dolphmsyin: domain-level quota management or something?19:12
syinSo in the rest of the system, we have domain support so there are a different set of users/projects for each domain19:13
dolphmsyin: but what is neutron's use case for caring about domain-level operations?19:13
*** geoffarn_ has quit IRC19:14
syinbut when it comes to Neutron, I find that an admin in project1 of domain1 would be able to see networks from domain2, because the Neutron policy only checks for role:admin, which the admin has for project119:14
*** phalmos has quit IRC19:14
*** geoffarnold has joined #openstack-keystone19:14
syinso basically i thought the Neutron policy should be domain-aware so that it doesn't "leak" networks across different domains19:14
*** kiran-r has quit IRC19:15
dolphmsyin: well, it needs to respect roles per project, first, right? "admin" in openstack generally ignores tenancy, unfortunately.19:15
*** phalmos has joined #openstack-keystone19:15
syinexactly. for example, i want to have dom1 and dom2 for say 2 different organizations.  within each org, they have their own users and projects, along with their own admins.19:16
syinnow obviously it'd be bad that an admin from org one using domain1 suddenly starts seeing networks from domain2.19:16
syinif you look at the current neutron policy.json, there are a lot of checks for rule:admin_only, which translate to role:admin without checking the context (ie. admin of which project, or admin of which domain)19:17
*** _cjones_ has quit IRC19:17
*** GB21 has quit IRC19:18
lbragstadlifeless: do you now if there is a way to get around https://bugs.launchpad.net/pbr/+bug/1374677 without setting PBR_VERSION and using pip install -e . ?19:19
openstackLaunchpad bug 1374677 in PBR "setup.py with pbr attempts to do git operations in tarball" [Medium,Confirmed]19:19
dolphmsyin: so the two obvious (?) solutions to that problem are either to not assign the "admin" role to anyone should not be root of openstack, or to re-write neutron's policy file to require the "admin" role *and* a matching tenancy19:19
dolphmsyin: so, *always* require a matching authz context19:20
lbragstads/now/know/19:20
lifelesslbragstad: I hadn't seen that bug.19:21
lifelesslbragstad: it shouldn't happen at all19:21
lbragstadlifeless: interesting19:21
amakarovayoung-meeting, DAG lgtm, albeit I'd like to understand more clear, how we are supposed to work with them19:21
lbragstadlifeless: I was just curious, because I don't think pbr is supporting the use of python setup.py, right?19:21
*** david-lyle has quit IRC19:22
lifelesslbragstad: ayoung-meeting is wrong IMO - pbr doesn't conflict with rpm versioning (we've explicitly got behaviours there to support distros)19:22
syindolphm: thanks for the suggestions.  1) isn't going to work because each organization really needs their own admins, but these are project-level and domain-level admins, not root openstack admins.  currently there is no way to distinguish what kind of admins they are when validating policies.19:22
lbragstadlifeless: ok, so given that, I have a question19:22
*** david-lyle has joined #openstack-keystone19:22
lifelesslbragstad: so for end users running 'python setup.py' is nearly always the wrong thing because it triggers easy_install (which is nothing to do with pbr)19:23
ayoung-meetingsyin, don't call em admins19:23
*** tonytan4ever has quit IRC19:23
dolphmsyin: and it's the policy file not checking context that essentially makes an "admin" into "root"19:23
ayoung-meetingcall them managers and make a new role19:23
syin2) that's actually what i've done now - with a context_is_admin being changed to role:admin and tenant_id:%(tenant_id)s19:23
lifelesslbragstad: at a plumbing level we'll definitely support what rpm and dpkg etc need19:23
lbragstadlifeless: ah, makes sense, which is why you recommend using pip install -e with pbr19:23
ayoung-meetingadd a policy check for the manager role19:23
*** su_zhang has joined #openstack-keystone19:23
lifelesslbragstad: the -e gets you 'develop', without -e it gets you 'install', but without as much room for easy-install to creep in19:24
lbragstadlifeless: because pip doesn't invoke easy_install19:24
lifelesslbragstad: just be sure you install pbr (which as a build-time dep pip doesn't handle yet) by hand first19:24
lifelessyah19:24
lifelesslbragstad: so you're seeing the same behaviour as in that bug ?19:24
lbragstadlifeless: yes, something similar but i believe my situation is different19:25
lbragstadlifeless: say i have a project that depends on an upstream project, and in my project's requirements.txt i have a link to the upstream git url, so a tarball19:25
lifelesslbragstad: don't do that :)(19:26
lbragstadlifeless: ok :)19:26
*** stevemar has joined #openstack-keystone19:26
*** ChanServ sets mode: +o stevemar19:26
syindolphm: however that's not the best solution (or at least it requires a lot of changes), because there are a lot of references to rule:admin_only, and if the target object does not have a tenant_id, there will be an exception due to the Neutron custom OwnerCheck(), which tries to look up "tenant" object as a parent if it cannot find tenant_id in the target's dictionary.  e.g. dhcp_agent is one such object.19:26
lbragstadlifeless: what should i do?19:26
lifelesslbragstad: so part of the problem here is that requirements.txt as pip defines it and pbr defines it differ19:26
lifelesslbragstad: (We're working on deprecated requirements.txt to fix this difference)19:26
lifelesslbragstad: pip install -r requirements.txt will resolve urls etc19:27
dolphmsyin: that's the broader problem that ayoung-meeting and i were just discussing. there are lots of tenant-less operations in openstack and we don't have a great authorization model for those. nothing in policy is really sufficient today, so the super root "admin" junk fills that gap19:27
syindolphm: yes the problem is that the default neutron policy.json basically treats anyone with an admin role as a super-root-admin type of user.  and the other problem is during policy enforcement, the "creds" dictionary does not have any domain_id for the policy file to check with.19:27
lifelesslbragstad: python setup.py install triggers reflection from pbr to map requirements.txt into setup(install_requires="...")19:27
lbragstadlifeless: interesting19:27
lifelesslbragstad: but setuptools install_requires cannot handle urls19:27
lifelesslbragstad: (at all)19:28
*** tonytan4ever has joined #openstack-keystone19:28
lifelesslbragstad: so pbr has to strip out the urls and transforms them to just the package names19:28
ayoung-meetingsyin, bug 96869619:28
openstackbug 968696 in OpenStack Compute (nova) ""admin"-ness not properly scoped" [High,Confirmed] https://launchpad.net/bugs/96869619:28
ayoung-meetingcinder claims they close it. Cinder lies19:28
dolphmsyin: there will only be a domain ID if the API user is authenticating with a domain-scoped token19:28
dolphmsyin: a project scoped token has no domain-level authorization19:29
lifelesslbragstad: this leads to developer confusion when the url version is not installed by 'pip install mypackage' and instead the version of the egginfo name from PyPI is installed19:29
lifelesslbragstad: the options are:19:29
lbragstadlifeless: yeah, i notice two different behaviors when I set version in my project's setup.cfg and when i set PBR_VERSION to something else19:30
lifeless - use pip install -r requirements.txt . # this will honour the urls (until we publish to PyPI)19:30
lifeless - use the name in requirements.txt and a constraints file to force the url version of the dep #makes it explicit that its a local choide19:30
lifelesslbragstad: PBR_VERSION just overrides the version19:31
syindolphm: hmm, right.  so basically if i want to allow my policy.json to check for domain_ids, i would have to add code somewhere before policy enforcement to "inject" the domain_id info?  ie. receive API call, look up which domain_id the user or project belongs to, and append it to the "creds" dictionary.  then I can compare domain_id in my policy.json file.19:31
lifelesslbragstad: version in setup.cfg sets a *target* version, not an actual version19:31
lbragstadlifeless: ah, ok... I thought that set the version of my package19:31
*** amakarov is now known as amakarov_away19:33
nisha_hello everyone :D19:33
*** jsavak has quit IRC19:33
nisha_I am a newbie and I want to contribute in keystone19:34
lifelesslbragstad: http://docs.openstack.org/developer/pbr/#version19:34
nisha_samueldmq, helped me and found an easy bug for me19:34
sweetjeebusHi y'all19:35
*** david-lyle has quit IRC19:35
nisha_It involved replacing all occurences of of http://code.google.com/p/sqlalchemy-migrate/ by https://github.com/stackforge/sqlalchemy-migrate19:35
lbragstadlifeless: so when I had version set in my setup.cfg, and I installed my package, I saw the version listed as <version>-dev31 or something similar19:35
lbragstadlifeless: so that all makes sense19:35
sweetjeebusAnybody familiar with that 'UTF8' Bug? https://bugs.launchpad.net/keystone/+bug/1469029 ?19:35
openstackLaunchpad bug 1469029 in Keystone "Migrations fail going from juno -> kilo" [High,Fix released] - Assigned to Morgan Fainberg (mdrnstm)19:35
dolphmsyin: the auth_token middleware will pass down a domain ID if the user used a domain-scoped token19:35
dolphmsyin: just because the user is owned by a domain should NOT imply that the user has any sort of authorization on that domain19:35
*** jsavak has joined #openstack-keystone19:35
lifelesslbragstad: yep19:36
dolphmsyin: the same goes for the domain that owns the project.19:36
dolphmsyin: those are exposed to services to namespace users and projects, not to provide some means of privilege escalation19:36
sweetjeebusfor what its worth, I had a backup of my db at v5519:36
lifelesslbragstad: generally these days I think noone should need version= in their setup.cfg, the git automatic semver should just do the right thing19:36
sweetjeebusand ran through it a few times19:36
nisha_So, I did the changes and did git commit. But I have some problem in git review. http://paste.openstack.org/show/474921/ Can someone please help me? I would be really grateful :)19:36
sweetjeebusbefore importing the db dump, I ran:19:36
sweetjeebusalter table revocation_event convert to character set utf8 collate utf8_unicode_ci ;         alter database keystone CHARACTER SET utf8 COLLATE utf8_unicode_ci;      - after this, it works19:36
lbragstadlifeless: but when i had to install my requirements.txt (which contained a url to keystone's master tarball) I'd get something like - http://cdn.pasteraw.com/saj757pt746cbvg8a8s7zezvhjglnd219:36
sweetjeebusanyway, its an easy way around it for now19:37
lbragstadlifeless: so, then I set PBR_VERSION to something, and then both my project version and the version of keystone are the same as the PBR_VERSION19:37
lifelesslbragstad: oh, so yeah I know whats going on19:37
lifelesslbragstad: I think you've got two separate things confused19:37
lbragstadlifeless: probably :)19:37
lifelesslbragstad: that error is nothing to do with your project19:37
lifelesslbragstad: its because the git *exports* from github aren't usable19:37
lifelesslbragstad: they have no version data in them. Don't try to use them.19:38
lifelesslbragstad: If you want to use master from git, use a git url19:38
lifelesslbragstad: https://pip.pypa.io/en/latest/reference/pip_install/#vcs-support19:38
lifelesslbragstad: whats happening is that the tarball on github has no version data, so the pbr logic for *it* [not your project] fails19:39
lbragstadlifeless: ah, so put that in my requirements.txt and not - https://github.com/openstack/keystone/tarball/master#egg=keystone19:39
lifelesslbragstad: right19:39
lifelesslbragstad: don't alter your project at all :)19:39
lbragstadjust alter my requirements19:39
lifelesslbragstad: that said, because of the aforementioned limitations on requirements reflection, don't put that in your requirements.txt either19:39
lifelessput 'keystone' in your requirements.txt19:40
*** marzif has joined #openstack-keystone19:40
lifelessand put the url in a new file 'constraints.txt'19:40
lifelessthe pip install -c constraints.txt pathtoyourproject19:40
lifelesshttps://pip.pypa.io/en/latest/user_guide/#constraints-files19:41
syin@dolphm: so in my example, i have someone who is a project admin or a domain admin, who has the admin role for that particular project or domain, and I need to make sure s/he does not see networks from a different domain, the best way is just to match tenant_id of creds against tenant_id of the target (the network) (solution 2 above), and change all the rule:admin_only to use this new, more specific admin-checking rule.19:42
lbragstadlifeless: makes sense, so - http://cdn.pasteraw.com/qq01aidp62pwc6clcy5uiqx5z8t56un19:42
ayoung-meetingnisha_, here is better19:42
syin@dolphm: and then i just have to work out the cases when the target does not have tenent_id in its dictionary and make sure those use the old context_is_admin rule.19:42
ayoung-meetingnisha_, but I am debugging somethign at the moment19:43
lbragstadlifeless: then i should be able to install my project without exporting PBR_VERSION19:43
lbragstadand still retain my project's version defined in my setup.cfg19:43
*** su_zhang has quit IRC19:44
syin@dolphm: I wanted to check here if there is already an upstream solution for my issue that I'm not aware of.  I'm kind of surprised that Neutron thinks anyone with admin role is admin across all projects/domains.19:44
dolphmsyin: all projects make that assumption19:45
dolphmsyin: neutron isn't the only one19:45
syin@dolphm: i thought keystone, for example, distinguishes between project and domain admins?  eg. "role add --user user1 --project project1 admin" gives a different role than "role add --user user1 --domain dom1 admin"19:46
dolphmsyin: it absolutely does, but when you use the role name "admin" most projects will ignore the tenancy19:47
dolphmmost services*19:47
nisha_ohh sure ayoung-meeting19:47
dolphmsorry, don't mean for this to be more confusing than it already is :)19:47
nisha_I wil wait, no problem :)19:47
nisha_This, channel seems very busy right now. So I am in no hurry19:47
syin@dolphm: no i really really appreciate your help.  judging from those keystone commands, I thought every project, such as neutron, would understand the concept of different types of admins.19:49
syin@dolphm: I thought domains were introduced as a further segregation of  user/projects.  if services such as neutron ignore tenancy / domains, then how can the segregation be done?19:51
lifelesslbragstad: right19:51
lbragstadlifeless: awesome! testing it out now19:51
lifelesslbragstad: if you use git tags for releases you can just skip the version= line in setup.cfg entirely19:51
lbragstadlifeless: because pbr will derive the version from git tags, right?19:52
lifelesslbragstad: and use tags and/or sem-ver: pseudo headers in your git commits to control the version19:52
lifelessyeah19:52
lbragstadlifeless: makes sense19:52
dolphmsyin: depends on what you mean by segregation? domains provide namespaces for users & projects, so that two users / projects can have identical names.19:52
*** david-lyle has joined #openstack-keystone19:52
dolphmsyin: but all tenants, regardless of owning domain, should have their resources segregated from each other. domains don't change that.19:52
*** mylu has quit IRC19:53
syin@dolphm: right. in my case, some of my requirements are: 1) each domain should have its own admin(s) with admin rights only for resources belonging to its own domain,19:54
openstackgerritHenrique Truta proposed openstack/keystone: Includes server_default option in is_domain column  https://review.openstack.org/21516719:55
syin@dolphm: 2) networks are tenant-specific.  you know how when you list networks, you see networks from your own tenant but also external and shared networks?  Well I need to restrict that to each domain.  so a "shared" network or external network only appears in 1 domain and not another.19:55
*** geoffarnold has quit IRC19:56
*** geoffarnold has joined #openstack-keystone19:56
syin@dolphm: so with these kind of requirements, i am playing around with policy.json to best achieve the separation, and i'm just having troubles with the role:admin part.19:56
dolphmsyin: that's not really a use case we've addressed via keystone, that i'm aware of. i imagine you'd have to ask keystone for the enumeration of projects that belong to the domain in a domain-scoped token to achieve that?19:58
dolphmsyin: and then enumerate resources in neutron that belong to any of those projects?19:59
morgandolphm: alternatively other projects could grow domain awareness I guess =/19:59
dolphmsyin: depending on the domain, there could be a lot of projects and a lot of resources, obviously. you could handle that client-side, as well... the client could establish sessions for a number of different tenants, make requests to neutron for each, and combine the results into a single interface20:00
morgandolphm: we can assert a project cannot be moved between domains, and domain info is propagated20:00
morgan(we do assert projects can't be moved) - but this is just forward speculation on what could be done20:00
morgansyin: ^ cc20:00
* dolphm <rant> or if we didn't have scoped-tokens then the client could just make a single request and enumerate a bunch of tenants it cared about </rant>20:01
*** lhcheng_ has quit IRC20:01
openstackgerritHenrique Truta proposed openstack/keystone: Add test case passing is_domain flag as False  https://review.openstack.org/22954920:01
morgandolphm: heh20:01
bknudsonyou can get the list of tenants you have a role on20:02
*** nisha__ has joined #openstack-keystone20:03
*** Sam-I-Am has left #openstack-keystone20:04
htrutaspeaking of not moving a project between domains, do you guys think we can land this still in liberty?20:06
syin@dolphm @morgan: to somehow get a list of projects belonging to a domain along with the token might work, but i was thinking more along the lines of just being able to determine what type of role:admin we're talking about (for what project or for what domain), then being able to match that against the project  or domain of the target (eg. a network)20:06
*** lhcheng has joined #openstack-keystone20:06
*** ChanServ sets mode: +v lhcheng20:06
*** david-ly_ has joined #openstack-keystone20:07
*** nisha_ has quit IRC20:07
*** su_zhang has joined #openstack-keystone20:07
syinif this kind of info is available when enforcing policies, i think i can come up with a better way to meet my requirements.20:07
morgansyin: that is going back to the enumeration issue.20:07
*** david-lyle has quit IRC20:07
morganit can/would be expensive to make that query or balloon the data needed for the token20:07
*** lhcheng_ has joined #openstack-keystone20:08
*** david-ly_ is now known as david-lyle20:08
morganit would likely be easier to make neutron domain aware, project info always has domain id associated with it - it is a check of a single value instead of a "search to see if this matches".20:08
*** nisha__ has quit IRC20:09
morganyou can tell what project you're scoped to, you can tell what domain the project is in20:09
*** nisha_ has joined #openstack-keystone20:09
morganbut it is hard to know what other projects are in the domain without a query. much easier to store/reference that data directly20:09
morganand again, projects *cannot* be moved between domains (for security reasons).20:09
*** jsavak has quit IRC20:10
*** lhcheng has quit IRC20:11
syin@morgan: i do understand we don't want to move projects between domains - that's fits very well with my intention to use domains to completely separate 2 organizations.20:12
morgansyin: this looks like a feature add that will be needed to meet your use-case compared to what is available today20:13
*** jsavak has joined #openstack-keystone20:13
morganat least at face value (something added to neutron)20:13
morganbut I am guessing here, playing catchup on the scrollback20:14
syin@morgan: yes i think so too20:14
*** mylu has joined #openstack-keystone20:14
syin@morgan: my main intention here is to make sure i'm not missing something that is already available / implemented upstream.  if nothing is available, i will have to hack some code to get the separation i want.20:14
morganI dont think what you want is currently available20:15
morganI can see the use-case/benefit20:15
syin@morgan: ok thanks for the confirmation.  though i'm still trying wrap my head around how most services still aren't domain aware in some way.20:15
morganmost services dont need to be domain aware20:16
*** gyee has quit IRC20:16
syin@morgan, that is what i learned today with the discussion between @dolphm and you20:16
morgansince tokens are project scoped20:16
*** zzzeek has quit IRC20:16
morganregardless of any silly behavior of "admin" vs "admin" between projects [lets ignore that for a second]20:16
morganwhen you tell nova to boot a VM, does it care what domain? no, just what project20:16
morgansimilar for most everything since resources are limited to projects20:16
morganheat is the notable exception20:17
syin@morgan: maybe I can write up a few use cases to better explain what i want to do, and then maybe you could give me some suggestions on how best to tackle it?  I came up with some way but I'm new to neutron / keystone so other suggestions are definitely welcomed.20:17
morganyour use-case for neutron would be an exception as well20:17
morganbut a VM via nova *cant* be in two projects or bridge two projects20:17
*** geoffarn_ has joined #openstack-keystone20:17
morgansyin: this is something I do encourage sending to the dev mailing list20:17
syin@morgan: i see your point about some services don't need to be domain aware20:17
*** geoffarnold has quit IRC20:18
morganand definitely circle up w/ us and the neutron team(s)20:18
syin@morgan: yes neutron is probably an exception because it has stuff like external networks and shared networks which spans across projects, but in my case i don't want them to span across domains.20:18
*** zzzeek has joined #openstack-keystone20:18
morganworth discussing more then :)20:18
morgani suggest also talking to neutron folks and/or sending the use-case to the dev mailing list20:19
syin@morgan:  this is my first contact with upstream openstack community, could you please kindly point to a channel, email address where I can send my discussion to?20:19
morganneutron is #openstack-neutron20:19
morganand the dev mailing list... sec20:19
morganhttps://wiki.openstack.org/wiki/Mailing_Lists here is the wiki on mailing lists20:20
syinthis issue is across neutron and keystone, so i guess openstack@lists.openstack.org ?20:21
morganthis would be openstack-dev likely20:21
morganand in the subject you'll want "[keystone][neutron] <your subject/title>"20:22
syinah ok. thanks.  is there a way for me to CC you and @dolphm?20:22
morganyou probably want to subscribe to the list20:22
morganwe're on the list for sure20:22
syinwill do20:22
morganthe [keystone] and [neutron] in the subject will help folks who watch the mailing list filter/see that it is related to both projects20:23
syin@morgan @dolphm: ok. i'll try to tidy up my thoughts and post there.  thank you so much for your help today.  It's encouraging that you guys take my question seriously and take the time to respond to me!20:24
dolphmsyin: i definitely get everything with [keystone] in the subject, along with a bunch of other tags20:27
*** sweetjeebus has quit IRC20:27
*** su_zhang has quit IRC20:28
*** su_zhang has joined #openstack-keystone20:30
syin@dolphm: ok thanks!  will continue the discussion there.  I might not be able to get to it today but it'll get there :)20:32
*** urulama has quit IRC20:37
*** _cjones_ has joined #openstack-keystone20:37
*** urulama has joined #openstack-keystone20:37
*** geoffarn_ has quit IRC20:38
*** geoffarnold has joined #openstack-keystone20:38
*** stevemar has quit IRC20:39
*** stevemar has joined #openstack-keystone20:40
*** ChanServ sets mode: +o stevemar20:40
*** mylu has quit IRC20:40
*** phalmos has quit IRC20:41
openstackgerritHenrique Truta proposed openstack/keystone: Manager support for projects acting as domains  https://review.openstack.org/21344820:41
openstackgerritHenrique Truta proposed openstack/keystone: Add is_domain parameter to get_project_by_name  https://review.openstack.org/21060020:41
*** nisha_ has quit IRC20:43
*** stevemar has quit IRC20:45
openstackgerritHenrique Truta proposed openstack/keystone: Add test case passing is_domain flag as False  https://review.openstack.org/22954920:45
*** topol has quit IRC20:46
*** _cjones_ has quit IRC20:48
*** _cjones_ has joined #openstack-keystone20:49
*** henrynash has quit IRC20:50
*** ankita_wagh has quit IRC20:52
*** stevemar has joined #openstack-keystone20:53
*** ChanServ sets mode: +o stevemar20:53
*** hrou has quit IRC20:53
*** raildo is now known as raildo-afk20:55
openstackgerritHenrique Truta proposed openstack/keystone: Includes server_default option in is_domain column  https://review.openstack.org/21516720:55
*** ankita_wagh has joined #openstack-keystone20:56
*** geoffarnold has quit IRC20:59
*** geoffarnold has joined #openstack-keystone21:00
*** su_zhang has quit IRC21:02
*** nicodemos has quit IRC21:02
*** ankita_w_ has joined #openstack-keystone21:03
*** ankita_wagh has quit IRC21:03
*** david-lyle has quit IRC21:03
*** david-ly_ has joined #openstack-keystone21:03
*** su_zhang has joined #openstack-keystone21:05
*** david-ly_ is now known as david-lyle21:05
*** jsavak has quit IRC21:05
*** gildub has joined #openstack-keystone21:06
*** syin has quit IRC21:12
stevemardstanek: yo21:25
stevemaryou -1ed https://review.openstack.org/#/c/215870/12 and left no comments21:26
*** woodster_ has joined #openstack-keystone21:26
*** gabriel-bezerra has quit IRC21:26
*** david-lyle has quit IRC21:26
*** david-lyle has joined #openstack-keystone21:29
*** albertom has quit IRC21:33
*** doug-fish has quit IRC21:36
*** doug-fish has joined #openstack-keystone21:36
stevemarpokes lbragstad: lhcheng_ about https://review.openstack.org/#/c/215870/21:38
*** doug-fis_ has joined #openstack-keystone21:39
dolphmstevemar: i believe the bug report mentioned in that code review dstanek -1'd might be a dupe of one opened by odyssey4me21:40
dolphmor maybe i just remember discussing the issue with odyssey4me ..21:40
*** doug-fish has quit IRC21:41
stevemardolphm: i dunno, there are no comments so i can't be certain21:41
dolphmstevemar: i'm not saying that's why he -1'd21:42
*** geoffarnold has quit IRC21:42
*** doug-fish has joined #openstack-keystone21:42
*** geoffarn_ has joined #openstack-keystone21:42
* stevemar shrugs at dolphm21:42
stevemardolphm: review: https://review.openstack.org/#/c/206561/ ?21:43
stevemardolphm: i'm itching to get these rc bugs merged21:43
dolphmi wonder how many reviews are -1's without comments21:43
*** john5223 has joined #openstack-keystone21:43
dolphmlike, in general21:43
*** doug-fis_ has quit IRC21:43
dolphmstevemar: looking!21:43
stevemardolphm: generally few i think21:44
*** doug-fish has quit IRC21:46
stevemardolphm: agreed, it looks goo21:47
stevemard21:47
*** pauloewerton has quit IRC21:47
*** david-lyle has quit IRC21:48
stevemardolphm: same patch but for liberty21:52
stevemarhttps://review.openstack.org/#/c/229647/21:52
*** doug-fish has joined #openstack-keystone21:54
*** david-lyle has joined #openstack-keystone21:54
*** sdake has quit IRC21:55
openstackgerritDolph Mathews proposed openstack/keystone: Make __all__ immutable  https://review.openstack.org/22965621:58
*** sdake has joined #openstack-keystone21:58
*** gordc has quit IRC21:58
*** doug-fish has quit IRC21:58
*** iurygregory has quit IRC21:59
*** geoffarnold has joined #openstack-keystone22:04
*** geoffarn_ has quit IRC22:04
*** svasheka has quit IRC22:05
*** lhcheng_ has quit IRC22:06
jamielennoxdolphm: who would mess with __all__?22:06
*** csoukup has quit IRC22:06
dolphmjamielennox: no one malicious, certainly22:08
*** diazjf has quit IRC22:08
*** ngupta has quit IRC22:09
*** topol has joined #openstack-keystone22:09
*** ChanServ sets mode: +v topol22:09
*** slberger has left #openstack-keystone22:09
*** su_zhang has quit IRC22:10
*** su_zhang has joined #openstack-keystone22:11
*** tonytan4ever has quit IRC22:13
*** lhcheng has joined #openstack-keystone22:14
*** ChanServ sets mode: +v lhcheng22:14
*** cjschaef__ has quit IRC22:14
*** mylu has joined #openstack-keystone22:14
*** david-lyle has quit IRC22:15
*** topol has quit IRC22:16
*** hrou has joined #openstack-keystone22:17
*** jecarey__ has quit IRC22:17
*** mylu has quit IRC22:20
*** su_zhang has quit IRC22:21
stevemarpokes at morgan for a stable/liberty change https://review.openstack.org/#/c/229647/22:22
openstackgerritBrant Knudson proposed openstack/keystone: Add LimitRequestBody to sample httpd config  https://review.openstack.org/20820822:23
morganstevemar: you are now admin of LP groups22:26
stevemarmorgan: yay \o/22:26
morganstevemar: you can add/remove people from keystone-drivers and keystone-coresec22:26
morganyou are now also responsible for security things.22:26
morgan;)22:26
stevemarmorgan: whats the difference between the two22:26
morgancoresec is security bugs22:26
morgandrivers is the normal core group22:27
stevemaroh fun22:28
*** devlaps has quit IRC22:30
*** ankita_wagh has joined #openstack-keystone22:30
*** ankita_w_ has quit IRC22:30
*** dims__ has joined #openstack-keystone22:30
*** su_zhang has joined #openstack-keystone22:31
*** e0ne has quit IRC22:33
*** dims_ has quit IRC22:33
*** david-lyle has joined #openstack-keystone22:36
*** su_zhang has quit IRC22:36
openstackgerritBrant Knudson proposed openstack/keystone: Cleanup _build_federated_info  https://review.openstack.org/22065822:36
*** mylu has joined #openstack-keystone22:38
htrutahey stevemar, how do I know if I can propose something to stable/liberty?22:40
*** mylu has quit IRC22:40
stevemarhtruta: only if it's a bug that is critical to liberty22:40
htrutastevemar: it's not critical, but it's pretty simple... just deprecating an update22:41
htrutathat would help us in a short future22:42
*** hrou has quit IRC22:42
stevemarhtruta: link?22:43
htrutahttps://review.openstack.org/#/c/207218/22:44
htrutastevemar, it just hasn't merged before because I've put it in the middle of the reseller chains22:44
*** spandhe has joined #openstack-keystone22:50
stevemarhtruta: i think bumping it to M is the right move, it's a wishlist bug, and no need to rush it into L. we'll carry the deprecation for another cycle, not that big of a deal22:50
*** su_zhang has joined #openstack-keystone22:51
*** mylu has joined #openstack-keystone22:51
htrutastevemar, fine. totally agreed22:52
htrutatks22:53
openstackgerritBrant Knudson proposed openstack/keystone: Document token provider support  https://review.openstack.org/22488822:53
openstackgerritBrant Knudson proposed openstack/keystone: Document token provider support  https://review.openstack.org/22488822:54
htrutastevemar, deprecating it in M and removing in M looks good to you?22:59
*** browne1 has joined #openstack-keystone23:03
*** alejandrito has quit IRC23:04
boltRis there a way to put secrets into the keystone token?23:06
*** browne has quit IRC23:06
boltRlike passwords23:06
*** geoffarnold has quit IRC23:07
*** geoffarnold has joined #openstack-keystone23:07
*** marzif has quit IRC23:10
*** EinstCra_ has quit IRC23:22
stevemarhtruta: we would remove in N23:23
*** stevemar has quit IRC23:23
*** stevemar has joined #openstack-keystone23:24
*** ChanServ sets mode: +o stevemar23:24
*** brad[] has quit IRC23:25
*** sigmavirus24 is now known as sigmavirus24_awa23:26
*** geoffarnold has quit IRC23:28
*** stevemar has quit IRC23:28
*** geoffarnold has joined #openstack-keystone23:29
*** mylu has quit IRC23:33
*** mylu has joined #openstack-keystone23:33
*** mylu has quit IRC23:34
*** mylu has joined #openstack-keystone23:34
openstackgerritMerged openstack/keystone: Skip rows with empty remote_ids  https://review.openstack.org/20656123:35
*** akanksha_ has quit IRC23:38
*** roxanagh_ has quit IRC23:38
*** hrou has joined #openstack-keystone23:38
openstackgerritHenrique Truta proposed openstack/keystone: Restricting domain_id update  https://review.openstack.org/20721823:40
*** roxanagh_ has joined #openstack-keystone23:41
*** topol has joined #openstack-keystone23:45
*** ChanServ sets mode: +v topol23:45
*** su_zhang has quit IRC23:47
*** hidekazu has quit IRC23:48
*** hidekazu has joined #openstack-keystone23:48
*** su_zhang has joined #openstack-keystone23:49
*** topol has quit IRC23:50
*** geoffarnold has quit IRC23:50
*** geoffarn_ has joined #openstack-keystone23:50
*** dsirrine has quit IRC23:51
*** syin has joined #openstack-keystone23:55

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