Thursday, 2014-05-22

*** amcrn has joined #openstack-keystone00:13
*** openstackgerrit has quit IRC00:19
*** openstackgerrit has joined #openstack-keystone00:20
*** BAKfr has quit IRC00:25
*** openstackgerrit has quit IRC00:34
*** openstackgerrit has joined #openstack-keystone00:35
*** richm has quit IRC00:35
openstackgerritA change was merged to openstack/python-keystoneclient: Move DisableModuleFixture to utils  https://review.openstack.org/9349600:42
*** gokrokve has joined #openstack-keystone00:43
rodrigodsayoung, time for a +2 today? =)00:47
*** gokrokve has quit IRC00:48
*** gordc has joined #openstack-keystone00:49
*** openstackgerrit has quit IRC00:49
*** openstackgerrit has joined #openstack-keystone00:50
*** gordc has quit IRC00:52
openstackgerritBrant Knudson proposed a change to openstack/keystone: LDAP fix for get_roles_for_user_and_project user=group ID  https://review.openstack.org/9447000:56
openstackgerritBrant Knudson proposed a change to openstack/keystone: Adds function to compare DNs  https://review.openstack.org/9451300:56
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add a test for getting grant for a user with a , in ID  https://review.openstack.org/9474000:56
bknudsonnkinder: those are the changes as described for master, so the LDAP fix now uses the DN compare functions00:57
nkinderbknudson: what is the new match() change for in 94740?01:01
nkinderbknudson: sorry, _match()01:01
bknudsonnkinder: the existing .test_user_id_comma test actually started failing01:02
ayoungrodrigods, heh...I haven't forgotten01:03
bknudsonand this was because the fakeldap was dumb about doing the comparison of the attributes for filter matching01:03
nkinderbknudson: ah, ok01:03
ayoungrodrigods, I promised today...gives me about 3 hours....01:03
bknudsonit was only normalizing the value passed in and not the values in the entry01:03
rodrigodsayoung, heheh ok01:03
ayoungrodrigods, but first an expense report for summit01:04
rodrigodsayoung, first things first01:06
nkinderbknudson: everything looks good.  I've +1'd them all.01:07
nkinderayoung: if you have 3 hours, you should have plenty of time left in the day for 3 more +2's for bknudson's patches! :)01:07
bknudsonI'll give people time to look at these today and work on the icehouse port in the morning01:08
bknudsonand let jenkins run to make sure it doesn't catch something again... at least I ran all the tests this time.01:09
rodrigodsbknudson, did you have the change to check the last changes at https://review.openstack.org/#/c/91578/?01:09
*** xianghui has quit IRC01:09
bknudsonrodrigods: it's on my list but I don't have time today01:10
rodrigodsbknudson, no problem =)01:10
nkinderbknudson: sounds good.  Thanks again for getting this all straightened out!01:11
rodrigodsbknudson, thanks for your previous comments01:11
nkinderbknudson: I'll look for your icehouse port tomorrow morning and will look it over.01:11
*** gabrielbezerra has quit IRC01:15
*** gabrielbezerra has joined #openstack-keystone01:15
*** marcoemorais has quit IRC01:16
*** clu_ has quit IRC01:23
*** diegows has quit IRC01:29
*** gyee has quit IRC01:32
*** hipster has joined #openstack-keystone01:36
*** gokrokve has joined #openstack-keystone01:43
*** gokrokve_ has joined #openstack-keystone01:44
*** gokrokve_ has quit IRC01:44
*** gokrokve_ has joined #openstack-keystone01:44
*** gokrokve has quit IRC01:48
*** gokrokve_ has quit IRC01:52
*** amcrn has quit IRC01:57
*** rodrigods has quit IRC01:59
ayoungjamielennox, https://review.openstack.org/#/c/91578/8/keystoneclient/v3/assignments.py,cm   is he right, or do we have a cleaner way to deal with the not implemented method for a client API?02:03
ayoungline 98 and beyond02:03
jamielennoxayoung: heh, i've wondered whether we should start doing that02:04
jamielennoxby importing crudmanager you get all those functions automatically and there's no way to not02:04
ayoungI think I'm going to let it go, then. Its easier than what I did with regions02:05
ayoungUntil we cleanup crud manager02:05
jamielennoxyea - i don't mind having that02:05
ayoungWhich plugin has a good example of how to build query strings?  His string handling is ovbisouly too hand-jammed02:05
jamielennoxthere's too much baggage there02:05
jamielennoxso from memory if you just pass kwargs through to super().list() it should handle that for you02:06
jamielennoxi'm not sure what the rationale behind building it yourself then passing to _list is02:06
jamielennoxbut i haven't looked at the review02:06
ayoung'slright, can kick it back with that guidance02:07
jamielennoxwhy params with . s in them02:07
jamielennoxscope.domain.id02:07
jamielennoxis that normal?02:07
*** clu_ has joined #openstack-keystone02:07
jamielennoxbecause that could be why02:07
*** clu_ has quit IRC02:07
jamielennoxi hate that manager code02:08
ayoungjamielennox, I thought henrynash wrote that role_assignments code02:11
ayoungdef list_role_assignments(self, context, filters):  has02:13
ayoung @controller.filterprotected('group.id', 'role.id',   and so on02:13
*** gokrokve has joined #openstack-keystone02:14
ayounghttps://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#list-effective-role-assignments-get-role_assignments02:15
ayoungjamielennox, is it just me, or is that the only place we do params like that?02:15
jamielennoxayoung: that's the only place i can think of it02:16
jamielennoxthe only reason i can think to have done it that way is so that it lines up with how the policy files are written02:16
ayoungneed to ask Henry why, but I'm guessing that is messing up the param marshalling02:16
jamielennoxit's kinda weird to handle it like that02:16
ayoung "identity:list_role_assignments": "rule:admin_on_domain_filter or rule:admin_on_project_filter",02:18
ayoungjamielennox, yeah, I am guessing that henry used the same format as the flattending dictionary02:18
ayoungflattened02:18
*** gokrokve has quit IRC02:18
*** gokrokve has joined #openstack-keystone02:20
ayoungjamielennox, what do you think about, for fine grained delegation, adding an optional section to a token that matches the rules from the policy file.  So even if you have, in that case, rule:admin_on_project_filter   the token would only pass if you also had  something like  "apis" :[ "identity:list_role_assignments"]02:20
jamielennoxthat's very fine grained02:20
jamielennoxumm, i think that would be hard to manage02:21
ayoungIt would be explicitly for handing out fine grained delegations without creating a new abstraction02:21
jamielennoxwhat's the case for it02:22
jamielennoxi understand if you wanted something like that in the form of trusts where you are just handing something off02:22
ayoungTo limit exposure.  Right now, the roles are so wide ranging, we basically have "admin" and "member"02:22
jamielennoxobviously it would help with interception02:22
jamielennoxbut you're talking about having the user limit there own abilities02:23
jamielennoxi can see the case for service users but service users should be able to do that via roles02:23
ayoungI think that it makes sense for trusts and oauth02:23
jamielennoxi guess it could be used setting up like a heat workflow02:24
ayoungbut tokens are themselves a form of delegation.  So, for instance, you could pass to Nova the ability to fetch something out of glance, but not write to it02:24
ayoungjamielennox, a way of implementing https://blog-nkinder.rhcloud.com/?p=10102:24
*** hipster has quit IRC02:25
ayoungIt might be easier than doing "stacked policy" too02:25
*** xianghui has joined #openstack-keystone02:27
jamielennoxhmm, that's kind of a hard thing to enforce generically02:28
jamielennoxchecking apis02:28
jamielennoxwhat about you change how you look at it, and you make a specific delegation token02:29
jamielennoxa delegation token is a token that cannot be used directly for auth but is used in conjunction with another token02:30
jamielennoxso for example you communicate to nova, nova must send both the nova token and the delegated token to glance02:30
jamielennoxthen you can do permission enforcement on glance based on the conjunction02:30
jamielennoxhmm02:30
jamielennoxhmm - that doesn't rreally work because everything is a delegation token, you can't start the process02:31
ayoungI was thinking along those lines, or just hand nova abunch of tokens, and each one can be used only once02:34
ayoungor a limitd number of times, and then gets stuck in the revocation list02:34
ayoungInstead of one big token, you just have a bunch of tiny ones...or something02:35
ayoungjamielennox, the idea is a role is a big thing, and that operations are based on a subset of the capabilites of a role.  We could make roles more fine grainied, but I would think that they should still be descriptive:  'Observer' for someone with readonly access, for example.02:39
jamielennoxright, my problem is that we push all this onto the user02:40
ayoungEach of the tasks that Heat has to do would then have a separate trust, with a token listing exactly the operations that the task has to perform02:40
jamielennoxadminstrators have this knowledge - the users really don't /shouldn't02:40
ayoungwell, no, we would need to provide tooling before this would be usable02:40
jamielennoxso things that exist in policy i'm happy to do, but this has you asking for a specific style of token ahead of time02:41
ayoungand the users should get a template for atoken02:41
*** mberlin1 has joined #openstack-keystone02:43
ayoungIt limits the exposure on a compute node.  So, launching a VM needs to hook that VMs nic up with a port set up by Neutron.   But the user already set up the port.  Its just the final link that needs to be done by the hypervisor.  One and done.  And then, if that Hypervisor is compromised, there is not a token left there that can be abused02:43
ayoungNova api or scheduler could even provide an api to craft the token request on behalf of the user02:43
*** morganfainberg is now known as morganfainberg_Z02:43
*** mberlin has quit IRC02:44
jamielennoxwe are getting back to a lot of load on keystone02:44
ayoungnope.  still done in one token generation call.02:44
ayoungwe could even use one token, it just could only be used a limited number of times per endpoint02:45
ayoungsay the token is bound to nova, glance, and neutron, with a count of 1 for glance and neutron.  Glance performs the download, and then sticks the token in the revocation tree02:45
ayoungits still valid on neutron, just not on glance02:45
harlowja_ayoung jamielennox  do u guys have a check to comment on https://review.openstack.org/#/c/88419/ (maybe when u are free)02:48
harlowja_i'd like to make sure the domain format is right02:49
*** radez is now known as radez_g0n302:49
harlowja_*see phils comment in that review, i guess we were supposed to find u at the summit but that didn't happen :)02:49
jamielennoxharlowja_: why are you exposing domains?02:50
harlowja_i'm fine with just user,project, but i'd suspect domain would be useful for certain cases (if say juju needs it/could use it)02:51
jamielennoxharlowja_: domain should really not need to be expose beyond keystone02:52
harlowja_k02:53
jamielennoxsame with from the comments project_domain_name etc all that is a product of using names which aren't unique02:54
harlowja_can u add that to the review, phil i think thought domain would be useful02:54
harlowja_sure, names not always unique, but unique at some companies ;)02:54
harlowja_but agreed, in general they aren't unique02:55
*** gabrielb has joined #openstack-keystone02:57
jamielennoxharlowja_: ok added some comments03:00
harlowja_thx03:00
jamielennoxin general i think you only want the user_id and either the domain_id or the project_id depending on what the token is scoped to03:00
*** gokrokve_ has joined #openstack-keystone03:00
*** schofield_away has joined #openstack-keystone03:01
harlowja_ya, in this case there wouldn't be a token (the metadata is accessible from the things inside the vm), i wouldn't think they'd have the token provided to them but would have to go get one03:01
harlowja_and this is partially about providing those things enough information to go get one03:02
harlowja_*one of the usages of it is this*03:02
harlowja_*other is to provide services that startup in the vm who the vm was created by (for various downstream services)03:02
*** xianghui has quit IRC03:03
*** gabrielbezerra has quit IRC03:03
*** anteaya has quit IRC03:03
*** Camisa has quit IRC03:03
*** schofield has quit IRC03:03
*** Camisa has joined #openstack-keystone03:03
*** Camisa has quit IRC03:03
*** Camisa has joined #openstack-keystone03:03
*** schofield_away is now known as schofield03:03
*** Camisa has quit IRC03:03
*** Camisa has joined #openstack-keystone03:04
ayoungjamielennox, when you get a chance, this one is kindof high priority https://review.openstack.org/#/c/94470/403:04
ayoungjamielennox, bknudson and I are both authors on it, so there is a shrinking pool of core reviewers03:04
*** Camisa is now known as Guest8525803:04
*** xianghui has joined #openstack-keystone03:05
*** anteaya has joined #openstack-keystone03:05
jamielennoxbut i didn't get through the whole proposal - this is just the general advice03:06
jamielennoxayoung: ergh, ldap03:08
*** serverascode has quit IRC03:08
*** gokrokve has quit IRC03:09
*** serverascode has joined #openstack-keystone03:10
*** hipster has joined #openstack-keystone03:10
ayoungjamielennox, we've had bknudson jdennis nkinder and myself all working on this...its pretty well beat on03:11
nkinderayoung, jamielennox: yeah, I can answer any questions on it03:11
ayoungnkinder, I'm looking at the https://review.openstack.org/#/c/94513/6/keystone/common/ldap/core.py,cm  and it looks prety straight forward03:12
ayoungnkinder, "each AVA of the RDNs must be the equal for the same attribute type. The03:14
ayoung      order isn't significant.   "  why is that?03:14
*** sbfox has joined #openstack-keystone03:14
nkinderayoung: that's referring to multiple RDNs, for example...03:14
nkinderayoung: dn: cn=foo+cn=bar,dc=example,dc=com03:14
nkinderthat is equivalent to "cn=bar+cn=foo,dc=example,dc=com"03:15
ayoungnkinder, so  cn=foo+cn=bar  == cn=bar+cn=foo  ?03:15
ayoungLDAP is lovely03:15
ayoungnkinder, we really need to get jdennis code upstream.  How many times do you think this has been miswritten in Python alone?03:16
nkinderayoung: my guess is most people just do upper()/lower() and a string comparison03:17
nkinderayoung: well, it's multiple naming attributes (not one)03:17
nkinderso the order doesn't matter03:17
nkinderayoung: it's not commonly used03:18
jamielennoxnkinder, ayoung: so why delete the test?03:20
nkinderjamielennox: it was previously overriden for ldap03:20
nkinderjamielennox: as it behaved differently.  This makes it behave the same as SQL, so the test override was removed03:20
*** gokrokve_ has quit IRC03:21
*** boris-42 has quit IRC03:23
jamielennoxso the thing i find weird here is that they've overriden the test which means someone somewhere knew that LDAP behaved differently to SQL03:23
jamielennoxthe actual LDAP change doesn't seem so bad03:23
*** sbfox has quit IRC03:24
nkinderjamielennox: I thinkit was overridden by the SQL patch, which landed this morning (let me check)03:27
nkinderjamielennox: yep - https://review.openstack.org/#/c/94396/03:28
nkinderjamielennox: "someone" in this case was bknudson, so he knew it was different since he split the SQL and LDAP work today.03:28
*** dstanek is now known as dstanek_zzz03:29
*** dstanek_zzz is now known as dstanek03:29
*** boris-42 has joined #openstack-keystone03:29
jamielennoxnkinder: so how does that review fix the bug? i can read the sql one easily enough03:37
jamielennoxbut the review would seem to make use (correctly) of the underlying comparison functions03:37
jamielennoxbut it is the same set of comparisons being made03:37
ayoung jamielennox its in the order of comparisons03:38
ayoungline 9203:38
nkinderjamielennox: you are looing at this, right? https://review.openstack.org/#/c/94470/4/keystone/assignment/backends/ldap.py03:38
ayounginstead of comparing two ids, we compare two dns03:38
ayoungit used to be  self.user._dn_to_id(a.user_dn)03:39
jamielennoxnkinder: yes03:39
ayoungwhich is an id.  But the id looses the context.  the DN makes sure a user and a group are distinct in this case03:39
nkinderjamielennox: ok, so the original code did a string comparison of the id03:40
nkinderjamielennox: in this case, the id was just an attribute value from ldap like "foo"03:40
jamielennoxayoung: right, but ignoring the subtleties of ldap dn's hte actual operations would apear the same03:41
*** praneshp has quit IRC03:41
nkinderjamielennox: attribute.user_dn contains both user and group DNs03:41
nkinder...this is despite the face that it's named attribute.user_dn03:41
nkinders/face/fact/03:41
ayoungjamielennox, so the id would be  ayoung,  whereas the dn would be uid=ayoiung,ou=users....03:41
nkinderso "cn=foo,ou=groups,..." and "cn=foo,ou=users,..." drops the rest of the DN.  Calling dn_to_id() makes them both plain "foo".03:42
jamielennoxah03:42
nkinderyeah03:42
nkinderso we just compare the DN, as we have the user DN, and the assignment has a full DN already too.03:43
nkinderjamielennox: ...but, the comparison needs to be smarter than just a string comparison, hence this patch - https://review.openstack.org/#/c/94513/03:43
ayoungjamielennox, I wrote the original comparitor when there was only users, and it didn't get updated when we added groups.  Notice that the groups code was already this way, we just updated from a string compare to a DN compare03:44
nkinderyeah, string compare has issues with things like ',' characters in the attribute value used for id03:45
nkinderthat's why we need all of the new DN comparison stuff from the other patch03:45
jamielennoxyep, i knew string compare was not right here - though often used03:46
jamielennoxalright, +2ed03:47
*** stevemar has joined #openstack-keystone03:47
nkinderjamielennox: please take a look at the chain of patches it depends on03:48
nkinderjamielennox: the DN compare one might seem a bit complex since you're not super familiar with LDAP, but it's not too bad03:48
jamielennoxwell LDAP names are the same concept as x509 names, so i know the basics03:49
jamielennox(well vice versa)03:50
jamielennoxdidn't jdennis write a file almost exactly like this ages ago?03:51
jamielennoxhe had one for der/pem, i thought he had one for ldap as well03:51
*** hipster has quit IRC03:55
*** stevemar has quit IRC04:15
*** gokrokve has joined #openstack-keystone04:20
*** marcoemorais has joined #openstack-keystone04:21
*** Abhijeet has joined #openstack-keystone04:29
*** marcoemorais1 has joined #openstack-keystone04:32
*** marcoemorais has quit IRC04:34
ayoungjamielennox, yes, he did it for FreeIPA, and I want him to resubmit it for Keystone....actually, we were saying it should go to upstream python-ldap04:36
ayoungand...goodnight04:36
*** ayoung has quit IRC04:36
*** gokrokve has quit IRC04:38
*** gokrokve has joined #openstack-keystone04:44
*** gokrokve has quit IRC04:47
openstackgerritSergey Nikitin proposed a change to openstack/keystone: Check that the user is dumb moved to the common method  https://review.openstack.org/8851704:48
*** daneyon has joined #openstack-keystone04:48
*** daneyon has quit IRC04:51
*** daneyon has joined #openstack-keystone04:52
*** gokrokve has joined #openstack-keystone05:14
*** harlowja_ is now known as harlowja_away05:17
*** dstanek is now known as dstanek_zzz05:23
*** daneyon has quit IRC05:27
openstackgerritSergey Nikitin proposed a change to openstack/keystone: Check that the user is dumb moved to the common method  https://review.openstack.org/8851705:32
*** ukalifon has joined #openstack-keystone05:39
*** praneshp has joined #openstack-keystone05:55
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/9028806:00
*** fin09pcap has joined #openstack-keystone06:06
*** dstanek_zzz is now known as dstanek06:14
*** fin09pcap has quit IRC06:15
*** dstanek is now known as dstanek_zzz06:24
*** gokrokve has quit IRC06:31
*** AJaeger has left #openstack-keystone06:33
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/9124007:12
*** dstanek_zzz is now known as dstanek07:15
*** BAKfr has joined #openstack-keystone07:16
*** Guest85258 has quit IRC07:17
*** praneshp has quit IRC07:23
*** Abhijeet has quit IRC07:23
*** dstanek is now known as dstanek_zzz07:25
*** Guest85258 has joined #openstack-keystone07:27
*** leseb has joined #openstack-keystone07:45
*** dstanek_zzz is now known as dstanek07:54
*** henrynash has joined #openstack-keystone08:00
*** dstanek is now known as dstanek_zzz08:04
*** dstanek_zzz is now known as dstanek08:07
*** dstanek is now known as dstanek_zzz08:17
*** afazekas_wfp has joined #openstack-keystone08:22
*** d0ugal_ has joined #openstack-keystone08:29
*** jamielennox is now known as jamielennox|away08:37
*** d0ugal_ has quit IRC08:39
*** henrynash has quit IRC08:42
*** d0ugal_ has joined #openstack-keystone08:46
*** andreaf has joined #openstack-keystone08:54
*** marcoemorais1 has quit IRC09:03
*** d0ugal_ has quit IRC09:05
*** dstanek_zzz is now known as dstanek09:08
*** afazekas_wfp is now known as afazekas09:11
*** d0ugal_ has joined #openstack-keystone09:14
*** d0ugal_ has quit IRC09:17
*** dstanek is now known as dstanek_zzz09:18
*** d0ugal_ has joined #openstack-keystone09:22
*** d0ugal has quit IRC09:22
*** d0ugal_ is now known as d0ugal09:22
*** d0ugal has quit IRC09:25
*** d0ugal has joined #openstack-keystone09:25
*** henrynash has joined #openstack-keystone09:34
*** henrynash_ has joined #openstack-keystone09:41
*** henrynash has quit IRC09:43
*** henrynash_ is now known as henrynash09:43
*** dstanek_zzz is now known as dstanek10:08
*** dstanek is now known as dstanek_zzz10:18
*** dstanek_zzz is now known as dstanek11:04
*** xianghui has quit IRC11:21
*** radez_g0n3 is now known as radez11:44
*** radez is now known as radez_g0n311:44
*** radez_g0n3 is now known as radez11:44
*** dims has joined #openstack-keystone11:53
*** afaranha has left #openstack-keystone11:55
*** erecio has joined #openstack-keystone11:58
*** rodrigods has joined #openstack-keystone12:00
*** stevemar has joined #openstack-keystone12:06
*** diegows has joined #openstack-keystone12:18
*** dstanek is now known as dstanek_zzz12:30
*** gordc has joined #openstack-keystone12:34
*** rodrigods_ has joined #openstack-keystone12:38
*** afaranha has joined #openstack-keystone12:39
afaranhaHello, does anyone got this error using keystoneclient in python? http://paste.openstack.org/show/81145/12:39
afaranhathe error is NotFound: The resource could not be found. (HTTP 404)12:39
*** rodrigods_ has quit IRC12:39
openstackgerritKristy Siu proposed a change to openstack/identity-api: Trusted Attributes Policy for External Identity Providers  https://review.openstack.org/6048912:41
*** ayoung has joined #openstack-keystone12:41
openstackgerritKristy Siu proposed a change to openstack/identity-api: Trusted Attributes Policy for External Identity Providers  https://review.openstack.org/6048912:43
*** dstanek_zzz is now known as dstanek12:45
rodrigodsayoung, saw your comments, have some questions about them. I'll catch up with you later, ok?12:53
ayoungrodrigods, now is ok12:53
ayoungrodrigods, so in general, you don't want to do string manipulations on things like URLs12:54
ayoungthere are libraries that do it "right"  and we have them12:54
rodrigodsayoung, yeah, I agree. I tried to use urllib.parse.urlencode12:54
ayoungif we had made sensible parameters for the role_assignments  it would have worked12:54
ayoungI'd try doing this12:54
ayounguser = {"id": user_id}  and see what happends12:54
ayounghappends12:55
ayounghappens12:55
* ayoung smarter than keyboard. No me not12:55
rodrigodsayoung, i know... the issue is with queries without a value12:55
ayounghenrynash, ^^ is your mess.  why does role_assignments do params like user.id12:55
rodrigodslike the "effective" one for /role_assingments12:55
ayounghmmm12:55
ayoungso does the dictionary approach work for the others?12:56
rodrigodsayoung, yeah, that's why I'm first using urllib.parse.urlencode for the regular ones12:57
ayoungcool12:57
ayoungthere must be something in it for effective12:57
rodrigodsayoung, i tried to find something in the lib that would fit this case, but haven't found =/12:58
*** afazekas is now known as afazekas_mtg12:59
ayoungis it a true/false thing?13:00
rodrigodsyeah13:00
rodrigodsbut the url accepts just the query key13:01
rodrigodswithout a value13:01
ayoungWhat happens if you pass it in =False?  http://url?effective=False13:01
rodrigodsayoung, actually I didn't test it =)13:02
rodrigodswith effective=true or effective=false13:02
rodrigodsbut if the positive case works with effective=true we can add the effective key only if the argument is true and do not add it otherwise13:03
*** afazekas_mtg has quit IRC13:04
dstanekstevemar: no details :-(  https://blueprints.launchpad.net/keystone/+spec/trusted-attribute-issuing-policy13:05
henrynashayoung: just on a call, then will look13:06
stevemardstanek, there is a wiki link under 'full specs'13:06
dstanekstevemar: not much there13:08
ayoungrodrigods, ++13:08
dolphmwe regularly get bugs filed that are red hat packaging issues - where can i direct those people?13:09
dstanekstevemar: i was hoping to at least see how it works with mapping13:09
dstanekdolphm: /dev/null? :-P13:09
stevemardstanek, that would be nice13:09
rodrigodsayoung, geat, will test this approach, if it works will update the patch13:10
dolphmgoogling for "rdo bugs" leads to a forum thread of people asking the same question... someone provides a link that seems legit, but it requires login13:10
*** thedodd has joined #openstack-keystone13:10
ayoungdolphm, Bugzilla.  I'll get you a link13:10
dstanekstevemar: do you understand what they are trying to do?13:10
dolphmayoung: https://bugzilla.redhat.com/ ?13:10
dolphmayoung: or something more specific?13:10
ayoungdolphm, more specific comeing up13:11
ayounghttps://bugzilla.redhat.com/enter_bug.cgi?product=RDO13:11
ayoungdolphm, could be Fedora as well, but RDO is probably the right place13:12
ayoungfor Fedora it would be https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora13:12
dstanekstevemar: i hate seeing API reviews when there are no code reviews to back it up - smells like BUFD13:13
ayoungdolphm, Component should be openstack-keystone  for either13:13
ayoungdstanek, I'm with you on this.13:13
dolphmayoung: both of those links just get me a login screen13:14
ayoungI'd rather we made everything go in as an extension, then reverse the API doc, and then promote it13:14
ayoungdolphm, I guess I am already logged in13:14
ayoungBut don't you need a launchpad login to report bugs upstream in Keystone, too?  A Bugzilla account for Red Hat etc packaging is pretty much the norm13:15
dolphmayoung: our bug database is open at least13:15
dolphmayoung: but yeah, you need to create an account to file a bug13:15
ayoungdolphm, you can query without a login, just not add13:15
dstanekayoung: yeah, i feel like once the spec is documented in the API docs it should be available13:15
dstanekyou also have the problem of changes needed to the spec because of unforeseen implementation issues13:16
*** bknudson has left #openstack-keystone13:16
stevemardstanek, apparently they have some code?13:16
dolphmlol if you search bugzilla for RDO bugs, you get an error that says "this list is too long for Red Hat Bugzilla's little mind"13:17
ayoungfor example...   https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Community&component=openstack-keystone&list_id=2498066&product=RDO&query_format=advanced13:18
*** afazekas_mtg has joined #openstack-keystone13:19
ayoungdolph  ^^ was produced from the Bugzilla search page13:19
*** thedodd has quit IRC13:19
ayoungwhen I added openstack-keystone as a component13:19
ayounghttps://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&classification=Community&component=python-keystoneclient&list_id=2498083&product=RDO&query_format=advanced13:20
dolphmthat's a really long link lol13:20
dolphmi'm running with https://bugzilla.redhat.com/buglist.cgi?product=RDO13:20
ayoungis pretty much everything for Keystone and client that is in the works13:20
ayounger...13:20
ayoungdropped keystone....13:21
ayoungyeah, the links get longer with more query params.  Its annoying.  We keep a bunch in our internal etherpads for regular discussions13:21
ayounghttps://bugzilla.redhat.com/buglist.cgi?classification=Community&component=openstack-keystone&component=python-keystoneclient&list_id=2498100&product=RDO&query_format=advanced13:21
ayoung^^ drops the status field off, which shows all.  Probably can ftrop the &query_format=advanced  as well....13:22
ayounghttps://bugzilla.redhat.com/buglist.cgi?classification=Community&component=openstack-keystone&component=python-keystoneclient&list_id=2498100&product=RDO13:22
ayounglist id is also not needed, now that I look13:22
ayounggets added in though once you search13:23
dstanekstevemar: actually there is some interesting detail hidden in comments https://review.openstack.org/#/c/60489/9/openstack-identity-api/v3/src/markdown/identity-api-v3-os-idp-issuing-policy-ext.md,cm13:23
ayounghttps://bugzilla.redhat.com/buglist.cgi?classification=Community&component=openstack-keystone&component=python-keystoneclient&product=RDO13:23
ayoungdolphm, ^^ should be reasonable13:23
stevemardstanek, ah, i see line 21 has some interesting comments13:25
stevemardstanek, i'm not keen on the fact that if the list isn't specified, then the mapping fails13:27
dstanekstevemar: what is an untrusted IdP?13:28
dstanekstevemar: the mapping is effectively a while list (similar in concept to a list of trusted attributes) so i don't see the point in the blueprint13:29
stevemardstanek, i think we already take care of that, by defining idps in /v3/os-federation/identity_providers/{idp}13:29
dstanekif you don't trust the IdP why would you add it? if you don't trust the attribute why would you add a mapping for it?13:29
stevemardstanek, that's what marekd|away said13:30
henrynashrodrigods: ok, free of my call…can you re-state your issue with role assignment api?13:35
*** bknudson has joined #openstack-keystone13:37
*** r-daneel has joined #openstack-keystone13:38
*** nkinder has quit IRC13:42
dolphmanyone ever tried to append/add Message objects together?13:42
lbragstaddolphm: are you working with translations? i18n stuff?13:43
rodrigodshenrynash, is just a question =). Can I use "effective=true", instead of just "effective"? The idea is to use a lib to build the url, and it doesn't handle "valueless" queries13:45
henrynashrodrigods: I think you should be able to yes, let me check quickly for you13:45
lbragstadI know jecarey and jungleboyj (both should be in -dev at some point) did a lot of work with message objects for the i18n translation stuff.13:46
lbragstadso they might have some experience on what you're trying to do13:46
henrynashrodigods: yep, that should work fine13:47
dolphmlbragstad: yes13:47
dolphmlbragstad: trying to merge two translated messages together13:47
bknudsondolphm: my understanding is that if you have a Message with %s and then the sub is a Messsage they'll be recursively translated13:48
lbragstaddolphm: how were you adding them together before?13:49
bknudsone.g., LOG.info(_LI('Message: %s), _LI('Turn off debug you idiot'))13:49
dstanekdolphm: what exactly are you looking to do?13:50
bknudsongetting back to https://bugs.launchpad.net/keystone/+bug/1309228 --13:51
uvirtbotLaunchpad bug 1309228 in keystone/icehouse "[OSSA 2014-015] User gets group auth if same id (CVE-2014-0204)" [High,In progress]13:51
bknudsonI think I'm going to squash the master changes13:51
bknudsonsince the OSSA note was already sent out and it only has https://review.openstack.org/94396 and https://review.openstack.org/94470 as the master fixes.13:51
bknudsonlooks like they all passed tests13:53
dolphmdstanek: pretty much what bknudson just posted13:54
dolphmlbragstad: i'm trying to append a new message13:55
dolphmrather, extend a dynamic message with a static message13:55
dolphmboth of which are translated separately13:55
bknudsonLOG.info(_LI('%s%s), original_message, _LI('Turn off debug you idiot') if CONF.debug else '')13:55
*** joesavak has joined #openstack-keystone13:56
dolphmbknudson: but i'm not doing it in a LOG call13:56
bknudson_LI('%s%s') % (original_message, _LI(' Turn off debug you idiot') if CONF.debug else '')13:58
openstackgerritDolph Mathews proposed a change to openstack/keystone: indicate that sensitive messages can be disabled  https://review.openstack.org/9487113:58
rodrigodshenrynash, thanks =)13:58
dolphmbknudson: ^13:58
rodrigodsayoung, will update the patch, hope you give a +2 =)13:58
henrynashrodrigods: np13:58
dolphmbknudson: can i just call translate on them and return the unicode? :-/14:00
bknudsondolphm: if you know the language to translate to14:00
dolphmbah14:00
*** gokrokve has joined #openstack-keystone14:01
bknudsondolphm: something like - return _('%s%s') % (message or self.message_format % kwargs, amendment or '')14:03
openstackgerritBrant Knudson proposed a change to openstack/keystone: LDAP fix for get_roles_for_user_and_project user=group ID  https://review.openstack.org/9447014:03
bknudson^ is the 3 reviews squashed into 1 -- so fixes the problem that was introduced earlier with , in a DN14:05
dstanekstevemar: getting closer!14:05
dolphmbknudson: that failed a bit better, thanks :)14:08
openstackgerritDolph Mathews proposed a change to openstack/keystone: indicate that sensitive messages can be disabled  https://review.openstack.org/9487114:14
dolphmbknudson: thank you, sir!14:14
openstackgerritDolph Mathews proposed a change to openstack/keystone: indicate that sensitive messages can be disabled  https://review.openstack.org/9487114:15
bknudsondolphm: thanks for making that change, will make my life easier14:15
stevemardstanek, getting closer to what?14:15
dolphmbknudson: ha, why?14:16
dstanekstevemar: got a response on my -1 from David14:16
bknudsondolphm: I get the same complaints about sensitive info in the logs when they have debug turned on14:20
*** xianghui has joined #openstack-keystone14:20
*** xianghui has quit IRC14:21
dstanekwill y'all kill me if i make a few proposals to *fix* drivers? part of our performance issues are cause by the need to know everything by ID14:23
*** afazekas_mtg has quit IRC14:24
*** david-lyle has joined #openstack-keystone14:26
dolphmdstanek: bp?14:27
*** afazekas has joined #openstack-keystone14:29
dstanekdolphm: i would probably propose a spec - i was hacking on this a bit yesterday so i have a feel for what i want14:30
*** nkinder has joined #openstack-keystone14:33
*** browne has joined #openstack-keystone14:50
*** mberlin1 is now known as mberlin14:55
*** thedodd has joined #openstack-keystone14:56
bknudsondolphm: are we supposed to manually abandon patches? e.g., https://review.openstack.org/#/c/77514/ hasn't been touched for a few week15:05
dstanekbknudson: whoa, Ray Chen is a bit harsh15:08
bknudsondstanek: I wonder where he's getting assertEqual(first, second, msg=None) -- I guess from python docs rather than testtools.15:19
dstanekbknudson: yes, the Python docs don't care about order15:20
bknudsonhttps://review.openstack.org/94470 passed jenkins so if people want to review it -- it's for security fix15:23
dstanekbknudson: the rationale i was given a while back is that testtools expects that order to make messages nicer, but it appears that they don't use this ordering in their own docs15:25
bknudsondstanek: I thought the code was the docs?15:26
bknudsonhttps://github.com/testing-cabal/testtools/blob/master/testtools/testcase.py#L31315:26
*** packet has joined #openstack-keystone15:27
dstanekbknudson: interesting here http://testtools.readthedocs.org/en/latest/for-test-authors.html they sometimes use the constant first and other time second15:27
bknudsondstanek: -1 on their docs.15:28
bknudsonI'm going to use this -- http://testtools.readthedocs.org/en/latest/for-test-authors.html#testcase-patch15:29
*** richm has joined #openstack-keystone15:33
openstackgerritJuan Manuel Ollé proposed a change to openstack/keystone: Adding Role for an unexisting user should fail.  https://review.openstack.org/9398215:36
*** juanmo has joined #openstack-keystone15:38
*** stevemar has quit IRC15:38
*** daneyon has joined #openstack-keystone15:44
*** daneyon has quit IRC15:47
*** dstanek is now known as dstanek_zzz15:47
*** daneyon has joined #openstack-keystone15:47
*** bknudson has quit IRC16:00
*** sbfox has joined #openstack-keystone16:02
*** BAKfr has quit IRC16:04
*** bknudson has joined #openstack-keystone16:05
*** marcoemorais has joined #openstack-keystone16:06
*** gokrokve has quit IRC16:10
*** gokrokve has joined #openstack-keystone16:12
*** amcrn has joined #openstack-keystone16:13
*** dstanek_zzz is now known as dstanek16:16
*** gyee has joined #openstack-keystone16:17
*** afazekas has quit IRC16:22
*** gokrokve has quit IRC16:24
*** daneyon has quit IRC16:25
*** henrynash has quit IRC16:25
*** BAKfr has joined #openstack-keystone16:29
*** henrynash has joined #openstack-keystone16:30
*** sbfox has quit IRC16:30
*** leseb has quit IRC16:32
*** praneshp has joined #openstack-keystone16:38
*** sbfox has joined #openstack-keystone16:43
ayoungnkinder, lets say a user authenticates to Horizon using SAML, and then, in order to get a Keystone token on behalf of the user, Horizon had to provide the origianl SAML assertion along with its request.  The resulting exposue would be the same as S4U2Proxy, right?16:44
ayoungassuming, of course, that the origianl SAML assertion was somehow specified to be used on Horizon in the first place16:46
ayoung <saml:Audience>https://appname.younglogic.com</saml:Audience>16:46
ayoungfrom http://adam.younglogic.com/resources/adam_example.saml16:46
ayoungnkinder, and openid connect is similar in its approach:  http://openid.net/specs/openid-connect-basic-1_0.html#IDToken16:50
*** praneshp has left #openstack-keystone16:50
*** praneshp has joined #openstack-keystone16:51
openstackgerritMatt Fischer proposed a change to openstack/python-keystoneclient: Add support for extensions-list  https://review.openstack.org/9297816:51
*** dstanek is now known as dstanek_zzz16:53
*** harlowja_away is now known as harlowja_16:54
*** dstanek_zzz is now known as dstanek17:00
ukalifonayoung: a little off-topic: If I use a token to get another token, should the new token provide me the same privilages? It seems like it gives me none whatsoever. I get "forbidden" on everything.17:03
ayoungits personal17:03
ayoungdid you ask for a new token with any scope?17:03
ukalifonno there was no scope in the request17:04
ayoungthen you got back an unscoped token17:05
*** nkinder_ has joined #openstack-keystone17:05
*** nkinder_ has quit IRC17:05
ukalifonayoung: should I ask for a token that has the same scope as the original? Does an "unscoped token" mean "no privilages"?17:07
ayoungno reason to do that17:07
ayoungit won';t have a long life span17:07
ayoungHorizon currently only holds a token for the current project17:07
ayoungIdeally, they would not do that, but its where we are today:17:07
*** Guest85258 has quit IRC17:11
*** Camisa has joined #openstack-keystone17:11
*** Camisa has joined #openstack-keystone17:11
*** gokrokve has joined #openstack-keystone17:21
*** dims has quit IRC17:24
openstackgerritA change was merged to openstack/keystone: Fix version links to docs.openstack.org  https://review.openstack.org/9265317:39
*** cds has joined #openstack-keystone17:41
*** gyee has quit IRC17:53
*** sbfox has quit IRC18:00
*** sbfox has joined #openstack-keystone18:01
*** dstanek is now known as dstanek_zzz18:01
*** morganfainberg_Z is now known as morganfainberg18:02
nkinderukalifon: this describes how authenticating with a token works (along with unscoped tokens) - https://blog-nkinder.rhcloud.com/?p=10118:02
nkinderukalifon: it also explains how I think it should be changed in the future.18:02
*** dstanek_zzz is now known as dstanek18:03
ukalifonthanks18:03
*** erecio_1 has joined #openstack-keystone18:04
morganfainbergayoung, dolphm, we have a specs repo http://git.openstack.org/cgit/openstack/identity-specs/tree/18:04
morganfainbergayoung, dolphm, I'll get the base structure in place as a review shortly.18:04
morganfainbergbknudson, nkinder, henrynash, dstanek, lbragstad, ^18:04
ayoungmorganfainberg, take my repo as a starting state?18:04
openstackgerritA change was merged to openstack/keystone: Reduce log noise on expired tokens  https://review.openstack.org/9380118:05
morganfainbergayoung, was going to look at yours specifically as part of that basis18:05
bknudsonlooks pretty sparse18:05
ayoungcool.  you might not want the whole history18:05
henrynashmorganfainberg: yeeha!18:05
nkindermorganfainberg: great!18:05
ayoungmorganfainberg, for example, I have a revert commit in mine you should probably squash18:05
lbragstadmorganfainberg: awesome!18:05
*** juanmo1 has joined #openstack-keystone18:05
morganfainbergayoung, exactly, plus need to get the right structure for ksc18:05
*** juanmo has quit IRC18:06
ayoungmorganfainberg, so, we have no grouping mechanism for client specs18:06
morganfainbergall current keystone core are core on the spec repo.18:06
*** erecio has quit IRC18:06
ayoungwe don;t target a specific release, so...maybe just "active and implemented"18:06
morganfainbergayoung, the idea is we will have a "Keystone Client" named repo, and when we release we move implemented BPs to the numbered release18:06
ayoungseparate repo?18:07
morganfainbergayoung, same repo, separate dir18:07
ayoungok, yeah, that was what I was saying18:07
morganfainberg specs/identity/keystoneclient/<release #>/bp18:07
ayoungmorganfainberg, so I can post the whole repo for review....18:07
morganfainbergayoung, yours is on github right?18:08
ayoungmorganfainberg, https://github.com/admiyo/keystone-specs/18:09
*** ukalifon has quit IRC18:10
morganfainbergayoung, do we need a separate template for ksc?18:11
ayoungmorganfainberg, how about: eventually?18:11
ayounglike, not right up front, but we should18:11
morganfainbergayoung, works for me. also there are still some "nova" isms in your template18:12
ayoungthe JSON-Schema one had no analog18:12
morganfainbergright.18:12
morganfainbergdo we want to keep that in there? it doesn't really make sense at the moment18:12
bknudsonkeystone should be doing input validation18:12
ayoungmorganfainberg, my question was, since it started with the Nova one, should we keep the git history to give credit?18:13
morganfainbergayoung, too late for that :P18:13
*** andreaf has quit IRC18:13
ayoungNope18:13
ayoungWe could do a merge from the nova repo18:13
morganfainbergayoung, at this point we'd need to have infra intervene on that, usually you specify a source for the repo when they create it to preserve history18:14
morganfainbergayoung, gerrit workflow iirc doesn't like people pushing merge commits in18:14
ayoungmorganfainberg, if we can commit, we can do it18:14
ayoungbut...I can just copy the files over and the initial commit can point to the nova repo18:14
bknudsonI think there's different permissions for merge and fast-forward pushes18:14
morganfainbergbknudson, ++18:15
morganfainbergbknudson, there are, I run a gerrit server today18:15
ayoungmorganfainberg, there are 116 commits including mine18:17
*** sbfox has quit IRC18:17
morganfainbergayoung, example https://github.com/openstack/tripleo-specs another project did it independantly18:17
morganfainbergayoung, i am fairly certain we can't do a merge commit through gerrit. it complains.18:18
openstackgerritMatt Fischer proposed a change to openstack/python-keystoneclient: Add support for extensions-list  https://review.openstack.org/9297818:20
morganfainbergayoung, are you proposing the initial commit or should I? (doesn't matter to me)18:23
ayoungmorganfainberg, your call...you have more access to the git repo than I do, as I need to work through gerrit, right?18:24
*** dims has joined #openstack-keystone18:24
morganfainbergayoung, we have equal access. it has to go through gerrit no matter what18:25
*** sbfox has joined #openstack-keystone18:25
ayoungmorganfainberg, You have my repo:  reset HEAD to  Converted from Nova to Keystone  and push, would be my suggestion18:26
morganfainbergayoung, ++ will propose you can review then.18:26
ayoungmorganfainberg, that is 116 patches...18:26
openstackgerritRodrigo Duarte Sousa proposed a change to openstack/python-keystoneclient: Add /role_assignments endpoint support  https://review.openstack.org/9157818:26
morganfainbergayoung, i'm squashing it all.18:26
ayoungalternatively, I can squash and propse18:26
ayoungok...do that18:27
morganfainbergayoung, :)18:27
ayoungmorganfainberg, it feels wrong, why not ask if there is a way we can do the fork from nova?18:27
rodrigodsayoung, ^^18:30
ayoungrodrigods, looks much better18:31
ayoungrodrigods, have you attempted to use this from a script yet?18:32
rodrigodsayoung, effective=True? Or the general feature?18:32
ayoungthe whole parameter thing, especiall effective18:33
*** dstanek is now known as dstanek_zzz18:33
rodrigodsayoung, yeah... I have a patch in Horizon that already uses this =)18:33
*** htruta has joined #openstack-keystone18:33
vhowardcan anyone help point me in the right direction to figure out how to break out my own identity driver for ldap auth so that it can be seperate from the main keystone code base?  i'm a bit lost and so far added our own subclass in the keystone/identity directory with a custom name…probably totally wrong lol18:33
ayoungrodrigods, a stand alone script would be very nice18:34
rodrigodsayoung, https://review.openstack.org/#/c/92412/18:34
ayoungseparate patch, or even a paste18:34
*** amcrn_ has joined #openstack-keystone18:34
rodrigodsayoung, ok, will write it here =)18:34
*** praneshp_ has joined #openstack-keystone18:35
ayoungrodrigods, but you've tested it with horizon, which is what I cared about18:35
*** amcrn has quit IRC18:35
rodrigodsayoung, and also: https://review.openstack.org/#/c/91634/218:37
*** praneshp has quit IRC18:37
*** praneshp_ is now known as praneshp18:37
rodrigodsayoung, but if you need a standalone script, I can write one here18:37
ayoungrodrigods,  please do, but I won't delay review for it.18:38
*** erecio_1 has quit IRC18:38
ayoungrodrigods, now get stevemar to back up his review with a +218:39
*** erecio_1 has joined #openstack-keystone18:39
*** erecio_1 has quit IRC18:40
*** erecio_1 has joined #openstack-keystone18:41
rodrigodsayoung, great!!! thanks for your feedback18:41
rodrigodsayoung, will provide a script in a few minutes18:41
*** ukalifon1 has joined #openstack-keystone18:41
raildo1ayoung: what do i need to review a patch with a +2? hahaha18:50
ayoungraildo1, first, find a patch that already has a +218:50
nkinderbknudson: did you mean to change something in patch 5 for https://review.openstack.org/#/c/94470 ?18:56
nkinderbknudson: it looks the same as patch 4.  We're you intending to remove the comment about AD?18:57
bknudsonnkinder: it's got all the other changes squashed18:57
bknudsonnkinder: I forgot to remove the comment18:57
bknudsonnkinder: I squashed the changes because there was already an OSSA note sent out saying that the fix for icehouse is in https://review.openstack.org/#/c/9447018:58
bknudsonoops, the fix for juno18:58
nkinderbknudson: ok18:58
bknudsonI'd remove the comment in a separate review at this point18:58
nkinderbknudson: yeah, let's put this one to bed18:59
*** leseb has joined #openstack-keystone19:06
*** ukalifon1 has quit IRC19:10
ayoungmorganfainberg, can you pull the trigger on https://review.openstack.org/#/c/94470/5  ?19:12
openstackgerritMorgan Fainberg proposed a change to openstack/identity-specs: Initial Commit for Identity-specs repo  https://review.openstack.org/9498719:20
openstackgerritMorgan Fainberg proposed a change to openstack/identity-specs: Initial Commit for Identity-specs repo  https://review.openstack.org/9498719:23
*** dstanek_zzz is now known as dstanek19:24
openstackgerritMorgan Fainberg proposed a change to openstack/identity-specs: Initial Commit for Identity-specs repo  https://review.openstack.org/9498719:27
*** gordc has left #openstack-keystone19:29
*** serverascode has quit IRC19:35
*** serverascode has joined #openstack-keystone19:37
openstackgerritMorgan Fainberg proposed a change to openstack/identity-specs: Initial Commit for Identity-specs repo  https://review.openstack.org/9498719:40
rodrigodsayoung, here sir: http://paste.openstack.org/show/81180/19:41
morganfainbergok initial specs repo commit ready for review.19:41
ayoungrodrigods, very nice.  submit it and we'll review it.  Put it in python-keystoneclient/examples/scripts.  Feel free to tag as a WIP if you are not ready for it to be prime time19:42
ayoungmorganfainberg, you rock, sir.19:42
morganfainbergayoung, there is something wonky in the doc build though19:42
morganfainbergayoung, http://docs-draft.openstack.org/87/94987/4/check/gate-identity-specs-docs/7932a12/doc/build/html/ doesn't look "right"19:42
ayoungmorganfainberg, what looks off?  What am I looking for?19:43
morganfainbergayoung, look at the header19:44
ayoungmorganfainberg, didn't get processed, did it19:44
morganfainbergayoung, ok fixed it next patch incoming19:44
morganfainbergayoung, yeah19:44
ayoung==—=19:44
openstackgerritMorgan Fainberg proposed a change to openstack/identity-specs: Initial Commit for Identity-specs repo  https://review.openstack.org/9498719:44
*** andreaf has joined #openstack-keystone19:44
morganfainbergthat should do it19:44
morganfainberghmm19:45
dstanekmorganfainberg: what does it mean to re-propose a spec?19:47
openstackgerritMorgan Fainberg proposed a change to openstack/identity-specs: Initial Commit for Identity-specs repo  https://review.openstack.org/9498719:47
morganfainbergdstanek, e.g. if the spec was proposed prior to us adopting the formal structure or for the next release19:47
dstanekmorganfainberg: you mean just during the transition to this repo?19:49
morganfainbergdstanek, bascially yes19:50
dstanekit reads like all approved blueprint will have to be re-approved for every release; doesn't even qualify that completed blueprints don't need to be re-approved19:51
morganfainbergdstanek, and if it wasn't completed for say Juno, you'd need to re-propose the spec for K19:51
morganfainbergdstanek, completed blueprints wouldn't need to be re-proposed.19:51
morganfainbergdstanek, if the BP wasn't completed for Juno, it's not a guarantee we'd want it for K (there might be good reasons it wasn't finished). Alternatively, we might just rubberstamp it for the next release19:52
morganfainbergdstanek, feel free to comment, happy to rephrase/fix wording now before we use it :)19:52
*** gyee has joined #openstack-keystone19:55
ayoungmorganfainberg, "Idenity Program Specifications"20:02
ayounghttp://docs-draft.openstack.org/87/94987/6/check/gate-identity-specs-docs/11acdde/doc/build/html/20:02
morganfainbergayoung, this is why we review :)20:02
morganfainbergbut Idenity is cooler sounding20:02
morganfainberg>.>20:02
*** leseb has quit IRC20:03
gyeemorganfainberg, hooray for the spec repo! :)20:03
morganfainbergayoung, i'll hold on subsequent patchsets until everyone has given a once over - solve all the issues at once if possible20:04
ayoung++20:04
morganfainberggyee, I totally agree. (though I want storyboard to cover the need for the spec repo longterm tbh)20:05
*** cds has quit IRC20:10
*** andreaf has quit IRC20:11
dstanekmorganfainberg: does storyboard capture the conversations like gerrit does?20:16
*** dims has quit IRC20:16
*** therve has quit IRC20:25
*** stevemar has joined #openstack-keystone20:29
morganfainbergdstanek, no idea. probably not yet20:31
morganfainbergdstanek, but storyboard is built for our needs specifically (OpenStack), so I'm sure it could capture the conversations if we wanted it to.20:31
*** amcrn_ has quit IRC20:32
*** nkinder has quit IRC20:37
bknudsonshouldn't this little client program work? http://paste.openstack.org/show/81186/20:40
rodrigodsstevemar, time for +2 again? =) https://review.openstack.org/#/c/91578/20:40
bknudsonI also had to set the project_name on the client, then it was happy20:43
stevemarbknudson, what do you mean?20:44
bknudsonstevemar: http://paste.openstack.org/show/81186/ -- when I changed the program to also pass the project_name it worked.20:44
*** andreaf has joined #openstack-keystone20:49
*** nkinder has joined #openstack-keystone20:51
*** joesavak has quit IRC20:52
bknudsonI wish I knew how the positional decorator was supposed to work -- https://review.openstack.org/#/c/79774/4/keystoneclient/v3/services.py20:53
bknudsonis the count supposed to be updated at line 53?20:53
bknudsonand why is the count set to 1 at line 40??20:53
*** browne1 has joined #openstack-keystone21:02
*** juanmo1 has quit IRC21:03
*** browne has quit IRC21:03
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Session loading from config  https://review.openstack.org/9501521:03
*** leseb has joined #openstack-keystone21:04
*** boris-42 has quit IRC21:06
*** boris-42 has joined #openstack-keystone21:08
*** bobt has joined #openstack-keystone21:09
*** bobt_ has joined #openstack-keystone21:09
*** dstanek is now known as dstanek_zzz21:16
*** joesavak has joined #openstack-keystone21:17
*** dstanek_zzz is now known as dstanek21:25
*** rodrigods has quit IRC21:26
*** bobt_ has quit IRC21:26
*** richm has quit IRC21:29
ayoungbknudson, it positional decoartor is to prevent people from calliing long parameter list functions by order21:31
bknudsonayoung: the lists in https://review.openstack.org/#/c/79774/4/keystoneclient/v3/services.py don't look particularly long21:32
ayoungbknudson, nope.  they don't21:32
bknudsonalthough it takes kwargs so it could be long21:33
bknudsonalso, if you call .create('service_name', 'service_type') you'll get a warning.21:33
bknudsonI think it's annoying if an API logs warnings.21:34
*** gokrokve has quit IRC21:34
ayoungbknudson, its a warning so you change your code to remove the warning21:35
ayoungbut old code still works21:35
bknudsonI think I'd change the logging levels so I don't see it before I'd change the code21:35
ayoungbknudson, I don't think the count is supposed to be updated. Unless you want to be able to add a new positional argument21:35
ayoung.create('service_name', 'service_type'  would work if you bumped the count to 221:36
ayoungbut adding description should not do that.21:36
ayoung I'm guessing 1 is for self21:36
bknudsonayoung: y, I ran the code and am convinced that the count doesn't have to be updated.21:36
ayoungbknudson, any experience with horizon?  I'm asking a quesiont in openstack-horizon and getting nothing but echos21:37
bknudsonayoung: no, I haven't been using horizon.21:37
ayoungsomething has told horizon that It should be talking to neutron and I set up things with no neutron21:37
bknudsondoug fish is our horizon expert.21:38
bknudsonLooks like he's in -dev21:38
*** ayoung is now known as ayoung_afk21:45
*** sbfox has quit IRC21:46
*** leseb has quit IRC21:47
*** erecio_1 has quit IRC21:51
*** leseb has joined #openstack-keystone21:53
*** bobt has quit IRC21:53
*** browne1 has quit IRC21:58
*** browne has joined #openstack-keystone22:02
*** marcoemorais has quit IRC22:06
*** marcoemorais has joined #openstack-keystone22:07
*** marcoemorais has quit IRC22:07
*** marcoemorais has joined #openstack-keystone22:08
*** leseb has quit IRC22:08
*** marcoemorais has quit IRC22:09
*** marcoemorais has joined #openstack-keystone22:09
*** jamielennox|away is now known as jamielennox22:11
*** andreaf has quit IRC22:12
*** nkinder has quit IRC22:15
*** boris-42 has quit IRC22:17
*** david-lyle has quit IRC22:18
*** david-lyle has joined #openstack-keystone22:18
*** david-lyle has quit IRC22:19
*** boris-42 has joined #openstack-keystone22:20
*** joesavak has quit IRC22:24
*** thedodd has quit IRC22:36
*** marcoemorais has quit IRC22:37
*** arborism has joined #openstack-keystone22:37
*** marcoemorais has joined #openstack-keystone22:37
*** sbfox has joined #openstack-keystone22:41
*** dstanek is now known as dstanek_zzz22:42
*** bknudson has quit IRC22:44
*** diegows has quit IRC23:04
*** dstanek_zzz is now known as dstanek23:04
*** schofield is now known as schofield_away23:04
*** sbfox has quit IRC23:06
*** ayoung_afk is now known as ayoung23:08
*** Camisa has quit IRC23:10
*** rodrigods has joined #openstack-keystone23:12
*** dstanek is now known as dstanek_zzz23:16
*** BAKfr has quit IRC23:18
*** rodrigods has quit IRC23:19
*** openstackgerrit has quit IRC23:19
*** rodrigods has joined #openstack-keystone23:19
*** rodrigods has joined #openstack-keystone23:19
*** openstackgerrit has joined #openstack-keystone23:20
*** sbfox has joined #openstack-keystone23:37
openstackgerritA change was merged to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/9124023:42
*** praneshp has quit IRC23:43
*** praneshp has joined #openstack-keystone23:44
stevemarbest bknudson comment yet: "2 spaces after a . is this 1980?"23:47
morganfainbergstevemar, ++23:47
*** nkinder has joined #openstack-keystone23:47
openstackgerritMorgan Fainberg proposed a change to openstack/identity-specs: Initial Commit for Identity-specs repo  https://review.openstack.org/9498723:49
*** marcoemorais has quit IRC23:49
*** marcoemorais has joined #openstack-keystone23:50
*** marcoemorais has quit IRC23:50
*** r-daneel has quit IRC23:50
*** marcoemorais has joined #openstack-keystone23:50
morganfainbergstevemar, ^ that should resolve brant's concerns and the typo23:50
jamielennoxstevemar: lol23:54
gyeejamielennox, there?23:59
jamielennoxyea23:59

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