| *** achampion has joined #openstack-keystone | 00:09 | |
| *** nkinder has quit IRC | 00:12 | |
| *** richm has quit IRC | 00:12 | |
| topol | ayoung, I got 10 to 1 odds that your patch wouldnt make it. Looks like my bookie is gonna take my thumbs :-) | 00:25 |
|---|---|---|
| *** krsna has quit IRC | 00:27 | |
| *** browne has left #openstack-keystone | 00:30 | |
| morganfainberg | ayoung, +2 with a comment that we should say it is expirimental in the docs | 00:35 |
| morganfainberg | ayoung, and get it really solid and lots of drive time for Juno | 00:36 |
| morganfainberg | ..WARNING:: This extension is experimental, and will continue to see improvement over the next development cycle. | 00:37 |
| morganfainberg | or some such | 00:37 |
| *** topol has quit IRC | 00:38 | |
| *** arborism is now known as amcrn | 00:40 | |
| *** henrynash has quit IRC | 00:41 | |
| *** derek_c has quit IRC | 00:46 | |
| *** stevemar has quit IRC | 00:51 | |
| *** lbragstad has joined #openstack-keystone | 00:52 | |
| ayoung | morganfainberg, Deal | 00:57 |
| gyee | so we are going with experimental? | 00:58 |
| gyee | topol, pay up! | 00:58 |
| morganfainberg | ayoung, i really expect a lot of things to change as we spend time working with the revocation events | 01:01 |
| morganfainberg | ayoung, both w/ revocation code and with the stuff that is associated to it / interacts with it | 01:01 |
| ayoung | morganfainberg, dolphm http://paste.fedoraproject.org/82410/39813201 I'll ad that and hit the approve button? | 01:02 |
| morganfainberg | hm. maybe "over the Juno development cycle"? | 01:02 |
| morganfainberg | ayoung, also make that a separate review. but yeah +A is good if jenkins is happy w/ it (though you should wait for https://review.openstack.org/#/c/78030/ to land | 01:03 |
| morganfainberg | or rebase on it. | 01:03 |
| ayoung | what do we have in the queue right now... | 01:04 |
| morganfainberg | ayoung, nothing except a stable/havana fix | 01:04 |
| morganfainberg | ayoung, once 78030 passes check, it'll move to gate | 01:05 |
| morganfainberg | gate is 54 deep | 01:05 |
| ayoung | morganfainberg, OK. I'll let mine wait. No reason to have too much churn. | 01:05 |
| morganfainberg | but only the sqlalchemy stable/havana fix | 01:05 |
| morganfainberg | k. | 01:05 |
| ayoung | 'salright. Just processing | 01:05 |
| morganfainberg | but yeah add the expirimental as a new patch based on yours, that way nothing is needed to accept both. :) easier / less churn on that massive patch | 01:06 |
| morganfainberg | coffee time | 01:07 |
| *** dstanek has joined #openstack-keystone | 01:08 | |
| *** ChanServ sets mode: +v dstanek | 01:08 | |
| *** wchrisj has quit IRC | 01:11 | |
| *** rwsu has quit IRC | 01:29 | |
| *** gokrokve_ has quit IRC | 01:30 | |
| *** harlowja has quit IRC | 01:31 | |
| ayoung | morganfainberg, if we have nothing else in the stack that is making config changes, I should be able to push the button, no> | 01:33 |
| *** derek_c has joined #openstack-keystone | 01:33 | |
| *** nkinder has joined #openstack-keystone | 01:36 | |
| *** wchrisj has joined #openstack-keystone | 01:37 | |
| morganfainberg | ayoung, well if you press go and https://review.openstack.org/#/c/78030/ isn't in the gate qeueue it'll fail pep8 | 01:38 |
| ayoung | OK...I can certainly wait on that | 01:38 |
| morganfainberg | ayoung, that one should finish in a minute or so | 01:38 |
| ayoung | morganfainberg, that FAILURE on Python33 gives me a little startle every time | 01:42 |
| morganfainberg | lol | 01:42 |
| ayoung | morganfainberg, its failing before our code even gets touched | 01:43 |
| morganfainberg | yep | 01:44 |
| morganfainberg | eventlet | 01:44 |
| ayoung | File "/opt/stack/keystone/.tox/py33/build/eventlet/setup.py", line 3 | 01:44 |
| morganfainberg | yep | 01:44 |
| morganfainberg | execpt exception, e | 01:44 |
| morganfainberg | not valid in py33 | 01:44 |
| morganfainberg | needs to be "as e" | 01:44 |
| ayoung | is there a python33 eventlet fix yet? | 01:44 |
| morganfainberg | nope | 01:44 |
| ayoung | how would one go about fixing this thing? | 01:45 |
| dstanek | ayoung: i'm pretty happy with the changes in the token extension - is the plan to fix the things that dolphm mentioned or proceed and fix in a later patch? | 01:45 |
| ayoung | we would need to get eventlet from somewhere other than upstream | 01:45 |
| ayoung | dstanek, later patch | 01:45 |
| ayoung | treat those as bugs for rc1 | 01:46 |
| ayoung | he and morganfainberg are willing to +2 it and we can get it merged and then move on | 01:46 |
| dstanek | :) | 01:46 |
| *** devlaps1 has quit IRC | 01:56 | |
| *** marcoemorais has quit IRC | 01:57 | |
| *** topol has joined #openstack-keystone | 02:04 | |
| *** wchrisj has quit IRC | 02:11 | |
| jamielennox | how do we get the openstackgerrit bot to show up in here? | 02:12 |
| jamielennox | XXX proposed a change to XXX - it's spammy but useful | 02:14 |
| *** gokrokve has joined #openstack-keystone | 02:16 | |
| *** harlowja has joined #openstack-keystone | 02:17 | |
| *** wchrisj has joined #openstack-keystone | 02:31 | |
| *** amcrn has quit IRC | 02:35 | |
| *** gokrokve has quit IRC | 02:35 | |
| *** wchrisj__ has joined #openstack-keystone | 02:37 | |
| *** wchrisj has quit IRC | 02:37 | |
| morganfainberg | jamielennox, i'll propose it to infra if you want | 02:38 |
| morganfainberg | it's easy | 02:38 |
| *** wchrisj__ has quit IRC | 02:41 | |
| *** derek_c has quit IRC | 02:41 | |
| *** derek_c has joined #openstack-keystone | 02:42 | |
| morganfainberg | jamielennox, https://review.openstack.org/#/c/78071/ | 02:44 |
| *** derek_c has quit IRC | 02:53 | |
| jamielennox | morganfainberg: huh, cool thanks | 03:03 |
| jamielennox | i assumed itd be an infra thing i just haven't done much with infraconfig | 03:04 |
| bknudson | morganfainberg: could do identity-api, too | 03:04 |
| morganfainberg | bknudson, ah sure i'll add that | 03:05 |
| *** gokrokve has joined #openstack-keystone | 03:05 | |
| morganfainberg | bknudson, added | 03:06 |
| gyee | morganfainberg, I am trying to following the increasing user ID size thread, but having trouble understand the reasons behind it | 03:09 |
| gyee | why do we need to map users IDs? | 03:10 |
| *** derek_c has joined #openstack-keystone | 03:12 | |
| morganfainberg | gyee, it's about ensuring that user_ids are unique across multiple backends | 03:13 |
| morganfainberg | gyee, initially we were going to use user_id@@domain_id | 03:13 |
| *** harlowja is now known as harlowja_away | 03:13 | |
| morganfainberg | and varchar(255) is more friendly to a ton of data. | 03:13 |
| gyee | is there a standard across OpenStack on the IDs? | 03:13 |
| morganfainberg | gyee, we define it... we're the idp | 03:13 |
| gyee | I can't tell by reading the thread | 03:13 |
| morganfainberg | gyee, but we have defined our schema as 64 varchar | 03:14 |
| gyee | I mean IDs in general | 03:14 |
| morganfainberg | and by and large we're only sending 32 bytes (uuid() | 03:14 |
| morganfainberg | gyee, so everyone (except one place i nova) uses a varchar(64) | 03:14 |
| morganfainberg | gyee, the standard on the type of data is a "string of <=64 characters" | 03:14 |
| gyee | are we defining a new ID data type across OpenStack? | 03:14 |
| morganfainberg | gyee, ideally we should be more picky about what we send as the user_id | 03:15 |
| morganfainberg | gyee, i would like everything to be uuids but there are concerns about having to maintain a map for LDAP federated, etc | 03:15 |
| morganfainberg | ldap/federated/etc | 03:15 |
| gyee | morganfainberg, no need for map | 03:15 |
| gyee | for LDAP and federation, users are managed outside of Keystone | 03:15 |
| morganfainberg | gyee this is for assignment purposes | 03:16 |
| morganfainberg | if we take a DN of "cn=gyee,dc=hp,dc=com" | 03:16 |
| morganfainberg | and we turn that into an id | 03:16 |
| morganfainberg | we get "gyee" today | 03:16 |
| gyee | morganfainberg, nope | 03:16 |
| gyee | that should be done dynamically | 03:16 |
| morganfainberg | when we map a role, the user_id is gyee | 03:16 |
| gyee | map user to a group template after auth | 03:16 |
| gyee | directly | 03:16 |
| morganfainberg | so in the grant table, it's gyee, <project_id>, has <role_id> | 03:17 |
| gyee | do not allow direct role assignments or life will be miserable | 03:17 |
| morganfainberg | we already allow it | 03:17 |
| morganfainberg | can't really take it away | 03:17 |
| gyee | I am saying do not support that use case for LDAP and Federation | 03:17 |
| gyee | no customers that we've interact with have this requirement | 03:17 |
| morganfainberg | well we can't take it away from LDAP we support it | 03:17 |
| morganfainberg | iirc CERN uses this | 03:17 |
| morganfainberg | among a few other deployments | 03:18 |
| gyee | CERN uses direct role assignment?!!!! | 03:18 |
| morganfainberg | perhaps | 03:18 |
| gyee | oh god bless them | 03:18 |
| morganfainberg | i wasn't 100% clear on it | 03:18 |
| morganfainberg | but i know places use direct role assignments w/ LDAP identity | 03:18 |
| morganfainberg | we can't take it away | 03:18 |
| gyee | when interacting wit LDAP and Federations, customers just want their existing users to use OpenStack | 03:18 |
| gyee | they don't want Keystone to manage their users | 03:19 |
| morganfainberg | sure, but id != assignment | 03:19 |
| gyee | I am saying no need for assignment | 03:19 |
| morganfainberg | even if we use groups in keystone, mapping users to those groups (what if ldap doesn't provide the group arrangement you want) needs an ID | 03:19 |
| morganfainberg | gyee, if we didn't need to break support for something we already have i'd be on board with that | 03:19 |
| gyee | all IdP supports groups | 03:20 |
| morganfainberg | but since we support all of this, we need to uniquely identify users | 03:20 |
| morganfainberg | if you have multiple users with the same ID derivation bits | 03:20 |
| morganfainberg | (e.g. cn=gyee) | 03:20 |
| morganfainberg | or even group=hp_admin | 03:20 |
| gyee | cn=gyee is not an LDAP DN | 03:20 |
| gyee | DN = distinguished name | 03:21 |
| gyee | DN, by definition, is globally unique | 03:21 |
| morganfainberg | cn=gyee,ou=users,dc=hp,dc=com | 03:21 |
| morganfainberg | better? | 03:21 |
| gyee | yes | 03:21 |
| morganfainberg | sure but that doesn't stop someone from doing something dumb and configuring ldap1 and ldap2 with the same data | 03:21 |
| morganfainberg | as seprate idenetity sources | 03:21 |
| gyee | morganfainberg, not within an enterprise | 03:21 |
| morganfainberg | keystone needs to protect against that. | 03:21 |
| morganfainberg | gyee, it is far different from "what should be done" and "omg i did this and it's broken" | 03:22 |
| morganfainberg | gyee, the latter is bad news for us. so we should prevent it from happening | 03:22 |
| morganfainberg | gyee we don't trust external idps to be globally unique | 03:22 |
| morganfainberg | even if they are supposed to be | 03:22 |
| morganfainberg | what stops someone from doing something malicious to get access to your account | 03:23 |
| morganfainberg | so we use our internal domain_id as part of the user_id. something we control | 03:23 |
| morganfainberg | it's really not expensive to do so | 03:23 |
| morganfainberg | we have 64 bytes of storage | 03:23 |
| morganfainberg | and it guarantees we can avoid cross-idp exploits / confusion of users / etc | 03:24 |
| gyee | morganfainberg, if we do this right, there's no need to maintaining user IDs in Keystone for external users | 03:24 |
| morganfainberg | think of it from interoperable clouds, maybe hp is providing id to a cloud operated by rax. | 03:24 |
| gyee | morgainfainberg, the only reason HP needs the ID is for tracking | 03:24 |
| gyee | billing, anti-fraud, etc | 03:25 |
| morganfainberg | and does it hurt us to provide good data back for that? | 03:25 |
| gyee | I don't think other OpenStack services needs the user ID | 03:25 |
| morganfainberg | user_quotas in heat/nova/etc | 03:25 |
| gyee | morganfainberg, tracking is outside of Keystone | 03:26 |
| morganfainberg | audit in nova | 03:26 |
| morganfainberg | needs user_id | 03:26 |
| gyee | for tracking, it is at the discretion of the deployer | 03:26 |
| morganfainberg | gyee, if we accept multiple sources providing ID to keystone, we need to uniquely map them to the domains | 03:26 |
| gyee | morganfainberg, we can | 03:26 |
| morganfainberg | gyee, ok and as it stands there is no option for the deployer to easily do that | 03:26 |
| gyee | for LDAP, if DN=gyee,ou=engineering,dc=hp,dc=com | 03:27 |
| morganfainberg | great | 03:27 |
| gyee | you can easily map "dc=hp,dc=com" to the "hp" domain | 03:27 |
| gyee | those can be done dynamically | 03:27 |
| morganfainberg | gyee, well #1, that isn't websafe, so uuencode it | 03:28 |
| morganfainberg | gyee (that's easy) | 03:28 |
| gyee | websafe? | 03:28 |
| morganfainberg | urlsafe | 03:28 |
| morganfainberg | sorry | 03:28 |
| gyee | why are we worry about urlsafe? | 03:28 |
| morganfainberg | gyee, 2 what if you have a cloud with external id provided by two companies. what if company B reconfigures their ldap server to serve up the _same_ id | 03:28 |
| gyee | DN will never be part of the request | 03:29 |
| morganfainberg | we allow queries based on user_id to the rest api | 03:29 |
| morganfainberg | for sanity sake, lets just assume we make ids safe for people to use. | 03:29 |
| morganfainberg | i don't want to argue that point, it's a noop or minimal overhead | 03:29 |
| gyee | that's what I was saying at the beginning, for 3rd party integration, no one will call Keystone's lookup user | 03:30 |
| gyee | Keystone is strictly for authentication | 03:30 |
| gyee | users are managed outside of Keystone :) | 03:30 |
| gyee | so don't worry about lookup | 03:30 |
| morganfainberg | gyee, /users/{user_id}/roles | 03:30 |
| morganfainberg | it's an assignment call | 03:30 |
| lbragstad | dstanek: if you want to add me to the initial hacking review you can | 03:30 |
| morganfainberg | not an identity call | 03:30 |
| gyee | morganfainberg, nope | 03:30 |
| morganfainberg | yes it is. | 03:31 |
| gyee | morganfainberg, /groups/group_id/roles yes | 03:31 |
| gyee | but not users | 03:31 |
| morganfainberg | i'm looking at the routers | 03:31 |
| morganfainberg | it's there | 03:31 |
| morganfainberg | current master | 03:31 |
| gyee | it is there, but not a good use case | 03:32 |
| morganfainberg | but we need to support it | 03:32 |
| gyee | for LDAP and Federation, we have to do it right at the system level | 03:32 |
| morganfainberg | ok so we can't trust that the LDAP server isn't being malicious if it's not managed by us | 03:32 |
| morganfainberg | if we have to provide an id, we should include enough data to make it 100% unique | 03:33 |
| gyee | morganfainberg, that's up to the deployers | 03:33 |
| gyee | ID ain't gonna help if you don't trust LDAP | 03:33 |
| morganfainberg | so if i deploy a cloud and customer says i want ldap server 2 and ldapserver 1 to be separate domains | 03:33 |
| morganfainberg | but they provide the same dc=blah,dc=com | 03:33 |
| morganfainberg | i have to tell them "sorry can't work" | 03:34 |
| gyee | moranfainberg, not a chance | 03:34 |
| morganfainberg | gyee, i don't get to control the LDAP servers | 03:34 |
| morganfainberg | what if someone reconfigures one to provide bad data? | 03:34 |
| morganfainberg | why are you against being defensive on this front | 03:34 |
| morganfainberg | and making it so we can't run into an issue due to it | 03:35 |
| morganfainberg | ? | 03:35 |
| gyee | morganfainberg, we can defense against stupidity :) | 03:35 |
| gyee | we can't | 03:35 |
| morganfainberg | ok | 03:35 |
| morganfainberg | another use case | 03:35 |
| morganfainberg | trusts | 03:35 |
| morganfainberg | trusts encode user_ids | 03:35 |
| gyee | we need to extend trust for groups, not individual users | 03:36 |
| morganfainberg | gyee, that is API incompatible | 03:36 |
| morganfainberg | gyee, we already support user trusts | 03:36 |
| morganfainberg | gyee, we can't take it away | 03:36 |
| gyee | not taking it away | 03:37 |
| morganfainberg | and heat uses trusts _a lot_ | 03:37 |
| morganfainberg | again, i don't trust sources of id keystone doesn't control | 03:37 |
| gyee | for 3rd integration, everything needs to be done by groups | 03:37 |
| gyee | 3rd party | 03:37 |
| morganfainberg | since we don't want to control it | 03:37 |
| morganfainberg | we just make sure it's easy to not worry about people doing something dumb | 03:37 |
| morganfainberg | deployers will do something dumb, i don't see why we shouldn't ensure we're guarding against that. vs failing in odd/strange/bad ways | 03:38 |
| gyee | morganfainberg, maintaining two parallel identity system is a huge overhead that we can avoid | 03:38 |
| morganfainberg | gyee, so you're saying don't support multiple id sources? | 03:38 |
| morganfainberg | no multiple ldap servers? | 03:38 |
| morganfainberg | since id source for keystone | 03:39 |
| morganfainberg | ? | 03:39 |
| gyee | morganfainberg, we can easily support multiple ID sources, purely by dynamic mapping | 03:39 |
| morganfainberg | ok so how do we solve dynamic mapping? | 03:39 |
| gyee | for LDAP, map partial DN to domain | 03:40 |
| morganfainberg | ok for federation | 03:40 |
| morganfainberg | ? | 03:40 |
| morganfainberg | i'll stop arguing ldap (except that we don't store the whole DN, we store a very small bit right now) | 03:41 |
| gyee | say two users, user1 with DN cn=gyee,ou=engineering,dc=hp,dc=com, and user 2 with DN cn=morganfainberg,ou=engineering,o=metacloud.com | 03:41 |
| gyee | you can have a rule that maps "dc=hp,dc=com" to the "hp" domain, map "ou=engineering,dc=hp,dc=com" to the "engineering" project | 03:41 |
| gyee | you can have a rule that maps "o=metacloud.com" to the "metacloud" domain | 03:42 |
| *** chandan_kumar has joined #openstack-keystone | 03:42 | |
| gyee | some for federation, domain map to combination of attributes | 03:42 |
| morganfainberg | gyee, you can't control federation servers or prevent them from sending the same exact informaiton for two users | 03:43 |
| morganfainberg | gyee, we get what is in the assertion (SAML) | 03:43 |
| gyee | morganfainberg, with federation, we deal with attributes/assertions | 03:43 |
| gyee | how we map them is entirely up to us | 03:43 |
| morganfainberg | gyee, ok so we map with something to derive ID and the domain | 03:43 |
| gyee | an identity is a set of attributes/assertions | 03:43 |
| morganfainberg | great easy to lookup the domain | 03:44 |
| gyee | if they are they same, then by definition it is the same identity | 03:44 |
| morganfainberg | gyee, unless someone is doing something malicious. lets be secure about it | 03:44 |
| morganfainberg | back to your ldap server cn=morganfainberg,ou=admin,ou=special users,ou=contractor,ou=engineering,o=metacloud.com' | 03:44 |
| gyee | morganfainberg, security is process, software is a tool | 03:44 |
| morganfainberg | not an unreasonable DN | 03:44 |
| morganfainberg | silly | 03:44 |
| gyee | secure design != secure implementation | 03:44 |
| morganfainberg | but not really unreasonable | 03:45 |
| gyee | secure implemenation != secure deployment | 03:45 |
| morganfainberg | if you store that ID outside of keystone | 03:45 |
| morganfainberg | 64 characters | 03:45 |
| morganfainberg | you end up at ou=en | 03:45 |
| gyee | we are merely providing a piece of functionality to allow customers to implement their business process | 03:45 |
| morganfainberg | that leaves ambigious matching | 03:45 |
| morganfainberg | vs. taking some unique element from the DN and the domain id (unique because keystone controls it) | 03:46 |
| morganfainberg | and use that to uniquely identify the suer | 03:46 |
| morganfainberg | useR* | 03:46 |
| *** chandan_kumar has quit IRC | 03:46 | |
| morganfainberg | gyee, sure. but if we lack security in our tools | 03:46 |
| gyee | morganfainberg, I am saying we don't need any user ID | 03:47 |
| morganfainberg | gyee, except... we do. | 03:47 |
| morganfainberg | gyee, it's how we identify users, audit, etc etc | 03:47 |
| morganfainberg | quota | 03:47 |
| *** wchrisj has joined #openstack-keystone | 03:47 | |
| gyee | you have the user name and you have the domain map | 03:47 |
| morganfainberg | and internal to keystone how we handle grants, trusts | 03:47 |
| gyee | those two pieces of information is all you need | 03:48 |
| morganfainberg | gyee, sure, and given the name alone in cases how do tyou know the domain | 03:48 |
| morganfainberg | right now, the implementation says we have the name only | 03:48 |
| gyee | domain is on the token data | 03:49 |
| gyee | in the token data | 03:49 |
| *** wchrisj has quit IRC | 03:49 | |
| morganfainberg | so, demand everyone store domain now too | 03:49 |
| gyee | no, who uses user ID besides Keystone | 03:49 |
| morganfainberg | nova, heat, uhm ceilometer, cinder | 03:49 |
| morganfainberg | i'm sure others | 03:50 |
| gyee | nova uses user_id? | 03:50 |
| morganfainberg | yep | 03:50 |
| morganfainberg | they provide user quotas | 03:50 |
| morganfainberg | in fact, they should only ever use user_id for anything that references the user | 03:50 |
| morganfainberg | they shouldn't care what the user's name is. or domain | 03:50 |
| morganfainberg | that is a keystone construct | 03:50 |
| *** stevemar has joined #openstack-keystone | 03:50 | |
| *** ChanServ sets mode: +v stevemar | 03:50 | |
| morganfainberg | user_id should be (and actually i think we say as much) be unique across the cloud | 03:51 |
| gyee | you have the url for the nova quota code? | 03:52 |
| morganfainberg | gyee, http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html | 03:53 |
| morganfainberg | looking for the code that backs that, sec | 03:53 |
| morganfainberg | it's been a while since i poked at nova :P | 03:54 |
| stevemar | morganfainberg, did it make it? | 03:55 |
| stevemar | morganfainberg, did it landddd | 03:55 |
| morganfainberg | stevemar, hmm? | 03:55 |
| stevemar | revoke | 03:55 |
| gyee | stevemar, yep, topol owns everybody beer! | 03:55 |
| morganfainberg | stevemar, not yet | 03:55 |
| stevemar | or was revoke revoked | 03:55 |
| gyee | owes | 03:55 |
| topol | stevemar did you see my email | 03:55 |
| morganfainberg | but it's approved | 03:55 |
| stevemar | topol, not yet, just turned on my laptop | 03:56 |
| stevemar | oh exciting times | 03:56 |
| stevemar | approved by author! | 03:56 |
| morganfainberg | gyee, ok i'm not seeing the code but i don't have my ide up i know they support user_quotas | 03:56 |
| stevemar | tsk tsk | 03:56 |
| morganfainberg | stevemar, yeah it needed to wait for another patch to hit gate, told ayoung to +A when that happened | 03:56 |
| topol | ayoung, I got 10 to 1 odds that your patch wouldnt make it. Looks like my bookie is gonna take my thumbs :-) | 03:56 |
| gyee | morganfainberg, lemme do some more code diving | 03:57 |
| *** david-lyle has joined #openstack-keystone | 03:57 | |
| morganfainberg | stevemar, https://review.openstack.org/#/c/78030/ | 03:57 |
| morganfainberg | that one was needed first to be in gate pipeline | 03:57 |
| ayoung | topol, you should know not to bet against me | 03:57 |
| stevemar | ayoung, how could he resist with odds like that! | 03:57 |
| morganfainberg | gyee, long and the short is, we can be defensive, and provide tools to prevent from malice (or bad deployments) from causing issues with crossed user_ids | 03:57 |
| topol | Like betting on the washington generals vs. the globetrotters... I thought they were due!!! | 03:58 |
| topol | stevemar the email I sent you is halarious | 03:58 |
| stevemar | topol, "He's spinning the ball on his finger! Just take it! Take it" | 03:59 |
| gyee | I can't still put a -2 on it before jenkins right? | 03:59 |
| gyee | topol, your luck may be changing | 03:59 |
| morganfainberg | gyee, short of moving to a V4, which I think we could eliminate user_ids completely then (not sure if anyone would enjoy it, but doable), i think we need to be smart about how we handle user_ids and ensure that we can tell the domain a user is from based upon the "shared" id | 03:59 |
| ayoung | morganfainberg, ++ audit is important | 04:00 |
| morganfainberg | gyee, eh, i hope you require serious $$$ for that. | 04:00 |
| topol | oh gyee, oh dont pin that on me... | 04:00 |
| morganfainberg | gyee, don't do it for cheap | 04:00 |
| gyee | topol, show me the money! | 04:00 |
| gyee | straight cash homie! | 04:00 |
| topol | ayoung is trained with firearms... so no dice | 04:00 |
| ayoung | topol, far more important is I know how to call in Indirect fire or an Airstrike | 04:01 |
| ayoung | why take out one person when you can take out a grid squar | 04:01 |
| ayoung | e | 04:01 |
| topol | ayoung, I used to work with a guy who was a sniper in the Korean Army. Very nice guy. You would never know it by looking at him | 04:02 |
| topol | great support tools builder | 04:02 |
| ayoung | WTF did a reverify put a patch back in the Check queue? Did I miss a memo? | 04:02 |
| gyee | morganfainberg, LDAP and federation have no concept of user_ids | 04:02 |
| gyee | I think we can do better in Keystone | 04:03 |
| gyee | anyway, time for dinner | 04:03 |
| morganfainberg | ayoung, you can't succeed a gate w/o a recent check | 04:03 |
| gyee | g'nite y'all | 04:03 |
| ayoung | but it failed gate due to a bug | 04:03 |
| ayoung | bah | 04:03 |
| *** gyee has quit IRC | 04:03 | |
| ayoung | how recent is ....a forget it | 04:03 |
| morganfainberg | ayoung, it's to mitigate gate churn because something like long +2/+2 item but doc bug | 04:03 |
| morganfainberg | so doc bug would force gate churn | 04:04 |
| ayoung | https://review.openstack.org/#/c/77215/ | 04:04 |
| morganfainberg | -2 from gate means you need a new +1 before it goes to gate | 04:04 |
| ayoung | failed due to some tempest disagreement with cinder or something | 04:04 |
| ayoung | and back to check? | 04:04 |
| ayoung | few | 04:04 |
| morganfainberg | yep. but it'll auto gate after check completes | 04:04 |
| morganfainberg | provided check passes | 04:04 |
| topol | morganfainberg, why a new +1? you cant just say reverify??? | 04:05 |
| morganfainberg | topol, jenkins needs a +1 to allow it in gate | 04:05 |
| morganfainberg | since a gate failure erases the +1, gerrit / zuul can't know it was already good | 04:05 |
| morganfainberg | it only knows current score | 04:05 |
| morganfainberg | so recheck, check produces +1, now +1 verify means it can go to gate | 04:06 |
| morganfainberg | the whole point is to prevent some stale code from making it's way into gate and causing gate churn | 04:06 |
| topol | morganfainberg forgive my ignorance, is this during a what used to be a recheck or a reverfy??? | 04:06 |
| morganfainberg | topol, recheck is only for a +1 verify | 04:07 |
| morganfainberg | a reverify issues what is equivalent to a "recheck" and if that passes, the previous functionality of "reverify" | 04:07 |
| topol | jenkins -1 correct? | 04:07 |
| morganfainberg | you can technically recheck a -2 :P | 04:07 |
| morganfainberg | but correct you would say recheck for a -1 | 04:07 |
| morganfainberg | you woudl say reverify for -2 | 04:07 |
| morganfainberg | but since there isn't a +1 verified, a "reverify" causes a check to run again before it tries to apply the +2 jenkins logic | 04:08 |
| topol | reverify was failure during merge. so now you have to do???? | 04:08 |
| morganfainberg | topol, "reverify" will work | 04:08 |
| topol | +1 then reverify?? | 04:08 |
| morganfainberg | topol, it just looks odd because jenkins automatically will try to +1, then try to gate it | 04:08 |
| morganfainberg | topol, it happens aiutomatically | 04:09 |
| morganfainberg | no change in your workflow | 04:09 |
| topol | oh ok, so what changed??? | 04:09 |
| morganfainberg | change in what zuul does | 04:09 |
| topol | ok good | 04:09 |
| lbragstad | topol: I responded to your comments here: https://review.openstack.org/#/c/72582/ | 04:09 |
| morganfainberg | basically if there isn't a +1 that happened in the last 24 hours, approval (or any comment) will force a 'recheck no bug' | 04:09 |
| * topol took dumbass brad long enough to learn the old workflow, glad it didnt change | 04:09 | |
| morganfainberg | it's magic | 04:10 |
| morganfainberg | zuul just does it | 04:10 |
| morganfainberg | this helps prevent issues like that doc bug, where the sphinx version is wrong | 04:10 |
| morganfainberg | from making it's way into gate, since some patch was +2 CR 2 months ago | 04:10 |
| morganfainberg | and some core approves it, not knowing the doc bug fix hasn't been merged | 04:11 |
| morganfainberg | then you get 20 of these things failing in gate and doing constant resets making gate back up | 04:11 |
| morganfainberg | and each reset resets everything behind it, then fails and the chain continues for hours | 04:11 |
| morganfainberg | topol, basically.. i makes some cases of approval / reverify take longer | 04:11 |
| morganfainberg | topol, but it makes the gate less brittle | 04:11 |
| morganfainberg | topol, and it doesn't change anyone's workflow | 04:12 |
| * morganfainberg stops being wordy | 04:12 | |
| topol | morganfainberg, thanks for the clarification. | 04:13 |
| topol | lbragstad, thanks for the response. I +1 the patch | 04:13 |
| morganfainberg | topol, sorry if i wasn't clear initially. sometimes IRC makes that harder :P | 04:13 |
| morganfainberg | ayoung, for the non-voting sample config change: https://review.openstack.org/#/c/78038/ | 04:14 |
| morganfainberg | that should at least warn us that sample is out of date on each/any check | 04:14 |
| morganfainberg | next steps will to make it all publish via doc building (or similar) | 04:14 |
| morganfainberg | automatically | 04:14 |
| ayoung | morganfainberg, that is a direct copy of the new files, right? | 04:15 |
| ayoung | https://review.openstack.org/#/c/78038/2/modules/jenkins/files/slave_scripts/check-config-sample-up-to-date.sh | 04:15 |
| morganfainberg | hmm? | 04:15 |
| morganfainberg | "direct copy"? | 04:15 |
| ayoung | is that new? | 04:16 |
| morganfainberg | yes new | 04:16 |
| morganfainberg | created for that review | 04:16 |
| ayoung | https://review.openstack.org/#/c/78038/2/modules/jenkins/files/slave_scripts/check-config-sample-up-to-date.sh | 04:16 |
| morganfainberg | it is based on the run-tox.sh file that is used to run unit tests | 04:16 |
| morganfainberg | but specific for checking the config | 04:16 |
| ayoung | so...just cuz it passed their test, does it mean it could completely break out gate if it had a typo? | 04:17 |
| morganfainberg | nope | 04:17 |
| morganfainberg | it's configured as non-voting | 04:17 |
| ayoung | sez yoiu | 04:17 |
| morganfainberg | worst case, it would say failed like py33 | 04:17 |
| morganfainberg | https://review.openstack.org/#/c/78038/2/modules/openstack_project/files/zuul/layout.yaml | 04:17 |
| *** harlowja_away has quit IRC | 04:17 | |
| morganfainberg | line 454 | 04:17 |
| morganfainberg | to 457 | 04:18 |
| ayoung | No, I believe that is what the file says...just that I have no context for any of this | 04:18 |
| morganfainberg | see where it says voting: false | 04:18 |
| ayoung | I mean, it looks right | 04:18 |
| morganfainberg | ayoung, ah yeah | 04:18 |
| morganfainberg | ayoung, zuul config stuff | 04:18 |
| morganfainberg | any check can be non-voting with that | 04:18 |
| ayoung | I'd prefer if there was a "lets test it out on a known good patch" part of the check | 04:18 |
| ayoung | if you don;t mind, lets hold off until the I3 stuff clears? | 04:19 |
| morganfainberg | ayoung, not sure how you'd do an automatic test of a slave script | 04:19 |
| ayoung | run it | 04:19 |
| morganfainberg | ayoung, that wont clear tonight | 04:19 |
| morganfainberg | ayoung, it'll go in long after revocation stuff | 04:19 |
| ayoung | nothing will clear tonight | 04:20 |
| morganfainberg | ayoung, it's up for infra to review, that is there perogative to approve/not approve | 04:20 |
| ayoung | sure | 04:20 |
| morganfainberg | ayoung, i think it'll hold till after i3 though | 04:20 |
| morganfainberg | ayoung, based on other stuff :) | 04:20 |
| ayoung | yeah...lots to clear on the freeze date | 04:20 |
| morganfainberg | yep | 04:20 |
| morganfainberg | which reminds me... | 04:21 |
| *** morganfainberg changes topic to "[ Icehouse RC blockers https://launchpad.net/keystone/+milestone/icehouse-rc1 ][ Icehouse RC Target Date: March 27th, 2014 ]" | 04:22 | |
| topol | we have some??? | 04:23 |
| morganfainberg | yep | 04:23 |
| morganfainberg | things that didn't get fixed for I3 | 04:23 |
| ayoung | guess I need to find a way to sneak in compressed tokens | 04:24 |
| ayoung | ah..but if it is a bug fix...I can add in a new config option, right? | 04:24 |
| morganfainberg | ayoung, uhmmmmmmmmmmmmmmmm | 04:24 |
| stevemar | topol, a few bugs here and there | 04:24 |
| ayoung | new token provider that makes use of compressed tokens | 04:24 |
| morganfainberg | ayoung, errrr i think that is a tough sell. | 04:24 |
| stevemar | ayoung, you just gotta keep pushing the envelope eh | 04:25 |
| morganfainberg | ayoung, but i'd need to defer to ttx and dolphm on that one | 04:25 |
| ayoung | it will be off by default. THe change needs to go into the client | 04:25 |
| ayoung | all hte server needs then is to be able to use it | 04:25 |
| morganfainberg | client changes aren't released the same way as server is | 04:25 |
| ayoung | I want it to be deployed to the other services before we enable on Keystone | 04:25 |
| morganfainberg | you can likely get the change into client | 04:25 |
| ayoung | right | 04:25 |
| ayoung | but I want a config option to use a client change on the server | 04:26 |
| morganfainberg | yeah i wouldn't worry about getting it into the client for FF etc | 04:26 |
| morganfainberg | isn't that just an option defined in keystoneclient (auth_token.py)? | 04:26 |
| ayoung | I can rework the client patch tomorrow. I need to go to bed now | 04:26 |
| topol | stevemar plz tell me you saw my email | 04:26 |
| ayoung | it needs to be an option passed to the cms call: compress the token | 04:26 |
| morganfainberg | again, client change, should be doable | 04:26 |
| ayoung | but ATM needs to be able to handle first | 04:27 |
| morganfainberg | ayoung, *shrug* still probably do able. | 04:27 |
| ayoung | gnigh | 04:27 |
| *** ayoung is now known as ayoung-snore | 04:27 | |
| morganfainberg | night | 04:27 |
| topol | when ayoungs kids get a little older he'll be able to live on 4 hours asleep a night like me. Side effects are minimal.. | 04:28 |
| stevemar | topol, reading it now! | 04:28 |
| topol | like giving poor lbragstad a totally undeserved -1 and not even remembering doing it... | 04:29 |
| * topol what the hell was I thinking.. | 04:29 | |
| lbragstad | lol | 04:29 |
| morganfainberg | topol, hmmmmm. | 04:30 |
| stevemar | topol, nice, way to defend OSC :) | 04:30 |
| morganfainberg | topol, maybe you were thinking "-1, time for beer" | 04:30 |
| topol | stevemar is that worth sharing with this crowd??? | 04:30 |
| lbragstad | morganfainberg: ++ :) | 04:31 |
| topol | I think the -1 was because lbragstad had not built his bar yet. Just the sign | 04:32 |
| morganfainberg | oh if you guys haven't done it (not that OFTC is 100%) make sure to go register your usernames on the OFTC irc network | 04:32 |
| *** wchrisj has joined #openstack-keystone | 04:32 | |
| lbragstad | hey I'm +2 on the bar for sure! just need to get the time to do it | 04:32 |
| stevemar | topol, i think morganfainberg would get a chuckle out of it | 04:32 |
| stevemar | lbragstad, yes, concentrate on the bar, i can live vicariously through you | 04:33 |
| topol | morganfainberg how do we do that? Are we really moving to OFTC? | 04:33 |
| lbragstad | stevemar: ++ | 04:33 |
| stevemar | topol, given ttx's last email, i'd say it's unlikely | 04:33 |
| stevemar | or at least not happening for a while | 04:34 |
| *** lbragstad is now known as lbragstad_ | 04:34 | |
| topol | morganfainberg, just fwded you a halarious email | 04:34 |
| morganfainberg | oh noes | 04:35 |
| topol | morganfainberg, did you get it? | 04:36 |
| morganfainberg | haha | 04:36 |
| *** wchrisj has quit IRC | 04:37 | |
| *** stevemar has quit IRC | 04:51 | |
| *** amcrn has joined #openstack-keystone | 04:55 | |
| *** stevemar has joined #openstack-keystone | 04:55 | |
| *** ChanServ sets mode: +v stevemar | 04:55 | |
| *** topol has quit IRC | 04:56 | |
| *** topol has joined #openstack-keystone | 04:56 | |
| *** amcrn_ has joined #openstack-keystone | 05:00 | |
| *** amcrn has quit IRC | 05:01 | |
| *** marcoemorais has joined #openstack-keystone | 05:07 | |
| *** marcoemorais has quit IRC | 05:09 | |
| dstanek | OFTC? | 05:09 |
| dstanek | morganfainberg: i saw a review about shutting off the sample check - it that on its way to being merged? | 05:10 |
| morganfainberg | dstanek. http://lists.openstack.org/pipermail/openstack-dev/2014-March/028783.html | 05:10 |
| *** wchrisj has joined #openstack-keystone | 05:11 | |
| morganfainberg | dstanek,. https://review.openstack.org/#/c/78030/ yeah it's in gate | 05:11 |
| dstanek | yay! | 05:11 |
| morganfainberg | it's a ways down though | 05:12 |
| *** ChanServ sets mode: -o morganfainberg | 05:15 | |
| dstanek | morganfainberg: well i got my nick just in case | 05:18 |
| morganfainberg | yeah same | 05:19 |
| *** stevemar has quit IRC | 05:26 | |
| *** chandankumar_ has quit IRC | 05:28 | |
| *** amcrn_ is now known as amcrn | 05:30 | |
| *** amcrn is now known as DrKatz | 05:34 | |
| *** chandan_kumar has joined #openstack-keystone | 05:38 | |
| *** DrKatz is now known as amcrn | 05:42 | |
| topol | I got my nick as well | 05:56 |
| *** derek_c has quit IRC | 06:00 | |
| *** topol has quit IRC | 06:09 | |
| *** achampion is now known as slic | 06:09 | |
| *** slic is now known as achampion | 06:10 | |
| *** bvandenh has joined #openstack-keystone | 06:15 | |
| *** derek_c has joined #openstack-keystone | 06:15 | |
| *** wchrisj has quit IRC | 06:29 | |
| *** gokrokve has quit IRC | 06:37 | |
| *** saju_m has joined #openstack-keystone | 07:02 | |
| *** amcrn has quit IRC | 07:36 | |
| *** huats_ has joined #openstack-keystone | 08:04 | |
| *** david-lyle has quit IRC | 08:11 | |
| *** nkinder has quit IRC | 08:11 | |
| *** lbragstad_ has quit IRC | 08:11 | |
| *** huats has quit IRC | 08:11 | |
| *** saju_m has quit IRC | 08:11 | |
| *** chandan_kumar has quit IRC | 08:11 | |
| *** dstanek has quit IRC | 08:11 | |
| *** koolhead17 has quit IRC | 08:11 | |
| *** YorikSar has quit IRC | 08:11 | |
| *** florentflament has quit IRC | 08:11 | |
| *** haneef_ has quit IRC | 08:11 | |
| *** bknudson has quit IRC | 08:11 | |
| *** tellesnobrega has quit IRC | 08:11 | |
| *** ayoung-snore has quit IRC | 08:11 | |
| *** sudorandom has quit IRC | 08:11 | |
| *** dolphm has quit IRC | 08:11 | |
| *** jamielennox has quit IRC | 08:11 | |
| *** bvandenh has quit IRC | 08:11 | |
| *** jraim has quit IRC | 08:11 | |
| *** zhiyan has quit IRC | 08:11 | |
| *** derek_c has quit IRC | 08:11 | |
| *** dtroyer has quit IRC | 08:11 | |
| *** Daviey has quit IRC | 08:11 | |
| *** mfisch has quit IRC | 08:11 | |
| *** chmouel has quit IRC | 08:11 | |
| *** zigo has quit IRC | 08:11 | |
| *** mhu has quit IRC | 08:11 | |
| *** ChanServ has quit IRC | 08:11 | |
| *** morganfainberg has quit IRC | 08:11 | |
| *** marekd|away has quit IRC | 08:11 | |
| *** anteaya has quit IRC | 08:11 | |
| *** luisbg has quit IRC | 08:11 | |
| *** david-lyle has joined #openstack-keystone | 08:28 | |
| *** lbragstad_ has joined #openstack-keystone | 08:28 | |
| *** huats has joined #openstack-keystone | 08:28 | |
| *** david-lyle has quit IRC | 08:29 | |
| *** lbragstad_ has quit IRC | 08:29 | |
| *** huats has quit IRC | 08:29 | |
| *** nkinder has joined #openstack-keystone | 09:02 | |
| *** lbragstad has joined #openstack-keystone | 09:02 | |
| *** david_lyle_ has joined #openstack-keystone | 09:02 | |
| *** saju_m has joined #openstack-keystone | 09:02 | |
| *** bvandenh has joined #openstack-keystone | 09:02 | |
| *** chandan_kumar has joined #openstack-keystone | 09:02 | |
| *** dstanek has joined #openstack-keystone | 09:02 | |
| *** haneef_ has joined #openstack-keystone | 09:02 | |
| *** jraim has joined #openstack-keystone | 09:02 | |
| *** zhiyan has joined #openstack-keystone | 09:02 | |
| *** bknudson has joined #openstack-keystone | 09:02 | |
| *** koolhead17 has joined #openstack-keystone | 09:02 | |
| *** YorikSar has joined #openstack-keystone | 09:02 | |
| *** tellesnobrega has joined #openstack-keystone | 09:02 | |
| *** ayoung-snore has joined #openstack-keystone | 09:02 | |
| *** sudorandom has joined #openstack-keystone | 09:02 | |
| *** dolphm has joined #openstack-keystone | 09:02 | |
| *** marekd has joined #openstack-keystone | 09:02 | |
| *** jamielennox|away has joined #openstack-keystone | 09:02 | |
| *** luisbg has joined #openstack-keystone | 09:02 | |
| *** florentflament has joined #openstack-keystone | 09:02 | |
| *** mfisch has joined #openstack-keystone | 09:02 | |
| *** anteaya has joined #openstack-keystone | 09:02 | |
| *** Daviey has joined #openstack-keystone | 09:02 | |
| *** dtroyer has joined #openstack-keystone | 09:02 | |
| *** chmouel has joined #openstack-keystone | 09:02 | |
| *** zigo has joined #openstack-keystone | 09:02 | |
| *** mhu has joined #openstack-keystone | 09:02 | |
| *** morganfainberg has joined #openstack-keystone | 09:02 | |
| *** dickson.freenode.net sets mode: +vovv dstanek dolphm jamielennox|away morganfainberg | 09:02 | |
| *** ChanServ has joined #openstack-keystone | 09:02 | |
| *** dickson.freenode.net sets mode: +o ChanServ | 09:02 | |
| *** bvandenh has quit IRC | 09:02 | |
| *** leseb has joined #openstack-keystone | 09:15 | |
| *** jaosorior has joined #openstack-keystone | 09:16 | |
| *** tellesnobrega has quit IRC | 09:18 | |
| *** saju_m has quit IRC | 09:19 | |
| *** saju_m has joined #openstack-keystone | 09:35 | |
| *** leseb has quit IRC | 09:46 | |
| *** leseb has joined #openstack-keystone | 09:47 | |
| *** leseb has quit IRC | 09:51 | |
| *** dstanek has quit IRC | 10:08 | |
| *** leseb has joined #openstack-keystone | 10:25 | |
| *** bvandenh has joined #openstack-keystone | 10:51 | |
| *** gokrokve has joined #openstack-keystone | 10:52 | |
| *** henrynash has joined #openstack-keystone | 10:52 | |
| *** gokrokve_ has joined #openstack-keystone | 10:54 | |
| *** gokrokve has quit IRC | 10:57 | |
| *** gokrokve_ has quit IRC | 10:59 | |
| *** bvandenh has quit IRC | 10:59 | |
| *** florentflament has quit IRC | 11:15 | |
| *** leseb has quit IRC | 11:18 | |
| *** leseb has joined #openstack-keystone | 11:18 | |
| *** leseb has quit IRC | 11:22 | |
| *** chandan_kumar has quit IRC | 11:25 | |
| *** henrynash has quit IRC | 11:28 | |
| *** henrynash has joined #openstack-keystone | 11:30 | |
| *** gokrokve has joined #openstack-keystone | 11:52 | |
| *** gokrokve has quit IRC | 11:56 | |
| *** chandan_kumar has joined #openstack-keystone | 12:11 | |
| *** leseb has joined #openstack-keystone | 12:16 | |
| *** leseb has quit IRC | 12:21 | |
| *** stevemar has joined #openstack-keystone | 12:23 | |
| *** henrynash has quit IRC | 12:26 | |
| *** leseb has joined #openstack-keystone | 12:43 | |
| *** wchrisj has joined #openstack-keystone | 12:51 | |
| *** gokrokve has joined #openstack-keystone | 12:52 | |
| *** bvandenh has joined #openstack-keystone | 12:53 | |
| *** achampion has quit IRC | 12:53 | |
| marekd | dstanek, stevemar: o/ Do you mind taking look at this? https://review.openstack.org/#/c/78142/ | 12:55 |
| stevemar | marekd, sure | 12:55 |
| marekd | docstring fix, however not sure if keystone.conf.sample should be also included (tox made me generate one to pass 'docs' tests) | 12:56 |
| *** gokrokve has quit IRC | 12:56 | |
| ayoung-snore | stevemar, marekd should you be updating the sampleconfig in that patch? | 12:57 |
| marekd | ayoung-snore: that's my concern :-) I am not sure. | 12:57 |
| ayoung-snore | I think that change might have been due to an earlier patch....did you rebase on origin/master | 12:58 |
| marekd | yep, pulled masted, checkout'ed to my branch and fixed the docstring... | 12:58 |
| ayoung-snore | anyway, I'm not here yet...just getting kids to school. Nothing seems to be passing gate anyway | 12:58 |
| marekd | any specific bug, or 'recheck no bug' ? | 12:58 |
| stevemar | marekd, i'm wondering why the conf file is updated, probably shouldn't be | 13:03 |
| *** d0ugal has joined #openstack-keystone | 13:09 | |
| d0ugal | Is there documentation somewhere describing how to make a new service auth with keystone? | 13:09 |
| d0ugal | I've figured out the client part, where it looks up the endpoint with keystone etc. | 13:10 |
| d0ugal | but at the moment our API is completely open, it doesn't actually verify tokens :) | 13:10 |
| stevemar | marekd, i might update it with a new patch, just to remove that conf part | 13:12 |
| *** leseb has quit IRC | 13:14 | |
| *** leseb has joined #openstack-keystone | 13:14 | |
| *** leseb_ has joined #openstack-keystone | 13:15 | |
| *** leseb has quit IRC | 13:15 | |
| *** dstanek has joined #openstack-keystone | 13:16 | |
| marekd | stevemar: up to you. rest is fine, i suppose. | 13:17 |
| stevemar | yeah, it's probably an actual artifact from running the config generation script, but that can be done in another patch | 13:18 |
| stevemar | marekd, it's not your problem to handle :P | 13:19 |
| marekd | ... | 13:19 |
| *** david_lyle_ has quit IRC | 13:20 | |
| marekd | stevemar: ok, i am off from now on. | 13:20 |
| stevemar | okie | 13:20 |
| stevemar | marekd, see you | 13:20 |
| marekd | stevemar: tomorrow! :-) | 13:20 |
| dolphm | o/ | 13:21 |
| dolphm | everyone is awake early | 13:21 |
| dolphm | stevemar: in ~3 hours we won't be gating on sample config changes anymore | 13:21 |
| *** marekd is now known as marekd|away | 13:22 | |
| dolphm | d0ugal: drop keystoneclient.middleware.auth_token in front of your app | 13:24 |
| d0ugal | dolphm: aha! This is exactly what I was looking for. Thanks | 13:25 |
| stevemar | dolphm, yeah, woke up early :\ | 13:27 |
| *** henrynash has joined #openstack-keystone | 13:32 | |
| dstanek | dolphm: this last few days it has caused lots of pain | 13:37 |
| dolphm | dstanek: i'm still slightly sad to see it go | 13:38 |
| dstanek | dolphm: i haven't looked to see if my fears where realized, but i suspect autogen adds options that we don't even support | 13:41 |
| *** leseb_ has quit IRC | 13:42 | |
| dolphm | dstanek: i believe that's true -- i remember skimming past a few options thinking "that's probably useless.." | 13:42 |
| *** browne has joined #openstack-keystone | 13:45 | |
| dstanek | :( | 13:45 |
| *** browne has quit IRC | 13:46 | |
| *** browne has joined #openstack-keystone | 13:48 | |
| *** leseb has joined #openstack-keystone | 13:48 | |
| *** gokrokve has joined #openstack-keystone | 13:52 | |
| *** gokrokve has quit IRC | 13:57 | |
| *** henrynash has quit IRC | 14:03 | |
| lbragstad | dstanek: nice work on the hacking checks | 14:04 |
| lbragstad | reviewing now | 14:04 |
| dolphm | lbragstad: dstanek: link? | 14:04 |
| dstanek | stevemar: thinking about https://review.openstack.org/#/c/60820 again; is there a way to know what the args are | 14:04 |
| lbragstad | https://review.openstack.org/#/c/78116/1 | 14:04 |
| lbragstad | dolphm: ^ starts there | 14:04 |
| *** achampion has joined #openstack-keystone | 14:04 | |
| lbragstad | series with the last one being the addition of hacking | 14:04 |
| dstanek | lbragstad: there should be a few more today - i have to see which things require the least amount of fixes for right now :-) | 14:05 |
| dstanek | these patches will likely churn a ton over time | 14:06 |
| lbragstad | dstanek: ok, I was thinking about that. So, I have a question. Are we going to always push up a patch fixing everything prior to adding the hacking check? | 14:07 |
| lbragstad | or do it all in one commit? | 14:07 |
| lbragstad | with one commit being the check and all the fixes for said check | 14:07 |
| dstanek | i'm doing each fix in a separate commit so it's easier to maintain (at least for me) | 14:08 |
| dolphm | dstanek: ++ | 14:08 |
| stevemar | dstanek, https://review.openstack.org/#/c/78116/ is awesome | 14:08 |
| dstanek | lbragstad: once the sample config check is out of the way i'll make sure all of my patches test OK in Jenkins | 14:08 |
| dolphm | dstanek: free +2 until then | 14:08 |
| dstanek | ha | 14:09 |
| lbragstad | dstanek: ok, sounds good. just looks like they are failing because of sample config | 14:09 |
| lbragstad | I have a real nit picky comment on the first one | 14:09 |
| dstanek | lbragstad: i didn't break the check up (yet), but i may have multple reviews of them | 14:10 |
| lbragstad | ok | 14:10 |
| stevemar | dstanek, you mean the kwargs for the consumer? | 14:11 |
| *** joesavak has joined #openstack-keystone | 14:11 | |
| dstanek | stevemar: yeah, not sure i know what kwargs those methods are expecting | 14:12 |
| dstanek | lbragstad: i responded to your comments | 14:14 |
| dstanek | lbragstad: i'm not sure about the extra spacing | 14:14 |
| *** saju_m has quit IRC | 14:15 | |
| *** leseb has quit IRC | 14:17 | |
| *** bknudson has quit IRC | 14:18 | |
| lbragstad | dstanek: yep, I forgot about the case with multiple comment lines and indentation | 14:19 |
| dstanek | lbragstad: if we need to add that later we can - we'll have to have a global tracking previous physical lines to know if we are the first line in a block comment | 14:20 |
| dstanek | lbragstad: good suggestion on the review #; i'll do that | 14:20 |
| lbragstad | dstanek: good point | 14:20 |
| *** leseb has joined #openstack-keystone | 14:23 | |
| *** gokrokve has joined #openstack-keystone | 14:25 | |
| *** gokrokve has quit IRC | 14:28 | |
| *** gokrokve has joined #openstack-keystone | 14:33 | |
| *** bknudson has joined #openstack-keystone | 14:43 | |
| *** bvandenh has quit IRC | 14:48 | |
| *** henrynash has joined #openstack-keystone | 14:56 | |
| *** henrynash has quit IRC | 15:11 | |
| *** henrynash has joined #openstack-keystone | 15:21 | |
| *** derek_c has joined #openstack-keystone | 15:27 | |
| *** derek_c has quit IRC | 15:29 | |
| *** derek_c has joined #openstack-keystone | 15:29 | |
| *** derek_c has quit IRC | 15:29 | |
| *** derek_c has joined #openstack-keystone | 15:29 | |
| *** ayoung-snore is now known as ayoung | 15:32 | |
| ayoung | you guys wanna see something cool? | 15:32 |
| ayoung | dolphm, this is what happens when ... well , judge for yourself https://github.com/RedHatEMEA/c-keystoneclient | 15:37 |
| dolphm | ayoung: lol | 15:37 |
| ayoung | Yeah | 15:38 |
| ayoung | might not be a bad idea...if we can convince them it should be mod_authz_keystone | 15:38 |
| ayoung | Actually would be nice for Horizon to use something like that | 15:39 |
| *** david-lyle has joined #openstack-keystone | 15:44 | |
| dolphm | success https://github.com/openstack/keystone/commit/e49d3c6b31dcb132eb7990740da5dc4bbd70999e | 15:49 |
| *** chandan_kumar has quit IRC | 15:51 | |
| *** zhiyan is now known as zhiyan_ | 15:53 | |
| bknudson | dolphm: ok... now rechecks... do we have a bug? | 15:54 |
| bknudson | or just nobug since it's fixed. | 15:54 |
| dolphm | bknudson: i think recheck no bug has been disabled :) | 15:54 |
| dolphm | bknudson: file a bug and mark it invalid? | 15:55 |
| dolphm | bknudson: or fix committed and link to your change | 15:55 |
| bknudson | I'll open a bug and fix committed it | 15:55 |
| *** thedodd has joined #openstack-keystone | 15:55 | |
| dolphm | bknudson: ping me with the bug number when it exists | 15:57 |
| bknudson | I thought nova might have one but no | 15:57 |
| dstanek | the title of the bug should be 'no bug' | 15:57 |
| *** chandan_kumar has joined #openstack-keystone | 15:57 | |
| bknudson | https://bugs.launchpad.net/keystone/+bug/1288313 | 15:58 |
| *** gordc has joined #openstack-keystone | 15:59 | |
| stevemar | i do enjoy it when dolphm goes on a -2 spree | 16:02 |
| *** ayoung has quit IRC | 16:03 | |
| *** derek_c has quit IRC | 16:05 | |
| *** leseb has quit IRC | 16:07 | |
| *** leseb has joined #openstack-keystone | 16:07 | |
| *** gordc1 has joined #openstack-keystone | 16:09 | |
| *** ayoung has joined #openstack-keystone | 16:09 | |
| *** gordc has quit IRC | 16:10 | |
| *** leseb has quit IRC | 16:11 | |
| *** gordc1 is now known as gordc | 16:14 | |
| *** derek_c has joined #openstack-keystone | 16:23 | |
| *** leseb has joined #openstack-keystone | 16:25 | |
| *** richm has joined #openstack-keystone | 16:25 | |
| *** henrynash has quit IRC | 16:32 | |
| *** joesavak has quit IRC | 16:33 | |
| *** joesavak has joined #openstack-keystone | 16:35 | |
| *** jsavak has joined #openstack-keystone | 16:37 | |
| *** joesavak has quit IRC | 16:40 | |
| *** achampion has quit IRC | 16:43 | |
| *** gyee has joined #openstack-keystone | 16:47 | |
| *** henrynash has joined #openstack-keystone | 16:50 | |
| *** derek_c has quit IRC | 16:50 | |
| *** topol has joined #openstack-keystone | 16:53 | |
| *** henrynash has quit IRC | 16:54 | |
| *** rwsu has joined #openstack-keystone | 17:03 | |
| *** leseb has quit IRC | 17:05 | |
| *** finite has joined #openstack-keystone | 17:06 | |
| *** harlowja has joined #openstack-keystone | 17:07 | |
| *** jaosorior has quit IRC | 17:10 | |
| *** devlaps has joined #openstack-keystone | 17:13 | |
| dolphm | ayoung: dstanek: morganfainberg: topol: turned the warning into a big-red-box warning https://review.openstack.org/#/c/78058/ | 17:15 |
| *** amcrn has joined #openstack-keystone | 17:15 | |
| ayoung | dolphm, thanks. And thanks for not accidentally rebasing its parent | 17:16 |
| *** chandan_kumar has quit IRC | 17:16 | |
| dolphm | ayoung: ++ | 17:16 |
| *** amcrn has quit IRC | 17:17 | |
| *** amcrn has joined #openstack-keystone | 17:18 | |
| topol | dolphm: Good Call. I like it! | 17:18 |
| *** henrynash has joined #openstack-keystone | 17:26 | |
| ayoung | dolphm, so...priority now would seem to be compressed tokens, or some other way of dealing with the 500 in HTTPD | 17:27 |
| dolphm | ayoung: and bugs ;) | 17:27 |
| dolphm | ayoung: and yeah, that's a bug so ++ | 17:28 |
| ayoung | yeah...so compressed tokens: we can't just drop in a new token format without breaking a lot of clients | 17:28 |
| ayoung | here's a thought | 17:28 |
| ayoung | add a new token format to the client, and get Auth token to deal with it | 17:28 |
| ayoung | then...make a config switch on the server | 17:28 |
| ayoung | its the second part I'm concerned with | 17:29 |
| ayoung | is that too big for RC? | 17:29 |
| ayoung | we'd need to ensure that the new AT is present in any clients that get the new token format before flipping the switch | 17:29 |
| ayoung | dolphm, ? | 17:32 |
| *** lbragstad is now known as lbragstad-lunch | 17:32 | |
| dolphm | ayoung: "a lot of clients" ? | 17:33 |
| dolphm | ayoung: also, it's too late for new config options | 17:33 |
| ayoung | dolphm, either older versions of our clients or things like that 3rd party one I showed you | 17:33 |
| ayoung | OK...so I don't think I can do compressed without something like that. It could possibly be a new token provider, which would not be a new option, but a new value for an existing optionb | 17:34 |
| ayoung | dolphm, something like CompressedPKITokenProvider | 17:34 |
| *** dims has quit IRC | 17:35 | |
| dolphm | ayoung: so, land support in auth_token for decompressing tokens first, release that in say 0.8.0 | 17:35 |
| dolphm | ayoung: ensure all services require at least 0.8.0 | 17:35 |
| dolphm | ayoung: when that's done, start producing compressed tokens by default | 17:36 |
| dolphm | ayoung: it'll be juno, but it'll be safe | 17:36 |
| ayoung | dolphm, that is my thinking. The server side piece will be a very small token provider, and we'll land for Juno. If we don't want to backport, I can find a way to make an out-of-tree version for people that desperately want it in an Icehouse based release | 17:37 |
| *** dims has joined #openstack-keystone | 17:38 | |
| ayoung | dolphm, as far as Kerberos and Horizon, one of my coworkers wrote up a pretty good howto: http://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/ | 17:40 |
| ayoung | the idea is that you log in to Horizon, then Horizon does a Kerberos based delegation to get the token from Keystone. "Server For User To Proxy" or S4U2Proxy is pretty much like Keystone trusts: You set up an agreement in the Kerberos server that says "The Horizon service can use a service ticket from an end user to get a service ticket as that same end user for another service" | 17:42 |
| ayoung | I think that the doc he posted coveres MIT Kerberos in general. | 17:43 |
| ayoung | gyee, ^^ might interest you as well | 17:44 |
| ayoung | topol, you, OTOH have no interest in Kerberos I am sure | 17:44 |
| *** leseb has joined #openstack-keystone | 17:46 | |
| topol | ayoung, have an interest but its not burning my fingers at the moment | 17:46 |
| gyee | ayoung, nice! | 17:47 |
| topol | dolphm, did you get my email from last night? | 17:47 |
| ayoung | gyee, thought you would like. Need to sync that up with Jose's work | 17:47 |
| dolphm | topol: i get email? | 17:47 |
| topol | only from people you respect and admire :-) | 17:48 |
| dolphm | topol: oh yeah, the IRC log | 17:48 |
| dolphm | topol: what channel was that? -dev? | 17:48 |
| topol | no just chatting privately | 17:49 |
| topol | dolphm | 17:49 |
| dolphm | topol: https://github.com/stackforge/python-openstacksdk | 17:49 |
| gyee | ayoung, I am much prefer doing Kerberos outside of Keystone, but if Jose can live with the performance problem with eventlet more power to him :) | 17:49 |
| topol | dolphm, thats different thanwhat was discussed in the irc, correct? Looked like a one off | 17:49 |
| ayoung | gyee, I think there is something wrong with one of his assumptions | 17:49 |
| dolphm | topol: termie's project is a one off | 17:49 |
| topol | dolphm, correct | 17:50 |
| ayoung | I think that Kerberos in HTTPD to get a token, and then use that token in a cookie makes more sense for what he is doing | 17:50 |
| gyee | ayoung, that token binding right? | 17:50 |
| ayoung | , heh, that too | 17:51 |
| ayoung | but I mean if he doesn't want to pay multiple times for Kerberos | 17:51 |
| ayoung | put a separte auth URL under Keystone, only Kerberize that url, and then everything else uses a cookie | 17:51 |
| ayoung | that said, I see no problem with coming up with a Kerberized solution for eventlet, so Long as I don't have to actually make it work | 17:52 |
| dolphm | okay i just finished going through *every* open keystone review and instantiated winter | 17:53 |
| gyee | its an auth plugin so its optional for everybody else :) | 17:54 |
| gyee | dolphm, *every* review? god bless you | 17:54 |
| dolphm | TIME FOR LUNCH | 17:54 |
| * dolphm going through 102 bugs after lunch | 17:55 | |
| gyee | wow | 17:55 |
| *** jsavak has quit IRC | 17:55 | |
| *** jsavak has joined #openstack-keystone | 17:56 | |
| ayoung | post lunch bug triage? | 17:56 |
| ayoung | Deal | 17:56 |
| * stevemar thinks dolphm needs a beer with his lunch | 17:56 | |
| *** marcoemorais has joined #openstack-keystone | 17:58 | |
| dolphm | stevemar: i was thinking something frozen to celebrate feature freeze | 17:59 |
| stevemar | dolphm, really *really* cold beer? or ice cream | 18:01 |
| stevemar | dolphm, just not both | 18:01 |
| *** lbragstad-lunch is now known as lbragstad | 18:03 | |
| dolphm | stevemar: why not both | 18:03 |
| stevemar | dolphm, your stomach will thank me | 18:04 |
| dolphm | stevemar: rofl | 18:04 |
| dolphm | stevemar: i've never had one, but... http://thefreshfridge.com/2011/08/guinness-extra-stout-floats/ | 18:04 |
| stevemar | dolphm, now you're thinking | 18:05 |
| dolphm | stevemar: needs to be some sort of stout, i think | 18:05 |
| lbragstad | ++ to the guiness floats! | 18:08 |
| lbragstad | that might actually be pretty good with a Vanilla porter | 18:08 |
| *** marcoemorais has quit IRC | 18:12 | |
| ayoung | I will spring for a round of Guiness Extra Stout Floats at the Summit if we can find a place that will make them. | 18:14 |
| ayoung | for Keystone Core Devs , lbragstad and topol ] | 18:15 |
| topol | ayoung, THANKS!!! | 18:15 |
| ayoung | topol, we might end up making them ourselves, in which case I will spring for the makings | 18:16 |
| topol | ayoung, either way works for me | 18:16 |
| ayoung | I think the second way sounds better...more scalable | 18:16 |
| * ayoung starts researching places that sell beer and Icecream near the summit site | 18:16 | |
| *** marcoemorais has joined #openstack-keystone | 18:18 | |
| ayoung | Hey! They even call them package stores! I'll be making the packie run! | 18:18 |
| *** leseb has quit IRC | 18:20 | |
| topol | I love the picture at http://thefreshfridge.com/2011/08/guinness-extra-stout-floats/. I want one now! | 18:22 |
| lbragstad | ayoung: http://atlanta.cbslocal.com/top-lists/best-breweries-in-atlanta/ :) | 18:22 |
| *** gokrokve has quit IRC | 18:22 | |
| ayoung | lbragstad, need to crossreference that with the Conference site | 18:23 |
| topol | dolphm, speaking of good food and beverages, I'll be in NYC at a panel next week 2 blocks from the carnegie deli. If I dont make it to Atl its because I had a heart attack eating their corn beef sandwich | 18:23 |
| lbragstad | ayoung: 12 minutes away from Red Brick | 18:24 |
| ayoung | ++ | 18:24 |
| ayoung | lbragstad, I have a lot of College Classmates in Atlanta. I might use that site for a mini-reunion | 18:25 |
| lbragstad | sweetwater isn't far, 10 minutes from GWCC | 18:25 |
| lbragstad | ayoung: winner -- Gordon Biersch Brewery 6 minutes... | 18:27 |
| lbragstad | 2.1 miles | 18:27 |
| ayoung | Meh, Macrobrew now | 18:27 |
| ayoung | Red Brick sounds better | 18:27 |
| lbragstad | yeah, it does sound good | 18:29 |
| ayoung | Last time I was in Atlanta (short of plane changing) I was a New 2nd Lieutenant | 18:30 |
| *** amcrn_ has joined #openstack-keystone | 18:32 | |
| *** amcrn has quit IRC | 18:32 | |
| gyee | ayoung, S4U2Proxy only works with LDAP backend huh | 18:37 |
| ayoung | lbragstad, 5 Seasons is pretty close | 18:38 |
| ayoung | gyee, "only" I don't think so | 18:38 |
| gyee | for the MIT impl I mean | 18:38 |
| ayoung | He did the FreeIPA setup which is LDAP based | 18:38 |
| ayoung | I can ask | 18:38 |
| lbragstad | yeah, that one looks good too | 18:39 |
| ayoung | gyee, what backend would you use instead? | 18:39 |
| gyee | ayoung, for public cloud, we use MongoDB | 18:40 |
| ayoung | For Kerberos? Really? | 18:40 |
| gyee | for private cloud, pretty much whatever customers ask | 18:41 |
| ayoung | neat...didn't know that was an option | 18:41 |
| gyee | ayoung, I mean we have our own mongo driver | 18:41 |
| ayoung | gyee, that is beyond my knowhow | 18:42 |
| *** jordant has joined #openstack-keystone | 18:45 | |
| ayoung | gyee, can you jump into #freeipa? | 18:49 |
| stevemar | ayoung, i'm gonna +A the experimental patch :O | 18:49 |
| ayoung | ++ | 18:49 |
| ayoung | https://review.openstack.org/#/c/55908/ "Change has been successfully merged into the git repository." and with that All BPs are complete for I3 | 19:00 |
| lbragstad | ++ nice | 19:02 |
| *** raenbakov has joined #openstack-keystone | 19:03 | |
| ayoung | thanks to all involved....I will now collapse for 10 minutes | 19:03 |
| topol | ayoung, last time you searched in your neighbors cube for something to have as your celebratory drink (trusts) | 19:05 |
| topol | I remember it well | 19:05 |
| ayoung | topol, Shh, he still doesn't know it was me. It was good scotch, too | 19:05 |
| topol | rofl | 19:05 |
| luisbg | ayoung, +1 thanks to all triagers | 19:05 |
| *** packet has joined #openstack-keystone | 19:09 | |
| *** gokrokve has joined #openstack-keystone | 19:23 | |
| *** joesavak has joined #openstack-keystone | 19:34 | |
| *** jsavak has quit IRC | 19:35 | |
| *** joesavak has quit IRC | 19:39 | |
| ayoung | On the compressed token format, I am uncomfortable using {} to distinguish the header of the token, as the braces are not URL safe. Neither is ## or any of the other reserved character | 19:53 |
| ayoung | s | 19:53 |
| bknudson | pick something url safe, -s or _ or something | 19:57 |
| *** marcoemorais has quit IRC | 20:02 | |
| *** marcoemorais has joined #openstack-keystone | 20:03 | |
| ayoung | bknudson, I think I'm going to have to....just want to come up with something that doesn't trip us up in the future | 20:04 |
| * dolphm back from lunch and happy to see icehouse-3 Implemented across the board | 20:06 | |
| *** raenbakov has quit IRC | 20:06 | |
| *** amcrn_ has quit IRC | 20:09 | |
| ayoung | bknudson, here's the thing: I really want to do something like state at each level what the format is; the token really should just say _BASE64_ and then when you decod ethat, the prefix of the underlying data would be "_GZIP_" and then when you gunzip it you get "_PEM_" but...the only thing that is guaranteed to be characters is the BASE64 encoded version | 20:19 |
| ayoung | So...I could stick it all in one header: | 20:20 |
| ayoung | _B64-GZIP-DER-JSON_ | 20:20 |
| ayoung | (DER, not PEM) | 20:20 |
| dolphm | ayoung: why not just version them sequentially? | 20:21 |
| *** marcoemorais has quit IRC | 20:21 | |
| ayoung | dolphm, ? | 20:21 |
| dolphm | ayoung: if uuid tokens are unversioned but v1, and pki was unversioned v2, start with 3-* | 20:22 |
| ayoung | dolphm, one reason is that I am hoping to be able to use the same mechanism for data other than tokens | 20:22 |
| ayoung | dolphm, for instance, the revocation events, or any data out of keystone | 20:22 |
| finite | Hello again all, still trying to achieve success with Keystone SSL. Going through this doc to add SSL, I'm stuck at the "Files" section. I can't find a keystone.py file that its referring to. http://docs.openstack.org/developer/keystone/apache-httpd.html#files | 20:22 |
| dolphm | ayoung: there's a lot more to the process than just the 4 steps you mentioned (like the arbitrary string manipulation that goes on) | 20:23 |
| ayoung | but also, potentially for use with Oslo messaging | 20:23 |
| ayoung | dolphm, that string manip will go away | 20:23 |
| ayoung | the process is: | 20:23 |
| ayoung | 1 CMS sign to der format | 20:23 |
| ayoung | 2 compress (z lib) | 20:23 |
| ayoung | 3 base64_urlsafe encode (python library call) | 20:23 |
| ayoung | dolphm, and, implicit step 0 convert object to JSON | 20:24 |
| dolphm | ayoung: so call the process token version '3'? | 20:25 |
| *** arborism has joined #openstack-keystone | 20:25 | |
| dolphm | ayoung: or just PKIv2 or something | 20:25 |
| ayoung | dolphm, question is whether we want to be able to switch out the signing to handle the KDS stuff | 20:26 |
| ayoung | I'd like to be able to indicate that the rest is the same, but the message is mac'ed | 20:26 |
| bknudson | finite: keystone.py is the file you're supposed to create according to the documentation | 20:26 |
| bknudson | ayoung: why is some kind of versioning needed? | 20:27 |
| bknudson | the client isn't going to be able to tell the difference? | 20:27 |
| ayoung | bknudson, Auth Token needs to know how to interpret what it is given | 20:27 |
| ayoung | bknudson, the approach for PKI thus far is sub-optimal | 20:28 |
| ayoung | to say the least | 20:28 |
| bknudson | Just look for MII | 20:28 |
| ayoung | yeah | 20:28 |
| ayoung | so, really, that is just...wrong | 20:28 |
| bknudson | so your step 4 is stick some different prefix ahead of base64. | 20:29 |
| ayoung | MI would be slightly better, but...the resulting code is not even real Base64 url safe | 20:29 |
| bknudson | pki2-<base64> | 20:29 |
| ayoung | bknudson, yeah....question is what to put there | 20:29 |
| ayoung | I was origianlly thinking CMSZ | 20:29 |
| ayoung | since CMS is the signed document, and Z is compressed | 20:29 |
| ayoung | {CMSZ} | 20:29 |
| ayoung | but...someone pointed out {} is not url safe. | 20:30 |
| bknudson | cmsz-<base64> | 20:30 |
| ayoung | CMSZ64 | 20:30 |
| bknudson | ok. I'm not too picky as long as it doesn't start with MII | 20:30 |
| ayoung | but it is the oslo messaging thing that got me thinking | 20:30 |
| bknudson | MIIz64 | 20:30 |
| ayoung | HA! | 20:30 |
| dolphm | ayoung: pkiz-<base64> (everyone knows what "pki tokens" are already, i'd rather not start calling it cms when it's not radically different) | 20:31 |
| dolphm | ayoung: but really the implementation details don't need to be in the prefix | 20:31 |
| ayoung | dolphm, _pkiz64_ ? | 20:31 |
| ayoung | can't use <> for the same reason as {} | 20:31 |
| ayoung | actaully, I probably *can* | 20:31 |
| ayoung | as I don't expect to actually put the whole body of the token in an URL, but only in a header | 20:32 |
| bknudson | don't need the <>, it was just to indicate that it's replaced and not constant | 20:32 |
| dolphm | ayoung: i really think pki2- or something, don't make it complicated | 20:32 |
| ayoung | dolphm, I was thinking that keystone client should be able to decode a token....and if a token, why not arbitrary data. I wasthinking in terms of a KDS client | 20:33 |
| bknudson | just don't make the prefix too long otherwise the compressed token will be longer than an uncompressed one. | 20:33 |
| dolphm | ayoung: and don't use too many unnecessary chars ;) | 20:33 |
| ayoung | and how CMS makes much more sense for pub sub in Oslo messaging | 20:33 |
| *** marcoemorais has joined #openstack-keystone | 20:33 | |
| ayoung | so if Oslo could use the keystone client to validate signed messages as well as tokens | 20:33 |
| dolphm | ayoung: that's sort of the end goal for KDS already, no? | 20:33 |
| ayoung | yep | 20:33 |
| ayoung | and KDS does not have a client | 20:33 |
| ayoung | and putting in a new client would be annoying | 20:34 |
| finite | bknudson, thanks I didn't see where I was going to make that file. This document is confusing me really heh. The only lead I have going right now is that my wsgi-keystone file has entires for main and admin and they pint to the cgi-bin/keystone directory, but nothing about that python file. | 20:34 |
| ayoung | but Keystone client is already pretty much everywhere | 20:34 |
| bknudson | finite: I think this is keystone.py -- https://github.com/openstack/keystone/blob/master/httpd/keystone.py | 20:35 |
| bknudson | finite: so I think the docs are just saying to look for this file wherever you've got keystone installed. | 20:35 |
| dolphm | ayoung: just in case https://launchpad.net/python-kiteclient/ | 20:36 |
| ayoung | bknudson, if finite used an RPM or DEB, it probably ended up in /usr/share | 20:36 |
| ayoung | Nice! | 20:36 |
| bknudson | maybe the openstack-sdk will be far enough along by then. | 20:37 |
| ayoung | dolphm, can keystone the program support a separate project like Kite? Does any program have multiple projects other than client/server splits? | 20:37 |
| finite | bknudson, ayoung, (wave @ ayoung) I used the rdo-release repo on centos 6.4 | 20:37 |
| ayoung | finite, fairly certain it is in /usr/share/openstack-keystone | 20:37 |
| ayoung | but | 20:37 |
| dolphm | ayoung: yes and yes, sort of | 20:38 |
| bknudson | I always use devstack | 20:38 |
| dolphm | ayoung: keystone is in the identity program, "kite" could be as well | 20:38 |
| finite | ayoung, i have /usr/shave/keystone , but not /usr/share/openstack-keystone | 20:38 |
| ayoung | dolphm, I know we keep trying to stick KDS with Barbican, as Barbican was origianlly Cloud Keep and was going to be all things crypto | 20:38 |
| bknudson | I think nova has several projects -- scheduler, etc. | 20:38 |
| ayoung | finite, that is probably it | 20:38 |
| ayoung | bknudson, but those are all in one git repo | 20:39 |
| ayoung | no? | 20:39 |
| finite | ayoung, yea that dir doesn't have httpd in it at all :( | 20:39 |
| ayoung | rpm -q --list | 20:39 |
| ayoung | proably | 20:39 |
| ayoung | rpm -q --list openstack-keystone | 20:40 |
| dolphm | ayoung: i'd rather just build the right technical solutions and the technical committee can be free to group them into programs for governance purposes | 20:40 |
| ayoung | dolphm, Oh, I agree | 20:41 |
| finite | ayoung yup /usr/share/keystone, but no httpd dir in the list | 20:41 |
| ayoung | just that the only people that seem at all concerned with getting KDS right are on Keystone... | 20:41 |
| dolphm | ayoung: fwiw, i'm wearing the "Identity Program Technical Lead" hat now, not the "Keystone Project Technical Lead" hat | 20:41 |
| ayoung | finite, I know that was an open bug, but | 20:41 |
| ayoung | you can always use the upstream version | 20:41 |
| dolphm | ayoung: ("PTL" was repurposed) | 20:42 |
| bknudson | power grab | 20:42 |
| ayoung | https://github.com/openstack/keystone/blob/master/httpd/keystone.py | 20:42 |
| finite | ayoung, aww borken packages :( | 20:42 |
| ayoung | finite, maybe. | 20:42 |
| ayoung | finite, I opened the BZ, but I thought it had been closed as fixed | 20:42 |
| ayoung | lemme see if I can find the RPM spec file and see if it went elsewhere | 20:43 |
| bknudson | dolphm: is there a reason https://review.openstack.org/#/c/75549/ was blocked as a new feature and not a bug fix? | 20:43 |
| *** marcoemorais has quit IRC | 20:43 | |
| dolphm | bknudson: yeah, i wanted to talk about that one | 20:44 |
| bknudson | I realize that the oslo-incubator db code did change significantly. | 20:44 |
| dolphm | bknudson: first and and foremost because it's +1186 / 0568 | 20:44 |
| dolphm | -568* | 20:44 |
| dolphm | bknudson: second because it affects config options, obviously | 20:44 |
| bknudson | dolphm: y, I see there's new config options. | 20:45 |
| bknudson | dolphm: what do you think about cherry-picking the changes we need for oslo-incubator to fix the bug? | 20:45 |
| ayoung | finite, I think this is it https://github.com/redhat-openstack/openstack-keystone/blob/master/openstack-keystone.spec | 20:46 |
| dolphm | bknudson: consider everything we do until RC1 to be a stable backport -- i think that would be a more backportable approach | 20:46 |
| ayoung | but ... it says milestone 3 | 20:46 |
| dolphm | bknudson: would it be cherry picking from this patch, basically? | 20:47 |
| bknudson | dolphm: btw - there's another bug that could be fixed with an oslo-incubator change -- when you start the server it prints out a WARNING about mysql something. | 20:47 |
| dolphm | bknudson: i saw that on list -- we'll need that too | 20:47 |
| ayoung | finite, it has to be accounted for in the spec file one way or another, either included or exclueded | 20:47 |
| dolphm | bknudson: WARNING mysql will eat all your data | 20:47 |
| bknudson | dolphm: but that's a config change, too... | 20:48 |
| bknudson | I think it can be worked around with the code we've got too by passing something to db. | 20:48 |
| dolphm | bknudson: that's what i understood (it didn't affect every project as-is?) | 20:48 |
| dolphm | bknudson: keystone also wasn't named in the thread, so i wasn't sure | 20:48 |
| dolphm | bknudson: but every other core project was, IIRC | 20:49 |
| dolphm | bknudson: so i figured we were just forgotten about per usual | 20:49 |
| finite | ayoung, doing a rpm -qa I get openstack-keystone-2013.2.1-1.el6.noarch I assume this is the first milestone. | 20:49 |
| finite | not the third | 20:49 |
| ayoung | finite, RHOS4 would be Havana final | 20:49 |
| bknudson | dolphm: maybe they were thinking we'd be able to merge the oslo-incubator db changes since we seemed to be further along. | 20:49 |
| ayoung | http://pkgs.fedoraproject.org/cgit/openstack-keystone.git/tree/openstack-keystone.spec | 20:50 |
| ayoung | that is Ice2 | 20:50 |
| bknudson | dolphm: Even though we were up to date just a couple months ago it's still taken +1186 / -568 lines to re-sync! | 20:50 |
| ayoung | finite, note http://pkgs.fedoraproject.org/cgit/openstack-keystone.git/tree/openstack-keystone.spec#n140 | 20:50 |
| dolphm | bknudson: i know :( | 20:51 |
| ayoung | http://pkgs.fedoraproject.org/cgit/openstack-keystone.git/tree/openstack-keystone.spec?h=f20#n133 finite that one is stable Havana | 20:51 |
| *** gokrokve has quit IRC | 20:51 | |
| stevemar | dolphm, so, theres a lot of references to tenant and keystoneclient in the docs, is that something we want to change? | 20:51 |
| ayoung | finite, do you have openstack-keystone-sample-data | 20:51 |
| finite | ayoung, I see. Thanks for finding all that info. I'm pulling from here: [rdo-release] name=OpenStack Havana Repository baseurl=http://repos.fedorapeople.org/repos/openstack/openstack-havana/epel-6/ | 20:52 |
| dolphm | stevemar: *and* keystoneclient? or in? | 20:52 |
| finite | ayoung, yes sir | 20:52 |
| dolphm | stevemar: (what's wrong with referencing keystoneclient?) | 20:52 |
| stevemar | dolphm, trouble is, if we change just tenant to project, it'll muck up the keystoneclient examples, cause they use tenant-create | 20:52 |
| stevemar | dolphm, ^ | 20:52 |
| finite | ayoung I do have the openstack-keystone-sample-data | 20:52 |
| ayoung | finite, ah..dang, itsin the wrong dir, though | 20:52 |
| dolphm | stevemar: oh yeah, be careful about it. if it's in the context of v2, it should still say "tenant" | 20:52 |
| finite | ayoung, its in /usr/bin/openstack-keystone-sample-data | 20:52 |
| ayoung | yeah | 20:53 |
| ayoung | we need | 20:53 |
| dolphm | stevemar: or tenant (i.e. project) | 20:53 |
| ayoung | sample_data.sh | 20:53 |
| stevemar | dolphm, correct, but for the most part it's used in a non-versioned way | 20:53 |
| ayoung | that is also in %{buildroot}%{_datadir} just like httpd is | 20:53 |
| dolphm | stevemar: and project in the context of v3 (or where there is no API version in context, go with project) | 20:53 |
| ayoung | I assume that is /usr/share/keystone or something like that | 20:54 |
| stevemar | dolphm, my main points of concern: http://docs.openstack.org/developer/keystone/configuringservices.html | 20:54 |
| finite | ayoung, yup /usr/share/keystone | 20:54 |
| ayoung | feh | 20:55 |
| ayoung | grab the upstream | 20:55 |
| dolphm | bknudson: skimming through the patch i don't see anything risky | 20:55 |
| ayoung | its the same code anyway | 20:55 |
| finite | interesting. so much for packages. | 20:55 |
| ayoung | grab havana stables version if you want to be "in sync" though I don't think we've done anything special to it | 20:55 |
| dolphm | bknudson: i assume the config options coming out of oslo are backwards compatible | 20:55 |
| stevemar | dolphm, and here: http://docs.openstack.org/developer/keystone/architecture.html ctrl+f tenant that stuff, lots of references between the two links | 20:56 |
| finite | ayoung, awesome sir, thank you for helping me these past few days. Greatly appreciated. | 20:56 |
| ayoung | dependency.resolve_future_dependencies() went in Icehouse...grab the Havana version | 20:56 |
| dolphm | stevemar: yeah, those should mostly be changed to reference projects or both | 20:57 |
| ayoung | finite, I'll put it on your tab | 20:57 |
| ayoung | you can help me pay for the Guiness Stout Floats at the summit | 20:57 |
| bknudson | dolphm: the "#slave_connection=" was removed... keystone never used it, and it's also a little insensitive. | 20:57 |
| finite | ayoung ;) you take amex/square heh | 20:57 |
| finite | or will beer do | 20:57 |
| dolphm | bknudson: *this* sync doesn't fix the bug from the mailing list, right? | 20:58 |
| ayoung | Single Malt Scotch is the preferred method of payment. | 20:58 |
| bknudson | dolphm: no, we'd need another sync | 20:58 |
| bknudson | dolphm: I was in the middle of doing that but got distracted | 20:58 |
| finite | ayoung niiiccee | 20:59 |
| *** marcoemorais has joined #openstack-keystone | 21:00 | |
| ayoung | finite, I'm not super picky, but there have been some I've tasted that tast like rubbing alcohol. I don't need 21 year old, but ... it needs to smell good. There is a reason we call the candy Butterscotch | 21:01 |
| ayoung | MacAllen's and Balvenie 10 are both good enough for my palate. | 21:01 |
| ayoung | Ah Macallan | 21:02 |
| ayoung | new I had that wrong | 21:02 |
| ayoung | anyway, back to software. | 21:02 |
| dolphm | bknudson: i just did a full code review, mostly ignoring the changes to keystone.openstack.common ... i'd be happy to land it if it has overwhelming support ASAP (because it still looks like a scary-sized patch on the road to RC) | 21:02 |
| ayoung | dolphm, I like _PKIZ64_ | 21:02 |
| ayoung | gonna go with that | 21:02 |
| dolphm | ayoung: but the first underscore is unnecessary, and pki was already base 64 encoded | 21:03 |
| bknudson | 64 like 64-bits? | 21:03 |
| bknudson | can I use it on my 32-bit system? | 21:03 |
| * dolphm [openstack][keystone] trying to deploy to precise32, but unable to find _PKIZ32_ packages? | 21:04 | |
| ayoung | dolphm, it wasn't really BASE64 more like Base64ish | 21:05 |
| bknudson | ayoung dstanek henrynash stevemar morganfainberg gyee jamielennox|away -- any opinion on getting oslo sync in -- https://review.openstack.org/#/c/75549/ ? | 21:05 |
| dolphm | ayoung: base64_urlsafe isn't base64 either, it's just another convention being applied (and it's super convenient because it's stdlib) | 21:06 |
| dolphm | bknudson: ++ | 21:06 |
| ayoung | bknudson, how important is 75549? | 21:06 |
| stevemar | bknudson, i'll play devils advocate, why do want it in? | 21:07 |
| ayoung | looks like IBM might want that | 21:07 |
| ayoung | DB2 | 21:07 |
| dolphm | ayoung: ++ | 21:07 |
| ayoung | DBDuplicateEntry not being translated for DB2 | 21:07 |
| bknudson | ayoung: without it we've got a regression with DB2. | 21:07 |
| dolphm | although i marked the bug as Low initially | 21:07 |
| ayoung | bknudson, I'm looking. | 21:07 |
| stevemar | ahh | 21:08 |
| ayoung | seems like a lot of file to sync at once | 21:08 |
| ayoung | are they all SQL related? | 21:08 |
| ayoung | yeah..they are | 21:08 |
| dolphm | ayoung: it's all common.db except for gettextutils | 21:08 |
| ayoung | yep... | 21:08 |
| ayoung | I'm ok with the sync... | 21:08 |
| stevemar | then it would make sense | 21:08 |
| bknudson | ayoung: yes, sadly it was a large change that the oslo team made to the db code :( | 21:08 |
| ayoung | looking at the effect on the keystone code | 21:08 |
| dolphm | ayoung: stevemar: the only code worth reviewing in keystone is here https://review.openstack.org/#/c/75549/10/keystone/common/sql/core.py | 21:08 |
| ayoung | I wish "diff all side by side" didn't automatically mark all files as "reviewed" | 21:09 |
| *** andreaf has joined #openstack-keystone | 21:09 | |
| ayoung | is (sql.get_engine() going to mess us up on unit testing? | 21:10 |
| bknudson | ayoung: I updated tests/core.py | 21:10 |
| ayoung | bknudson, I'm just thinking about how we do the migrations for testing...nothing in this patch changes the rules there? | 21:11 |
| bknudson | ayoung: we really don't use get_engine often... there's only a couple of places where it's used. | 21:11 |
| bknudson | ayoung: no, everything really works the same way. | 21:11 |
| ayoung | bknudson, but a couple of tests do it specifically | 21:11 |
| dolphm | ayoung: other than test_sql_upgrade? | 21:11 |
| ayoung | keystone/tests/test_associate_project_endpoint_extension.py for example | 21:11 |
| dolphm | ayoung: ?? it does? | 21:12 |
| ayoung | and that will share the engine | 21:12 |
| bknudson | ayoung: the oslo code changed so that it doesn't have a global engine anymore. | 21:12 |
| ayoung | https://review.openstack.org/#/c/75549/10/keystone/tests/test_associate_project_endpoint_extension.py | 21:12 |
| bknudson | we used to use that global engine. | 21:12 |
| bknudson | and now keystone has to have the global engine | 21:12 |
| ayoung | bknudson, yeah...I battled with that when trying to get migrations to work with an in-memory database | 21:12 |
| ayoung | it kept killing the engine and wiping out the database | 21:12 |
| ayoung | I really wanted in memory sqlite for testing | 21:13 |
| bknudson | ayoung: right, have to use the same engine all the time... that should work now. | 21:13 |
| ayoung | instead of having to mount the ramdisk...but that is not going to happen | 21:13 |
| ayoung | interesting...I wonder if the migration code does that now> | 21:13 |
| ayoung | it was in the upstream code, not ourse that the engine was destroyed | 21:13 |
| bknudson | ayoung: in https://review.openstack.org/#/c/75549/10/keystone/tests/test_associate_project_endpoint_extension.py it's going to get the same engine both times. | 21:14 |
| bknudson | ayoung: in sqlalchemy-migrate? | 21:14 |
| ayoung | yeah | 21:14 |
| ayoung | I think this code is fine... | 21:14 |
| dolphm | bknudson: this is also still new against every other project -- so is every project broken in this regard in icehouse? | 21:15 |
| dolphm | in progress on heat and nova, new on cinder, glance neutron | 21:16 |
| dolphm | s/every other project/several other projects/ | 21:16 |
| finite | ayoung, adding to my tab, is it a good idea to have both an SSL enabled keystone service and a swift proxy SSL enabled service talking to each other using a corporate signed PKI? | 21:17 |
| bknudson | dolphm: the bugs that are in oslo are kind of funny because you don't know if someone has merged the fix for it already... | 21:17 |
| ayoung | finite, that question sounds rhetorical | 21:17 |
| bknudson | I took on the keystone one because we actually hit it in our internal CI system. | 21:17 |
| dolphm | bknudson: oh true | 21:18 |
| ayoung | the alternative is either a selfsigned cert (bad) or no SSL (worse) | 21:18 |
| ayoung | what are your really asking finite ? | 21:18 |
| morganfainberg | dolphm, for migration collapse do we want 2 cycles for upgrade? i'll keep where i'm at for J1 then | 21:18 |
| dolphm | morganfainberg: yes, so collapse essex -> grizzly? | 21:18 |
| bknudson | which hopefully our CI system will be able to start reporting to gerrit sometime soon. | 21:18 |
| morganfainberg | dolphm, for J, essex->H | 21:19 |
| finite | ayoung, apologies, I guess I'm trying to ask is it not dumb to try to ssl both keystone and a swift proxy on the same box using internally signed certs. | 21:19 |
| morganfainberg | so to migrate to J you need to be on H | 21:19 |
| morganfainberg | and in K we'll move that to I etc. | 21:19 |
| dolphm | morganfainberg: so you should be able to upgrade from grizzly -> icehouse with the icehouse release, for example | 21:19 |
| dolphm | morganfainberg: right | 21:19 |
| morganfainberg | dolphm, and since we're blocking the collapse (-2 for FF) | 21:19 |
| morganfainberg | i'll just aim for J1 | 21:19 |
| dolphm | morganfainberg: oh, that's another -2 i wanted to check in on -- there's no benefit to nuking our work there right before release, right? | 21:20 |
| ayoung | finite, finite if you have a corporate CA that can sign, you should use it. Clients are going to be talking to Keystone, and you want all that to be properly authenticate and authorized | 21:20 |
| dolphm | morganfainberg: but it'll save us maintenance effort over the next release cycle | 21:20 |
| morganfainberg | dolphm, correct | 21:20 |
| ayoung | selfsign is a blight. I should never have written it | 21:20 |
| morganfainberg | dolphm, if we could have squeezed it in, great, but it will have 0 effect for I | 21:20 |
| morganfainberg | dolphm, so putting it in J is 100% good | 21:21 |
| ayoung | finite, I'm trying to change things over to using certmonger | 21:21 |
| dolphm | morganfainberg: is it tracked against a BP? | 21:21 |
| morganfainberg | dolphm, nope, going to open one for J | 21:21 |
| dolphm | morganfainberg: "next" | 21:21 |
| morganfainberg | dolphm, ++ | 21:21 |
| dolphm | morganfainberg: i don't think we get J targets until april | 21:21 |
| morganfainberg | dolphm, right | 21:21 |
| morganfainberg | dolphm, i'll also open the "juno" named deprecation one | 21:21 |
| morganfainberg | but tag it to "next" | 21:22 |
| dolphm | morganfainberg: assign to Keystone Drivers | 21:22 |
| morganfainberg | dolphm, ++ | 21:22 |
| dolphm | morganfainberg: and put UUID tokens on the list for juno :) | 21:22 |
| morganfainberg | dolphm, ++ | 21:23 |
| morganfainberg | dolphm, a massive ++ | 21:23 |
| finite | ayoung, yeah I took a look at that project yesterday. I'm just trying to get a grasp on what was failing before I started looking at the doc that kicked off today's questioning heh. The keystone service was running using SSL, but then the proxy service started throwing 400s when trying to use the tokens. | 21:23 |
| dolphm | morganfainberg: += sys.maxint | 21:23 |
| morganfainberg | dolphm, yes!! | 21:24 |
| ayoung | finite, was keystone+SSL and nova/horizon working ok? | 21:25 |
| finite | ayoung, only using swift at this point. Near future adding nova/horizon, but right now the only other piece is swift | 21:26 |
| morganfainberg | dolphm, https://blueprints.launchpad.net/keystone/+spec/sql-migration-collapse-juno | 21:26 |
| *** leseb has joined #openstack-keystone | 21:27 | |
| ayoung | finite, so you can talk to keystone fine using the command line client, just not from swift? | 21:29 |
| morganfainberg | dolphm, https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-juno | 21:32 |
| *** leseb has quit IRC | 21:32 | |
| finite | ayoung, so yeah using curl I could get a token (with -k to ignore the ssl complaint about it not being a trusted CA) just fine, but when taking that token and pointing to our proxy end point, the proxy returns with a 401 | 21:32 |
| ayoung | finite, you see the problem right? | 21:33 |
| ayoung | -k? | 21:33 |
| morganfainberg | ayoung, i saw the notice... revocation events merged. | 21:34 |
| morganfainberg | ayoung, gratz | 21:34 |
| ayoung | morganfainberg, did you see my response? | 21:34 |
| finite | ayoung, yeah thats a whole other thing, but non-trusted CAs aside, assuming keystone service is running, the proxy service should be able to auth to it? no? | 21:34 |
| ayoung | finite, I think that if you run with a non-trusted CA, you get a different error than the 401, but not sure | 21:35 |
| ayoung | I would assume it would be a non-http error | 21:35 |
| morganfainberg | ayoung, no | 21:35 |
| morganfainberg | ayoung, lots of scrollback - let me go looking *scrolls up* | 21:36 |
| gyee | bknudson, sorry missed your ping earlier, I am fine with oslo sync | 21:36 |
| ayoung | morganfainberg, I am planning a night of making Guiness Stout Floats at the summit | 21:36 |
| dolphm | easy review https://review.openstack.org/#/c/76249/ | 21:36 |
| morganfainberg | ayoung, ++ | 21:36 |
| dolphm | ayoung: lol i'm in | 21:37 |
| ayoung | dolphm, +2 | 21:37 |
| morganfainberg | dolphm, +2/+A | 21:37 |
| gyee | ayoung, *making* or *drinking*? | 21:37 |
| ayoung | dolphm, I figure I'll buy the fixings, we all make our own | 21:37 |
| bknudson | gyee: ok, thanks. | 21:37 |
| ayoung | much cheaper than spotting for them at a bar | 21:38 |
| morganfainberg | dolphm, i'm +A transifex stuff | 21:38 |
| morganfainberg | dolphm, unless you want me to wait | 21:38 |
| dolphm | ayoung: where summit session does this fit into? i want to be sure to attend | 21:38 |
| ayoung | I mena, yeah, it iwll be caned guines, not fresh, but I figure if we are making floats out of them, who is going to be able to tell | 21:38 |
| ayoung | dolphm, I'm thinking Monday night | 21:38 |
| ayoung | kick the summit off right | 21:38 |
| dolphm | morganfainberg: i wanted to double check against string freeze actually; but i think that particular change is safe | 21:39 |
| morganfainberg | dolphm, also, iirc generally it's accepted (discussed last summit) any core can +2/+A transifex as long as it looks good, no need for 2 cores | 21:39 |
| dolphm | morganfainberg: otherwise translations are broken | 21:39 |
| dolphm | morganfainberg: ++ | 21:39 |
| morganfainberg | dolphm, string freeze is... what closer to RC? | 21:39 |
| morganfainberg | right? | 21:39 |
| morganfainberg | or am i confused | 21:40 |
| dolphm | morganfainberg: https://wiki.openstack.org/wiki/Icehouse_Release_Schedule | 21:40 |
| dolphm | morganfainberg: today | 21:40 |
| * morganfainberg is confused | 21:40 | |
| morganfainberg | ah | 21:40 |
| morganfainberg | dolphm, yep | 21:40 |
| morganfainberg | dolphm, anyway, transifex should always be safe | 21:40 |
| morganfainberg | dolphm, it's translations, not strings :) | 21:40 |
| dolphm | morganfainberg: yeah | 21:40 |
| dolphm | morganfainberg: i'd be happy to +A myself, i just wasn't 100% sure when i looked at it | 21:41 |
| morganfainberg | dolphm, :) | 21:42 |
| morganfainberg | dolphm, cool | 21:42 |
| ayoung | so if pkiz64 is for tokens,m and we extended to kds...that would be, what? something to indicate symmetric crypto | 21:47 |
| ayoung | macz64? | 21:47 |
| *** arborism is now known as amcrn | 21:50 | |
| dstanek | keystone broke my inbox - when from from 'inbox 0' to 'inbox 2**16' | 21:50 |
| morganfainberg | dstanek, time to declare email bankruptcy | 21:51 |
| dolphm | dstanek: inbox 0 is on the list with unicorns | 21:52 |
| dolphm | i'm at 9322 unread | 21:53 |
| bknudson | here's the oslo-incubator sync to get rid of the mysql warning -- https://review.openstack.org/#/c/78429/1/keystone/openstack/common/db/options.py | 21:55 |
| dolphm | morganfainberg: thoughts? https://review.openstack.org/#/c/77325/ | 21:55 |
| dolphm | morganfainberg: (see my comment this morning) | 21:55 |
| bknudson | I thought there was a reason for truncating passwords? Something about the time to crypt. | 21:56 |
| dolphm | bknudson: that's exactly it | 21:56 |
| dstanek | dolphm: what does it do instead of truncate? | 21:56 |
| dstanek | how is the max size globally mutable? does he mean malicious Python code? | 21:58 |
| *** marcoemorais has quit IRC | 22:02 | |
| dstanek | man, openstack is talking about moving off of freenode and onto oftc | 22:06 |
| dstanek | not cool! | 22:06 |
| dstanek | it's like saying 'come on ohio (all of you), you need to go to maine' | 22:07 |
| *** marcoemorais has joined #openstack-keystone | 22:07 | |
| morganfainberg | dolphm, looking now | 22:11 |
| morganfainberg | dstanek, i think he's thinking bad code, malicious python, or bad config | 22:12 |
| morganfainberg | dolphm, ++ on your comment | 22:13 |
| morganfainberg | dolphm, 100% for that | 22:13 |
| morganfainberg | dolphm, if we want to not truncate, an option ot make it strict would be good | 22:13 |
| morganfainberg | we can transition that to default next cycle if we like it | 22:13 |
| morganfainberg | dolphm, alternatively... we could make it a frozen value so one conf is loaded, you can't change the password_length value, settable only at conf read time | 22:14 |
| morganfainberg | dstanek, ^ | 22:14 |
| morganfainberg | i'm not sure i agree with the "sky is falling" tone of the bug that globally mutable is bad in this case. it would take some serious missteps to cause an issue i think. | 22:15 |
| dstanek | morganfainberg: nah, i can just as easilty replace keystone.common.utils.hash_password and i can change an int | 22:15 |
| dstanek | in fact i can make a plugin to just automatically email me all the passwords | 22:15 |
| morganfainberg | dstanek, true | 22:15 |
| morganfainberg | dstanek, i do agree that password length enforcement is better as a 400. | 22:16 |
| morganfainberg | rather than truncating. | 22:16 |
| morganfainberg | but eh, i think this is wishlist, J timeline and needs an option to change behavior | 22:16 |
| dstanek | IMO it's not a security issue that we can do much about | 22:17 |
| ayoung | dolphm, do we need "incubation permission" from the Technical commitee to spin up another project under Identity, or do we as core have the right to decide to do that? Say we thought we should spin off...the policy distribution into its own service and git repo, could we make that decision? | 22:17 |
| morganfainberg | dolphm, i vote -2 (FF), aim for J and go with your suggestion if we want that enforcement. | 22:17 |
| morganfainberg | ayoung, if we want to increase scope, we need to get TC approval. We can't "incubate" a project, but can claim it under identity. Incubation still needs to be officially approved by TC | 22:19 |
| morganfainberg | ayoung, based upon the KDS discussions (as far as i can tell) | 22:19 |
| ayoung | morganfainberg, need to get kids...just realized the time...back in a few hours. | 22:20 |
| *** derek_c has joined #openstack-keystone | 22:30 | |
| *** derek_c has quit IRC | 22:33 | |
| morganfainberg | dolphm, https://review.openstack.org/#/c/72582/ rebased | 22:41 |
| *** leseb has joined #openstack-keystone | 22:43 | |
| *** david-lyle has quit IRC | 22:46 | |
| *** leseb has quit IRC | 22:47 | |
| *** stevemar has quit IRC | 22:50 | |
| lbragstad | morganfainberg: thanks! | 22:51 |
| morganfainberg | lbragstad, :) | 22:51 |
| *** finite has quit IRC | 22:51 | |
| morganfainberg | lbragstad, was a very quick rebase | 22:51 |
| lbragstad | ++ those are the good kinda | 22:51 |
| lbragstad | rebases | 22:51 |
| *** gordc has quit IRC | 23:00 | |
| *** openstack has joined #openstack-keystone | 23:03 | |
| topol | stevemar, fee; free to thank gyee for brow beating a +1 out of me :-) | 23:08 |
| gyee | topol, I am non-violence :) | 23:09 |
| topol | gyee, you have your ways... :-) | 23:10 |
| *** jamielennox|away is now known as jamielennox | 23:17 | |
| bknudson | jamielennox: you're going to have to start being up at night to keep the openstack-sdk going in the right direction. | 23:18 |
| jamielennox | bknudson: ergh, yea | 23:18 |
| jamielennox | i come back some days and can't believe everything i missed | 23:18 |
| jamielennox | i used to go back through irc logs when i came online, but it just takes too long | 23:19 |
| morganfainberg | jamielennox, https://review.openstack.org/#/c/78448 | 23:19 |
| morganfainberg | jamielennox, that bug (post merge) still seems to be hitting us. | 23:19 |
| morganfainberg | jamielennox, gate haas already seen one. | 23:19 |
| jamielennox | morganfainberg: which bug are we talking? | 23:19 |
| morganfainberg | jamielennox, so i thnk we need to get better logging so we know what is going on | 23:20 |
| jamielennox | related-bug, right | 23:20 |
| morganfainberg | #1285833 | 23:20 |
| bknudson | so it wasn't the non-atomic write? | 23:20 |
| morganfainberg | i am open to better phrasing on the log | 23:20 |
| morganfainberg | bknudson, it probably was sometimes a non-atomic write | 23:20 |
| bknudson | overwrite | 23:20 |
| morganfainberg | but we have no idea what the openssl error output is | 23:20 |
| morganfainberg | we never capture / send that | 23:20 |
| bknudson | I assume they're actually using the new code? | 23:20 |
| bknudson | do they need a release? | 23:21 |
| morganfainberg | bknudson, yeah gate failed ~3hrs post merge | 23:21 |
| morganfainberg | nope | 23:21 |
| morganfainberg | gate uses trunk clients for integration test | 23:21 |
| jamielennox | morganfainberg: i thought we logged that somewhere already | 23:21 |
| morganfainberg | nope | 23:21 |
| bknudson | don't show dstanek he'll go ballistic with your use of % in a log. | 23:21 |
| jamielennox | oh, that's in the calledproccess error | 23:21 |
| morganfainberg | http://logs.openstack.org/10/77710/3/gate/gate-grenade-dsvm/1b42df2/logs/new/screen-c-api.txt.gz?level=TRACE | 23:21 |
| morganfainberg | bknudson LOL fair point let me fix that. | 23:22 |
| morganfainberg | jamielennox, yeah we drop it silently on the floor | 23:22 |
| morganfainberg | not sure i want to include it in the exception | 23:22 |
| morganfainberg | but it def needs to be logged. | 23:22 |
| dstanek | bknudson: :P | 23:22 |
| morganfainberg | updated to not use % in log | 23:23 |
| dstanek | morganfainberg: that's one of the checks i'm working on! | 23:23 |
| morganfainberg | dstanek, +++++ | 23:23 |
| jamielennox | morganfainberg: yea, we should probably be attaching all these log messages to the exceptions and then doing consistent error messages higher up | 23:23 |
| jamielennox | morganfainberg: but that's so far down on the list of auth_token failures | 23:23 |
| morganfainberg | jamielennox, yep | 23:23 |
| morganfainberg | jamielennox, so if you want something else in there i can change it up, but i am fine with just logging for now | 23:24 |
| morganfainberg | jamielennox, i just have no way to know what is going on when infra asks "so why is this still broken" | 23:24 |
| jamielennox | morganfainberg: dumb question, but does it work? | 23:24 |
| morganfainberg | jamielennox, we use .output to look for the filename in "cert_file_missing" | 23:25 |
| morganfainberg | return (file_name in proc_output and not os.path.exists(file_name)) | 23:25 |
| bknudson | morganfainberg: did you consider trying the cms_verify again? | 23:25 |
| morganfainberg | bknudson, this is 3rd attempt at cms_verify | 23:25 |
| gyee | morganfainberg, jamielennox, is openstacksdk going to replace all the python-*client out there? | 23:25 |
| morganfainberg | bknudson, well, possibly 3rd | 23:25 |
| bknudson | y, but it's probably the first. | 23:26 |
| morganfainberg | bknudson, if cert file is missing, fetch cert, try again, ca .. same, then still fail, raise opaque error | 23:26 |
| jamielennox | gyee: i think they want to | 23:26 |
| gyee | jamielennox, who's they? | 23:26 |
| morganfainberg | bknudson, do we really want to say "failed 1 time, try again" in auth_token? | 23:26 |
| gyee | I am all for it btw | 23:26 |
| morganfainberg | bknudson, not opposed, not sure if that is a valid thing to do each time | 23:27 |
| jamielennox | gyee: sdk people - i'm of the opinion they are biting off more than they can chew | 23:27 |
| jamielennox | gyee: am keen to help, but i think they are tackling a big problem | 23:27 |
| bknudson | jamielennox: I agree that this is a monster project they're taking on. | 23:27 |
| morganfainberg | bknudson, i'm more inclined to log and see what the heck is happening before we add more retry logic | 23:27 |
| jamielennox | morganfainberg: ++ | 23:27 |
| bknudson | jamielennox: gyee: they'll be lucky to be able to keep momentum | 23:27 |
| jamielennox | it's a fairly rare problem and i don't know why it's happening | 23:27 |
| morganfainberg | jamielennox, exactly | 23:28 |
| jamielennox | bknudson: they have a few big drivers behind it | 23:28 |
| bknudson | morganfainberg: I'm afraid that the output is going to be "error 1" or whatever that won't tell us anything. | 23:28 |
| jamielennox | bknudson: but they face the same problem that OSC does and i don't think people will continue to update 2 sets of clients for every API they add | 23:28 |
| morganfainberg | bknudson, eh at least we have an actual OpenSSL error to go for then. it's a starting place | 23:28 |
| morganfainberg | bknudson, alternatives would be welcome | 23:29 |
| morganfainberg | bknudson, but i don't think retry logic will buy us much here. | 23:29 |
| gyee | bknudson, I do think a common client is beneficial, key is to have the right abstraction | 23:29 |
| jamielennox | morganfainberg, bknudson: yes, there is a problem that the only place where certificateConficError is raised is on status_code != 200 | 23:29 |
| jamielennox | gyee: i agree too, they have good goals | 23:29 |
| gyee | stuff that jamielennox did can easily be in the framework, especially session management | 23:30 |
| bknudson | gyee: I'm not convinced that we'll be able to get rid of the existing client libs... they're going for a "user" SDK... does that cover the "admin" SDK that we also need? | 23:30 |
| morganfainberg | bknudson, it would be nice if it did | 23:30 |
| morganfainberg | bknudson, doubtful | 23:30 |
| bknudson | gyee: I've been trying to convince them to look at jamielennox's code. | 23:30 |
| jamielennox | bknudson: i still like the approach that the SDK relies on all the individual clients | 23:30 |
| jamielennox | bknudson: if that means fixing the individual clients then that's great! | 23:30 |
| bknudson | jamielennox: yes, that seems like a good goal, especially if you're not going to get rid of the existing clients anyways. | 23:31 |
| jamielennox | i was disappointed by yesterday's meeting, nothing seemed to get resolved - and the vendor extensions topic is so far down the list that it should not be a concern yet | 23:31 |
| gyee | not sure about that, one of its goal should be to reduce package dependency nightmare | 23:31 |
| bknudson | jamielennox: lol -- yes, they seem to be off in the weeds already. | 23:31 |
| gyee | you want 1 client package, or n client package | 23:32 |
| jamielennox | gyee: they have core python community members on that team, if they want to fix the package dep nightmare i would like to see them do it in pip | 23:32 |
| bknudson | gyee: seems like we could do that without rewriting the client. | 23:32 |
| gyee | bknudson, how? | 23:33 |
| jamielennox | gyee: i'm still not convinced that the metapackage is a problem, on the other hand my solution to the windows problem is - people use that? | 23:33 |
| bknudson | just make one project with all the existing clients. | 23:33 |
| jamielennox | bknudson: ++ | 23:34 |
| morganfainberg | bknudson, python-openstack | 23:34 |
| gyee | bknudson, isn't that he purpose of openstacksdk? one project with all the clients | 23:34 |
| morganfainberg | or openstacksdk | 23:34 |
| gyee | the rest are just framework stuff | 23:34 |
| bknudson | gyee: no, it's to write a "user" SDK | 23:34 |
| gyee | like using session for session management | 23:34 |
| gyee | wtf's "user" sdk? | 23:35 |
| gyee | is there even a distinction? | 23:35 |
| gyee | sdk is api calls, users is the context | 23:35 |
| jamielennox | bknudson: reading over last nights sdk log - it's... painful | 23:36 |
| morganfainberg | bknudson, i wonder if it would be possible to convince the projects that python-*client should be moved out of the "programs" and into it's own program. client code, in theory, should be roughly all the same, and could be held to the same standards / core for one could in theory be core for others. | 23:36 |
| jamielennox | bknudson: i've done half of that | 23:36 |
| bknudson | gyee: dolphm was asking about the "user" vs other SDK. | 23:36 |
| jamielennox | bknudson: standardize discover across service - check | 23:36 |
| *** henrynash has quit IRC | 23:36 | |
| bknudson | gyee: was asking about it in the openstacksdk meeting (it's right after keystone meeting) | 23:36 |
| morganfainberg | bknudson, i don't think it would fly, but it might make consistent client code much much better / easier | 23:37 |
| morganfainberg | jamielennox, ^ | 23:37 |
| bknudson | morganfainberg: I agree about making the clients more consistent would need a core team. | 23:37 |
| gyee | morganfainberg, that's all there is | 23:37 |
| gyee | a framework | 23:37 |
| morganfainberg | gyee, i mean seriously make openstack client libraries a core team | 23:38 |
| morganfainberg | gyee, and the "programs" move their clients over to that new team | 23:38 |
| gyee | morganfainberg, no argument here | 23:38 |
| morganfainberg | so keystoneclient would become openstack.identity | 23:39 |
| jamielennox | gyee: i've been fighting this one | 23:39 |
| morganfainberg | novaclient would be openstack.compute | 23:39 |
| morganfainberg | etc | 23:39 |
| jamielennox | morganfainberg: i even mentioned that on the ML in that huge thread | 23:39 |
| gyee | ++ | 23:39 |
| morganfainberg | it would be a beast to get going but i think it would solve a lot | 23:39 |
| dstanek | morganfainberg: is my comment here correct? https://review.openstack.org/#/c/77325/ | 23:39 |
| dstanek | i probably should have asked before posting | 23:39 |
| morganfainberg | dstanek, hmmm | 23:39 |
| morganfainberg | dstanek, you might be right | 23:39 |
| morganfainberg | let me 2xcheck | 23:40 |
| bknudson | gyee: I'd point you to the meeting logs for info about "user" sdk vs admin sdk, but I can't find them. | 23:40 |
| morganfainberg | actually... that might be a flaw in the current truncate code too | 23:40 |
| morganfainberg | brb | 23:40 |
| dstanek | morganfainberg: origpasswd vs. passwd? yeah, that would be all fail | 23:41 |
| *** thedodd has quit IRC | 23:44 | |
| dolphm | dstanek: your comment is correct afaik | 23:49 |
| dolphm | dstanek: you'd get a 400 on auth | 23:49 |
| jamielennox | gyee, maybe ayoung can you have a look at: https://review.openstack.org/#/c/78224/1/keystoneclient/auth/identity/v3.py | 23:50 |
| jamielennox | that doesn't seem right to me | 23:50 |
| jamielennox | if we use a trust then it _replaces_ the scope rather than add to it | 23:51 |
| jamielennox | can you not scope to a trust and a domain? | 23:51 |
| dolphm | jamielennox: no, but that's because you can't delegate domain-level authorization | 23:52 |
| jamielennox | dolphm: ok, but a project then? | 23:52 |
| dolphm | jamielennox: i *believe* so | 23:52 |
| jamielennox | or are you expected to get the trust and find the info from that/ | 23:52 |
| jamielennox | it would seem to definently be a regression: https://github.com/openstack/python-keystoneclient/blob/0.6.0/keystoneclient/v3/client.py#L237 | 23:53 |
| dolphm | jamielennox: oh this is building a request... | 23:53 |
| dolphm | jamielennox: if you specify a trust, then scope is determined implicitly based on what was delegated in the trust | 23:54 |
| gyee | jamielennox, the fix seem correct | 23:54 |
| jamielennox | dolphm: hmm, right i guess that makes sense | 23:54 |
| jamielennox | ok | 23:54 |
| *** dims has quit IRC | 23:56 | |
| gyee | there should be a check on the server side to make sure we don't scope to more than one thing at a time | 23:56 |
| jamielennox | gyee: i think there is and that's what was failing | 23:56 |
| jamielennox | the client was building a request for multiple scopes | 23:57 |
| dolphm | jamielennox: commented -- the problem is one of user expectations ... i'm not sure the proposed fix is any sort of improvement | 23:57 |
| gyee | jamielennox, perhaps the client should emit some warning as well | 23:57 |
| dolphm | jamielennox: it's just silently ignoring broken expectations | 23:57 |
| *** topol has quit IRC | 23:57 | |
| dolphm | (after the change) | 23:57 |
| jamielennox | dolphm: indeed - but it is a regression that someone relies upon, so not much choice there | 23:58 |
| dolphm | jamielennox: before the change, it sounds like the server was balking at broken user expectations | 23:58 |
| gyee | dolphm, its a smart client, it's trying to read into what user wants :) | 23:58 |
| jamielennox | no, looking at https://github.com/openstack/python-keystoneclient/blob/0.6.0/keystoneclient/v3/client.py#L237 it was a pure replace silently | 23:59 |
| dolphm | jamielennox: bah... i missed the link to 0.6.0 | 23:59 |
| dolphm | gyee: no, that's just a bug | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!