| *** rkrum has joined #openstack-keystone | 00:00 | |
| *** ddieterly has quit IRC | 00:02 | |
| *** code-R has joined #openstack-keystone | 00:14 | |
| *** code-R_ has joined #openstack-keystone | 00:15 | |
| *** code-R has quit IRC | 00:19 | |
| *** markvoelker has joined #openstack-keystone | 00:59 | |
| *** ddieterly has joined #openstack-keystone | 01:02 | |
| *** markvoelker has quit IRC | 01:04 | |
| *** code-R_ has quit IRC | 01:07 | |
| *** code-R has joined #openstack-keystone | 01:07 | |
| *** atod has quit IRC | 01:26 | |
| *** atod has joined #openstack-keystone | 01:27 | |
| atod | Hi. Is anyone playing with Identity V3 and domains in Keystone? | 01:30 |
|---|---|---|
| *** EinstCrazy has joined #openstack-keystone | 01:34 | |
| *** EinstCrazy has quit IRC | 01:34 | |
| *** EinstCrazy has joined #openstack-keystone | 01:34 | |
| *** ddieterly has quit IRC | 01:35 | |
| *** davechen has joined #openstack-keystone | 01:35 | |
| *** atod has quit IRC | 01:35 | |
| *** ddieterly has joined #openstack-keystone | 01:36 | |
| *** atod has joined #openstack-keystone | 01:40 | |
| *** ddieterly is now known as ddieterly[away] | 02:01 | |
| *** ddieterly[away] is now known as ddieterly | 02:03 | |
| *** EinstCra_ has joined #openstack-keystone | 02:06 | |
| *** EinstCrazy has quit IRC | 02:09 | |
| *** EinstCrazy has joined #openstack-keystone | 02:13 | |
| *** ddieterly has quit IRC | 02:13 | |
| *** EinstCra_ has quit IRC | 02:17 | |
| *** nkinder has quit IRC | 02:23 | |
| *** su_zhang has joined #openstack-keystone | 02:25 | |
| *** atod has quit IRC | 02:27 | |
| *** GB21 has joined #openstack-keystone | 02:39 | |
| *** GB21 has quit IRC | 02:47 | |
| openstackgerrit | Merged openstack/keystone: Add create and update methods to credential Manager https://review.openstack.org/355056 | 03:00 |
| *** tqtran has joined #openstack-keystone | 03:02 | |
| *** tqtran has quit IRC | 03:06 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/356872 | 03:08 |
| stevemar | dolphm: i updated the meeting with stuff and things, let me know if you have any questions | 03:14 |
| *** su_zhang has quit IRC | 03:14 | |
| *** su_zhang has joined #openstack-keystone | 03:15 | |
| *** su_zhang has quit IRC | 03:19 | |
| *** chrichip has quit IRC | 03:23 | |
| *** chrichip has joined #openstack-keystone | 03:23 | |
| *** julim has quit IRC | 03:27 | |
| stevemar | henrynash: ayoung can you look at https://review.openstack.org/#/c/351264/4 for a minute, since y'all know about domain specific vs implied roles | 03:29 |
| ayoung | stevemar, really? Midnight on Sunday? Oh, wait, newborn...nevermind | 03:29 |
| stevemar | ayoung: haha, that was meant for you to read on monday morning! | 03:29 |
| ayoung | stevemar, is that really something we want to forbid? | 03:29 |
| stevemar | i think a DSR from domain A should not imply a DSR from domain B | 03:30 |
| openstackgerrit | Dave Chen proposed openstack/keystone: Update `href` for keystone extensions https://review.openstack.org/358381 | 03:30 |
| ayoung | stevemar, I'm actually headed to Cape Cod for the week...I'll be working from there, but driving the family down in the morning. Was just shutting down | 03:30 |
| stevemar | ayoung: oh go go go | 03:31 |
| stevemar | ayoung: have fun man | 03:31 |
| ayoung | stevemar, no problem, just finishing up | 03:31 |
| ayoung | I don;'t know if I think that is a real thing to avoid. | 03:31 |
| ayoung | I could see DSRs from one domain pointing at another being a useful thing, but confusing. | 03:31 |
| ayoung | Why? Is this just being over cautious? | 03:32 |
| stevemar | ayoung: i believe so, gyee filed the bug | 03:33 |
| ayoung | stevemar, meh | 03:33 |
| stevemar | it feels funny, but overcautious yes | 03:33 |
| ayoung | What did Henry say? | 03:33 |
| stevemar | hasn't seen it yet | 03:34 |
| *** atod has joined #openstack-keystone | 03:36 | |
| ayoung | stevemar, I did write up a spec you might find interesting | 03:40 |
| *** atod has quit IRC | 03:40 | |
| ayoung | https://review.openstack.org/#/c/358131/ | 03:41 |
| *** ayoung has quit IRC | 03:43 | |
| *** mdurrant_ has joined #openstack-keystone | 03:44 | |
| *** chrisshattuck has joined #openstack-keystone | 03:45 | |
| *** mdurrant__ has quit IRC | 03:47 | |
| davechen | stevemar: have replied to your comments, and a question for you, do you know why 'trust' and 'endpoint policy' haven't register the extension data? | 03:47 |
| stevemar | davechen: cause we stink at consistency :) | 03:48 |
| stevemar | davechen: +2'ed it | 03:48 |
| davechen | stevemar: I feel the api to show the info for the extension will miss them | 03:48 |
| davechen | stevemar: will dig into it, if this is true will try to fix it. | 03:49 |
| davechen | stevemar: thanks! | 03:49 |
| stevemar | awesome! | 03:49 |
| *** chrisshattuck has quit IRC | 03:59 | |
| *** code-R has quit IRC | 04:00 | |
| *** chrisshattuck has joined #openstack-keystone | 04:00 | |
| *** chrisshattuck has quit IRC | 04:04 | |
| *** code-R has joined #openstack-keystone | 04:10 | |
| *** su_zhang has joined #openstack-keystone | 04:14 | |
| *** michauds has joined #openstack-keystone | 04:34 | |
| *** david-lyle has quit IRC | 04:37 | |
| *** pcaruana has quit IRC | 04:55 | |
| *** jamielennox is now known as jamielennox|away | 05:18 | |
| *** aswadr_ has joined #openstack-keystone | 05:22 | |
| *** jaosorior has joined #openstack-keystone | 05:23 | |
| *** links has joined #openstack-keystone | 05:38 | |
| *** links has quit IRC | 05:38 | |
| *** richm has quit IRC | 05:40 | |
| *** Gorian has quit IRC | 05:45 | |
| *** sigmavirus has quit IRC | 05:46 | |
| *** d34dh0r53 has quit IRC | 05:46 | |
| *** eglute has quit IRC | 05:46 | |
| *** eglute has joined #openstack-keystone | 05:47 | |
| *** d34dh0r53 has joined #openstack-keystone | 05:48 | |
| *** d34dh0r53 has quit IRC | 05:48 | |
| *** eglute has quit IRC | 05:48 | |
| *** eglute has joined #openstack-keystone | 05:49 | |
| *** eglute has quit IRC | 05:49 | |
| *** eglute has joined #openstack-keystone | 05:50 | |
| *** d34dh0r53 has joined #openstack-keystone | 05:51 | |
| *** eglute has quit IRC | 05:51 | |
| *** d34dh0r53 has quit IRC | 05:51 | |
| *** Gorian has joined #openstack-keystone | 05:53 | |
| *** eglute has joined #openstack-keystone | 05:54 | |
| *** eglute has quit IRC | 05:54 | |
| *** dikonoor has joined #openstack-keystone | 06:02 | |
| *** eglute has joined #openstack-keystone | 06:05 | |
| *** d34dh0r53 has joined #openstack-keystone | 06:06 | |
| *** michauds has quit IRC | 06:15 | |
| *** EinstCrazy has quit IRC | 06:23 | |
| *** EinstCrazy has joined #openstack-keystone | 06:24 | |
| *** rcernin has joined #openstack-keystone | 06:51 | |
| *** pcaruana has joined #openstack-keystone | 06:52 | |
| *** tesseract- has joined #openstack-keystone | 07:09 | |
| *** atod has joined #openstack-keystone | 07:15 | |
| *** atod has quit IRC | 07:16 | |
| *** atod has joined #openstack-keystone | 07:19 | |
| *** mkoderer__ has quit IRC | 07:19 | |
| *** rcernin has quit IRC | 07:25 | |
| *** su_zhang has quit IRC | 07:29 | |
| *** su_zhang has joined #openstack-keystone | 07:30 | |
| *** code-R has quit IRC | 07:31 | |
| *** code-R has joined #openstack-keystone | 07:32 | |
| *** rkrum has quit IRC | 07:34 | |
| *** su_zhang has quit IRC | 07:34 | |
| *** code-R has quit IRC | 07:37 | |
| *** su_zhang has joined #openstack-keystone | 07:40 | |
| *** itisha has joined #openstack-keystone | 07:43 | |
| *** su_zhang has quit IRC | 07:45 | |
| *** su_zhang has joined #openstack-keystone | 07:46 | |
| *** su_zhang has quit IRC | 07:50 | |
| *** atod has quit IRC | 07:54 | |
| *** atod has joined #openstack-keystone | 07:54 | |
| *** zzzeek has quit IRC | 08:00 | |
| *** zzzeek has joined #openstack-keystone | 08:01 | |
| *** asettle has joined #openstack-keystone | 08:05 | |
| *** markvoelker has joined #openstack-keystone | 08:05 | |
| *** markvoelker has quit IRC | 08:10 | |
| *** atod has quit IRC | 08:24 | |
| *** atod has joined #openstack-keystone | 08:24 | |
| *** asettle has quit IRC | 08:27 | |
| *** atod has quit IRC | 08:29 | |
| *** jaosorior has quit IRC | 08:30 | |
| *** atod has joined #openstack-keystone | 08:31 | |
| *** jaosorior has joined #openstack-keystone | 08:31 | |
| *** atod has quit IRC | 08:35 | |
| *** asettle has joined #openstack-keystone | 08:35 | |
| *** atod has joined #openstack-keystone | 08:45 | |
| *** atod has quit IRC | 08:47 | |
| *** atod has joined #openstack-keystone | 08:48 | |
| *** code-R has joined #openstack-keystone | 09:00 | |
| *** markvoelker has joined #openstack-keystone | 09:06 | |
| *** tqtran has joined #openstack-keystone | 09:06 | |
| *** markvoelker has quit IRC | 09:11 | |
| *** tqtran has quit IRC | 09:11 | |
| *** sheel has joined #openstack-keystone | 09:22 | |
| *** atod has quit IRC | 09:24 | |
| breton | morning | 09:29 |
| openstackgerrit | Kseniya Tychkova proposed openstack/oslo.policy: Apache Fortress support prototype https://review.openstack.org/237521 | 09:40 |
| *** amakarov_away is now known as amakarov | 09:52 | |
| *** rkrum has joined #openstack-keystone | 09:58 | |
| *** rkrum has quit IRC | 10:02 | |
| *** markvoelker has joined #openstack-keystone | 10:07 | |
| *** richm has joined #openstack-keystone | 10:07 | |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/keystone: [WIP] Testing latest u-c https://review.openstack.org/318435 | 10:10 |
| openstackgerrit | Davanum Srinivas (dims) proposed openstack/keystone: [WIP] Testing latest u-c https://review.openstack.org/318435 | 10:10 |
| *** markvoelker has quit IRC | 10:12 | |
| *** david_cu has quit IRC | 10:13 | |
| samueldmq | morning keystone | 10:41 |
| *** dikonoor has quit IRC | 10:52 | |
| *** EinstCrazy has quit IRC | 10:53 | |
| *** GB21 has joined #openstack-keystone | 11:02 | |
| *** openstackgerrit has quit IRC | 11:03 | |
| *** openstackgerrit has joined #openstack-keystone | 11:03 | |
| *** davechen has left #openstack-keystone | 11:05 | |
| *** markvoelker has joined #openstack-keystone | 11:08 | |
| *** tqtran has joined #openstack-keystone | 11:08 | |
| *** rodrigods has quit IRC | 11:11 | |
| *** rodrigods has joined #openstack-keystone | 11:11 | |
| *** markvoelker has quit IRC | 11:12 | |
| *** tqtran has quit IRC | 11:13 | |
| *** agireud has quit IRC | 11:16 | |
| *** gagehugo has quit IRC | 11:17 | |
| *** dhellmann has quit IRC | 11:17 | |
| *** dhellmann has joined #openstack-keystone | 11:17 | |
| *** nk2527 has joined #openstack-keystone | 11:18 | |
| *** agireud has joined #openstack-keystone | 11:20 | |
| *** maestropandy has joined #openstack-keystone | 11:28 | |
| *** nishaYadav has joined #openstack-keystone | 11:33 | |
| nishaYadav | o/ | 11:34 |
| *** openstackstatus has quit IRC | 11:36 | |
| *** openstackstatus has joined #openstack-keystone | 11:38 | |
| *** ChanServ sets mode: +v openstackstatus | 11:38 | |
| *** woodster_ has joined #openstack-keystone | 11:42 | |
| *** asettle has quit IRC | 11:46 | |
| *** dikonoor has joined #openstack-keystone | 11:46 | |
| *** jaosorior has quit IRC | 11:50 | |
| *** jaosorior has joined #openstack-keystone | 11:50 | |
| *** jpena is now known as jpena|lunch | 11:51 | |
| *** _sigmavirus24 has joined #openstack-keystone | 11:52 | |
| *** maestropandy has left #openstack-keystone | 11:53 | |
| *** _sigmavirus24 is now known as sigmavirus | 11:54 | |
| *** sigmavirus has joined #openstack-keystone | 11:54 | |
| stevemar | morning samueldmq | 11:56 |
| samueldmq | nishaYadav: stevemar: o/ | 11:57 |
| *** asettle has joined #openstack-keystone | 11:57 | |
| *** maestropandy1 has joined #openstack-keystone | 12:03 | |
| *** maestropandy1 has left #openstack-keystone | 12:04 | |
| *** alex_xu has quit IRC | 12:08 | |
| rodrigods | rderose, can you check my replies at https://review.openstack.org/#/c/357950/5 ? | 12:08 |
| *** markvoelker has joined #openstack-keystone | 12:09 | |
| *** alex_xu has joined #openstack-keystone | 12:09 | |
| *** markvoelker has quit IRC | 12:13 | |
| *** asettle has quit IRC | 12:19 | |
| *** markvoelker has joined #openstack-keystone | 12:20 | |
| *** nishaYadav has quit IRC | 12:21 | |
| *** nishaYadav has joined #openstack-keystone | 12:21 | |
| *** dstanek_ has quit IRC | 12:25 | |
| *** dstanek has joined #openstack-keystone | 12:26 | |
| *** ChanServ sets mode: +v dstanek | 12:26 | |
| *** jaosorior is now known as jaosorior_brb | 12:26 | |
| *** dstanek has quit IRC | 12:27 | |
| *** dstanek has joined #openstack-keystone | 12:27 | |
| *** ChanServ sets mode: +v dstanek | 12:27 | |
| *** asettle has joined #openstack-keystone | 12:29 | |
| dstanek | good morning all | 12:30 |
| *** edmondsw has joined #openstack-keystone | 12:30 | |
| *** dstanek has quit IRC | 12:33 | |
| henrynash | dstaneK; morning...quick pythony question for you....is there any way a function that you monkeypatch in to replace an existing function can know the name of the function it has replaced? (I doubt it, somehow) | 12:33 |
| *** dstanek has joined #openstack-keystone | 12:33 | |
| *** ChanServ sets mode: +v dstanek | 12:33 | |
| *** GB21 has quit IRC | 12:43 | |
| openstackgerrit | Steve Martinelli proposed openstack/keystoneauth: Disables TCP_KEEPCNT when using Windows Subsystem for Linux https://review.openstack.org/357452 | 12:46 |
| stevemar | jamielennox|away: if you're still around: https://review.openstack.org/#/c/357452/6 | 12:47 |
| openstackgerrit | Steve Martinelli proposed openstack/keystoneauth: Allow specifying client and service info to user_agent https://review.openstack.org/357633 | 12:49 |
| *** Marcellin_ has joined #openstack-keystone | 12:56 | |
| *** raildo has joined #openstack-keystone | 12:57 | |
| *** clenimar has joined #openstack-keystone | 12:58 | |
| *** mgagne_ has quit IRC | 13:00 | |
| *** mgagne_ has joined #openstack-keystone | 13:00 | |
| *** jpena|lunch is now known as jpena | 13:06 | |
| *** edmondsw has quit IRC | 13:09 | |
| *** ddieterly has joined #openstack-keystone | 13:10 | |
| *** ddieterly has quit IRC | 13:14 | |
| *** julim has joined #openstack-keystone | 13:18 | |
| *** Guest37793 is now known as zeus | 13:24 | |
| *** zeus has joined #openstack-keystone | 13:24 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Add key repository uniqueness check to doctor https://review.openstack.org/358083 | 13:29 |
| dikonoor | dstanek:dolphm: Hi | 13:30 |
| dikonoor | dstanek:dolphm: I am running into an error like this and I think this is a bug..but I am not sure..LEt me explain the usecase >> Conflict occurred attempting to store nonlocal_user - Duplicate Entry (HTTP 409) | 13:31 |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystoneauth: Disables TCP_KEEPCNT when using Windows Subsystem for Linux https://review.openstack.org/357452 | 13:32 |
| samueldmq | stevemar: ^ | 13:32 |
| dikonoor | dstanek:dolphm: This is in the context of shadow users. I tried with LDAP user.. | 13:32 |
| samueldmq | stevemar: let me know if it's good enough | 13:32 |
| dikonoor | dstanek:dolphm:rderose: Use case is : I have two ldaps - LDAP1 and LDAP2. Both of them have a specific user with the same name ..Let's call the user ABC. I now configure keystone with LDAP1 and then when the user is authenticated, there's an entry created in the nonlocal_user table with primary_key combination as domain and username ABC | 13:34 |
| *** melwitt_ is now known as melwitt | 13:34 | |
| dikonoor | dstanek:dolphm:rderose: I now reconfigure the same instance of keystone with LDAP2, which also has a user with the same name.. SO, now when I try to authenticate user ABC (from LDAP2), it gives me a conflicting user error because the nonlocal_user table already has en entry with the same domain+username combination | 13:35 |
| dikonoor | dstanek: dolphm: rderose: So, even though my user ABC from LDAP2 is actually a valid user, the authentication fails | 13:36 |
| dstanek | dikonoor: this is likely caused by the bug that is accidentally creating local_users | 13:36 |
| dstanek | i'm guessing that once the fix gets in it will work | 13:36 |
| dikonoor | dstanek: dolphm: rderose: But this conflict occurs in the nonlocal_user table | 13:37 |
| dstanek | dikonoor: ah, then another bug? | 13:37 |
| dikonoor | dstanek:dolphm:rderose: and even if with the fix to not insert in local_user, this will happen | 13:37 |
| dstanek | dikonoor: are you trying to use the same domain for both ldaps? | 13:37 |
| dikonoor | dstanek: yes..same domain | 13:37 |
| dstanek | i don't think that can work | 13:37 |
| dikonoor | dstanek : which is a supported usecase.. | 13:38 |
| dstanek | dikonoor: is it supported? | 13:38 |
| dikonoor | dstanek: I don't see any reason it shouldn't be..If I were a customer and my LDAP1 crashed for some reason and I want to switch to my backup LDAP2, I would want to use the same domain | 13:38 |
| dikonoor | dstanek: So, I think this would be a bug.. This can be reproduced in other ways as well even with the use of a single LDAP | 13:40 |
| dstanek | dikonoor: how can it be done with a single LDAP server? | 13:40 |
| dstanek | dikonoor: i don't think having 2 different LDAP servers under a single domain is possible because of name collision issues (which is what you are seeing) | 13:41 |
| dikonoor | dstanek: for eg. Let's say I have just one LDAP and I configure keystone to user it such that the user-id-mapping is set to cn (for eg. cn=abc@abc.com)..now I authenticate..everything works fine | 13:41 |
| dstanek | i could be wrong, but i wouldn't actually expect it to work | 13:41 |
| dikonoor | dstanek: now let me reconfigure keystone with the same LDAP such that user-id-mapping is set to uid (for eg. uid=3764836)..When keystone is restarted after this configuration, a new entry gets created in the id_mapping table and then when you try to authenticate , it will cause the same conflict user error at the nonlocal_user.. | 13:43 |
| dikonoor | dstanek: This is caused because in both the cases the user name attribute used for configuration is the same ..and after the first configuration when the user authenticates, an entry is made in the nonlocal_user table with domain+user_name combination | 13:44 |
| dstanek | dikonoor: i'm not sure if reconfiguring like that is a bug or not, but i suggest you file it and see what others think | 13:45 |
| dikonoor | dstanek: ok..Let me file a bug..but the first scenario of two different LDAPs and same user/domain would be a valid usecase in my opinion.. I will file a bug..Wanted to know what rderose and dolphm thought as well | 13:46 |
| dikonoor | dstanek: The other query I have would be around deletions in the keystone db for these users | 13:46 |
| *** sdake has joined #openstack-keystone | 13:46 | |
| dstanek | dikonoor: if your usecase for the first once is redundancy on the ldap server i think there are better ways to do that | 13:47 |
| *** bigdogstl has joined #openstack-keystone | 13:48 | |
| lbragstad | henrynash quick question on the database migration repos. Did we ever determine a location for tests that span the entire upgrade? | 13:50 |
| *** sdake_ has joined #openstack-keystone | 13:50 | |
| dikonoor | dstanek: well..there might be other ways..but I don't think it would be right to give a conflict user error in the usecases I explained..but let's see..I will open a bug..I am not sure if these db entries are ever cleaned up..so there could be other usecases where we could hit this error | 13:50 |
| dikonoor | dstanek: The other query I have is around the "last_active_at" column in the user table | 13:51 |
| *** briancurtin has quit IRC | 13:51 | |
| samueldmq | stevemar: dstanek: do we really need to have kerberos as mandatory extra dps for our testing env ? | 13:51 |
| samueldmq | https://github.com/openstack/keystoneauth/blob/master/tox.ini#L15 | 13:51 |
| dstanek | i don't think they are cleaned up at all - the idea (i believe) is that the information from LDAP should be unique enough to create a user | 13:51 |
| *** tonytan4ever has joined #openstack-keystone | 13:51 | |
| samueldmq | stevemar: I had to "sudo apt-get install libkrb5-dev" just to be able to tox -e venv -- reno new bug-1614688 | 13:52 |
| samueldmq | :/ | 13:52 |
| *** briancurtin has joined #openstack-keystone | 13:52 | |
| dikonoor | dstanek : but when we switch between LDAPs , wouldn't it make sense to clean it up ? OR perhaps clean it up if the "last_active_at" column shows that the user hasn't been active for ages ? | 13:52 |
| dstanek | samueldmq: hmmm, we could probably make those tests skipped is kerberos isn't installed, but i'd rather not | 13:53 |
| *** bigdogstl has quit IRC | 13:53 | |
| dikonoor | but "last_active_at" column, I see always has a value of NULL..Not sure if this is intentional ? | 13:53 |
| dikonoor | or a bug | 13:53 |
| *** sdake has quit IRC | 13:53 | |
| dstanek | dikonoor: maybe? but that may lead to having to clean up lots of stuff. you may have things in the cloud pointing to users that don't exist | 13:54 |
| dikonoor | dstanek: that's true..i mean what you say references of non-existent users ..would be a problem with the auditing support as well | 13:54 |
| rderose | rodrigods: so what's the purpose of the controller in your opinion? | 13:55 |
| dstanek | there's rderose! | 13:55 |
| samueldmq | dstanek: well, I am not complaining about the tests ... jsut about needing to install that for running reno | 13:56 |
| samueldmq | dstanek: :( | 13:56 |
| henrynash | lbragstad: good question, not sure we have a class for that...although the contract test class in test_sql_upgrade forces all the migrations phases before it runs....so that is one options | 13:56 |
| rderose | dstanek: good morning :) | 13:56 |
| dikonoor | dstanek : but in a huge cloud deployment with LDAP servers carrying lakhs of users , where users are authenticating in and out, it would be an overkill not to delete any entries | 13:56 |
| dikonoor | rderose: Good Morning :D | 13:56 |
| lbragstad | henrynash hmm | 13:57 |
| lbragstad | henrynash is there any way to control which repos run in the test? | 13:57 |
| rderose | dikonoor: good morning :) | 13:57 |
| dikonoor | rderose: dstanek and I were discussing about a specific usecase around LDAP conflicting user problem in nonlocal_user table | 13:58 |
| dstanek | samueldmq: stevemar: our dev docs no longer say what system packages need to be installed :-( | 13:58 |
| rderose | dikonoor: reading... | 13:58 |
| henrynash | lbragstad: so there is a test class for expand, migrate and contract (as well as the legacy), each one ensures any previous phases are run as part of its setup | 13:58 |
| stevemar | dstanek: indeed! | 13:58 |
| stevemar | dstanek: they say to use bindep | 13:58 |
| samueldmq | stevemar: ++ | 13:58 |
| stevemar | and "other-requrements.txt" | 13:58 |
| samueldmq | exactly, we need to add that to other repos too | 13:58 |
| samueldmq | looks like it's only in keystone server repo | 13:59 |
| dstanek | stevemar: where? | 13:59 |
| samueldmq | stevemar: now it's named 'bindep.txt' | 13:59 |
| dstanek | i'm looking st http://docs.openstack.org/developer/keystone/devref/development.environment.html | 13:59 |
| samueldmq | stevemar: dstanek : https://github.com/openstack/keystone/blob/master/bindep.txt | 13:59 |
| lbragstad | henrynash interesting - i'm trying to test https://review.openstack.org/#/c/355618/9 and I want to make sure you can't issue some sort of credential write during the upgrade (so, testing the triggers that make credentials read-only). | 13:59 |
| samueldmq | dstanek: in the Development environment section, it tells you to go to http://docs.openstack.org/project-team-guide/project-setup/python.html | 14:00 |
| *** spedione|AWAY is now known as spedione | 14:00 | |
| samueldmq | there it talks about bindep | 14:00 |
| stevemar | dstanek: "For setting up the Python development environment and running tox testing environments, please refer to the Project Team Guide: Python Project Guide, the OpenStack guide on wide standard practices around the use of Python."" | 14:00 |
| *** ddieterly has joined #openstack-keystone | 14:00 | |
| samueldmq | which is a common thing to all projects, so we didn't need to c&p the docs :) | 14:00 |
| stevemar | pip install bindep; sudo [apt-get | yum] install $(bindep -b) | 14:01 |
| dstanek | leave it to openstack to keep making things more and more complicated :-) | 14:01 |
| samueldmq | we had to maintain a different list of packages depending on distro, now it's just those commands ^ | 14:02 |
| dstanek | stevemar: do we support using multiple LDAP servers attached to the same domain? | 14:02 |
| dikonoor | rderose: 3 things 1) conflicting user problem 2) last_active_at NULL in User table (I see default_project_id also as NULL) 3) Deletion of stale entries | 14:03 |
| dstanek | dikonoor: at this point i doubt we would try to delete stale entries | 14:04 |
| stevemar | dstanek: i don't believe so | 14:04 |
| *** ddieterly is now known as ddieterly[away] | 14:04 | |
| rderose | dikonoor dstanek dolphm: 1) yeah, as dstanek was saying, I'm not sure we support multiple LDAP servers with the same domain. If we do, the obvious fix would be to remove the constraint. | 14:04 |
| rderose | dikonoor: what's your question regarding 2) last_active_at? | 14:05 |
| dikonoor | stevemar: do we support using multiple LDAP servers attached to the same domain such that only one LDAP is configured at a time ..if LDAP1 that was setup with domain1 was unavailable for some reason, using ldap2 with the same domain is not supported? | 14:06 |
| rderose | stevemar dstanek dikonoor: okay, then we probably can remove that constraint, as long as the user ID will be unique across the LDAP servers | 14:07 |
| stevemar | dikonoor: do ldap1 and ldap2 have the same data? | 14:07 |
| rderose | stevemar dstanek dikonoor: I'll have to looks at the id mapping logic and see | 14:07 |
| *** edmondsw has joined #openstack-keystone | 14:07 | |
| dikonoor | stevemar : both ldaps could have users with the same name | 14:07 |
| stevemar | dikonoor: if it's a failover ldap, sure... but if it's an entirely different set of users i dont think so | 14:08 |
| dikonoor | rderose: "last_active_at" - what exactly is it used for.. | 14:08 |
| *** ddieterly[away] is now known as ddieterly | 14:08 | |
| rderose | dikonoor: it's for new security compliance feature for disabling inactive users | 14:09 |
| *** lamt has quit IRC | 14:09 | |
| dikonoor | rderose : ok..makes sense..currently the values are NULL for all LDAP entries I have..Is it a bug? | 14:10 |
| rderose | dikonoor: no, this setting is only supported with SQL identities | 14:10 |
| dstanek | dikonoor: ah yes, that's for PCI compliance support | 14:11 |
| *** tqtran has joined #openstack-keystone | 14:11 | |
| *** haplo37__ has joined #openstack-keystone | 14:11 | |
| dikonoor | dstanek: ok..got it..Also the default_project_id column | 14:11 |
| dikonoor | rderose: what's that for..That's also seen as null | 14:12 |
| dikonoor | rderose: Is it also something specific to sql and PCI-DSS compliance | 14:12 |
| rderose | dikonoor: yes, but it's not for PCI, default_project_id has been there for a while for SQL identities | 14:14 |
| dikonoor | rderose: not sure if it's actually getting used.. (I didn't see any functional problems) but they are NULL | 14:14 |
| rderose | dikonoor: it wouldn't be used for LDAP identities | 14:15 |
| *** tqtran has quit IRC | 14:15 | |
| dikonoor | dstanek : rderose: stevemar: On the original problem of conflicting user , we can hit that problem even if a case we switch between keystone identity drivers (from ldap to custom and vice versa), where both the backends have users with the same name and both drivers were used in the same domain; the other case is the failover scenario of the two ldaps with same set of users and we switch over to the second | 14:17 |
| rderose | dikonoor: regarding 3) deletion of stale entries, we've discussed this, but currently we do not have a mechanism for deleting stale users | 14:17 |
| dstanek | i thought default_project_id was just a v2 thing. i'd have to double check how it's used though | 14:17 |
| *** sdake_ is now known as sdake | 14:18 | |
| dikonoor | rderose: yeah..we don't have a mechanism and dstanek also mentioned the problem around the non-existent user. | 14:19 |
| dstanek | dikonoor: i don't think we can easily support switching drivers in a domain | 14:19 |
| openstackgerrit | Merged openstack/keystoneauth: Allow identity plugins to discover relative version urls https://review.openstack.org/356808 | 14:19 |
| *** su_zhang has joined #openstack-keystone | 14:19 | |
| dstanek | dikonoor: i'm curious how the failover is failing since the public_ids and user name should be the same between the servers | 14:20 |
| rderose | dstanek dikonoor: yeah, if the user ID is the same across LDAP servers, than shouldn't fail | 14:22 |
| rodrigods | rderose, see.. i get your point, but for that specific check i'm not sure we want to implement it in the manager layer - we may even change the behavior in the future to make the type filed immutable just using JSON schema | 14:22 |
| dikonoor | dstanek: ok.but the userid is different but the user name is same , then it would | 14:23 |
| dstanek | dikonoor: in your example where both ldap servers exactly the same? | 14:23 |
| rodrigods | rderose, sorry to jump into the discussion with a totally different topic :) | 14:23 |
| dstanek | dikonoor: yes, we can't support that | 14:23 |
| dstanek | dikonoor: that is two different sets of users | 14:23 |
| rderose | rodrigods: :) | 14:23 |
| dikonoor | dstanek : ok..let's forget the multiple ldap problem for a minute.. This can be reproduced with a single ldap as well.. I ran into this problem when i configured my ldap incorrectly the first time and then configured it correctly and then couldn't authenticate | 14:24 |
| dstanek | dikonoor: i'm not sure how we can handle that case. i think you'd have to manually delete the user records. | 14:25 |
| dstanek | if you change how you uniquely identify users then all your previous data is incorrect | 14:25 |
| *** sheel has quit IRC | 14:26 | |
| dstanek | amakarov: are you around? | 14:26 |
| *** ravelar has joined #openstack-keystone | 14:26 | |
| amakarov | dstanek, hi! | 14:26 |
| rderose | rodrigods: okay, I'm not sure why we wouldn't want to put that in the manager layer. And to be honest, I think the only reason why we are doing schema validation in the controller layer is to take advantage of JSON validation. Otherwise, this would likely be in the manager layer as well. | 14:27 |
| dikonoor | rderose: dstanek : yes..all previous data is incorrect.. and then I would have to manually remove all the entries from the table | 14:27 |
| dikonoor | rderose: dstanek : Let's say I have just one LDAP and I configure keystone to user it such that the user-id-mapping is set to cn (for eg. cn=abc@abc.com)..now I authenticate..everything works fine | 14:27 |
| dikonoor | . now let me reconfigure keystone with the same LDAP such that user-id-mapping is set to uid (for eg. uid=3764836)..When keystone is restarted after this configuration, a new entry gets created in the id_mapping table and then when you try to authenticate , it will cause the same conflict user error at the nonlocal_user.. | 14:27 |
| dikonoor | rderose : Above is what I tried when I ran into the problem | 14:27 |
| rderose | dikonoor: I see, hmm... | 14:28 |
| rodrigods | rderose, hmm you are right... i would like to have the controller layer handling only JSON parsing (dict -> JSON) and query parameters | 14:29 |
| dstanek | amakarov: hey....just thinking about your comment about get_or_create for cache keys and i had a thought | 14:29 |
| rodrigods | rderose, will put it in the manager - the tricky part are the tests though | 14:29 |
| dstanek | dikonoor: i understand the usecase, but i don't think there is anything we can do about it. you would just ahve to delete your users and start over. | 14:29 |
| dikonoor | rderose: there could be other permutations and combinations where we could run into this and the only way to get out of this is to manually delete the entries from the nonlocal_user table | 14:29 |
| rodrigods | rderose, we don't have a test_core for credential, yet | 14:29 |
| *** slberger has joined #openstack-keystone | 14:30 | |
| dstanek | amakarov: https://review.openstack.org/#/c/349704/6/keystone/common/cache/core.py | 14:30 |
| dstanek | amakarov: it seems that get_or_create isn't actually locking between processes so i don't think it helps | 14:31 |
| dikonoor | rderose: dstanek: so I guess there's nothing much to do about it :( | 14:31 |
| dstanek | amakarov: but what is the initial value for the region key what just the region name? | 14:31 |
| rderose | dikonoor dstanek stevemar: what would be the problem is we removed the domain/name constraint for shadowing nonlocal users (ldap, custom)? | 14:31 |
| rodrigods | rderose, i could create one, but would be better to wait the encrypt credentials work land first | 14:31 |
| *** nishaYadav has quit IRC | 14:32 | |
| rderose | rodrigods: agree | 14:32 |
| dstanek | rderose: if someone tries to login with username/domain what would happen? | 14:32 |
| amakarov | dstanek, get_or_create uses Lock. I'll double check | 14:32 |
| rderose | dstanek: as long as the user id is unique, it would create a new entry in the nonlocal_user table | 14:33 |
| rderose | in dikonoor case, you would have 2 entries for the same user | 14:33 |
| *** bigdogstl has joined #openstack-keystone | 14:33 | |
| *** code-R has quit IRC | 14:34 | |
| dstanek | amakarov: it uses a Lock object that is implemented using the threading module | 14:34 |
| *** code-R has joined #openstack-keystone | 14:34 | |
| dstanek | rderose: tbh...we made this so confusing that i have no idea what'll happen | 14:36 |
| rderose | dstanek: ha ha ha :) | 14:36 |
| rderose | dstanek: alright, let me think this through | 14:36 |
| amakarov | dstanek, it uses backend mutex | 14:37 |
| dstanek | rderose: in the case of nonlocaluser what is the name? | 14:37 |
| amakarov | dstanek, https://bitbucket.org/zzzeek/dogpile.cache/src/669582c2e5bf12b1303f50c4b7ba3dad308eb1cc/dogpile/cache/backends/memcached.py?at=master&fileviewer=file-view-default | 14:38 |
| amakarov | in case of memcache backend ^^ | 14:39 |
| rderose | dstanek: nonlocal_user, just means non-SQL, so LDAP and custom driver | 14:39 |
| *** roxanaghe has joined #openstack-keystone | 14:39 | |
| rderose | dstanek: the name is the username | 14:39 |
| breton | [A[A | 14:40 |
| dstanek | amakarov: how does that get wired in when the code expicitly uses Lock? | 14:40 |
| dstanek | rderose: right, but where does it come from and how is it used? | 14:40 |
| *** ayoung has joined #openstack-keystone | 14:41 | |
| *** ChanServ sets mode: +v ayoung | 14:41 | |
| rderose | dstanek: it would come from LDAP (configurable) and it's only used to map the LDAP identity to a local identity | 14:41 |
| breton | oh wow | 14:42 |
| amakarov | dstanek, https://bitbucket.org/zzzeek/dogpile.cache/src/669582c2e5bf12b1303f50c4b7ba3dad308eb1cc/dogpile/cache/region.py?at=master&fileviewer=file-view-default#region.py-475 | 14:42 |
| *** lamt has joined #openstack-keystone | 14:42 | |
| amakarov | dstanek, and https://bitbucket.org/zzzeek/dogpile.cache/src/669582c2e5bf12b1303f50c4b7ba3dad308eb1cc/dogpile/cache/region.py?at=master&fileviewer=file-view-default#region.py-821 | 14:42 |
| dstanek | hmmm...i wonder why that's not working for me | 14:42 |
| *** bigdogstl has quit IRC | 14:43 | |
| dstanek | amakarov: i'm still not sure i can use it without recreating it. let me publish some code so i can explain | 14:43 |
| *** roxanaghe has quit IRC | 14:44 | |
| rderose | dikonoor: so do we have a bug? | 14:44 |
| rderose | dikonoor: other than, we still need to solve removing stale users and possibly issues around multiple identity drivers | 14:44 |
| zzzeek | amakarov: just spin up zookeeper :) | 14:46 |
| dstanek | zzzeek: too many things! | 14:47 |
| zzzeek | dstanek: distributed locks in memcached have the kind of big problem that values in memcached can just vanish | 14:47 |
| zzzeek | i dont recall how this is ameliorated by the lock here if at all | 14:48 |
| dstanek | zzzeek: in our case it's not too big a deal. a race condition or vanishing lock would just mean that data isn't cached as long as it could be. not sure it even matters. | 14:48 |
| zzzeek | dstanek: i have a dim recollection of some more serious side effect but...well it's too dim for me to remember :) | 14:49 |
| *** BjoernT has joined #openstack-keystone | 14:51 | |
| *** hockeynut has joined #openstack-keystone | 14:58 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: Minor docstring fix in mappings.py https://review.openstack.org/358698 | 14:58 |
| *** ayoung has quit IRC | 14:59 | |
| *** jaosorior_brb is now known as jaosorior | 15:00 | |
| *** code-R has quit IRC | 15:08 | |
| *** asettle has quit IRC | 15:08 | |
| dstanek | stevemar: is it better to reopen https://bugs.launchpad.net/keystone/+bug/1537617 or create another bug? | 15:09 |
| openstack | Launchpad bug 1537617 in OpenStack Identity (keystone) "caching of the catalog does not invalidate across processes" [High,Fix released] - Assigned to Morgan Fainberg (mdrnstm) | 15:09 |
| *** woodburn has quit IRC | 15:11 | |
| openstackgerrit | David Stanek proposed openstack/keystone: Distributed cache namespace to invalidate regions https://review.openstack.org/349704 | 15:11 |
| dstanek | zzzeek: if you have a sec take a quick peek at that. i'd love to get your opinion. | 15:12 |
| dstanek | amakarov: ^ | 15:12 |
| zzzeek | dstanek: sure | 15:12 |
| dstanek | amakarov: so if i wanted to use get_or_create i would have to have a region subclass that deals with the key function for the decorator and a backend proxy that deals with the dynamic key names | 15:14 |
| *** bigdogstl has joined #openstack-keystone | 15:14 | |
| dstanek | amakarov: while it's possible it isn't as clean | 15:14 |
| dstanek | amakarov: the reason for the proxy is that get_or_create uses self.backend.* effectively bypassing the region key logic | 15:16 |
| dstanek | amakarov: after i add a few more test cases i can show what that code would look like | 15:16 |
| *** woodburn has joined #openstack-keystone | 15:17 | |
| *** erhudy has joined #openstack-keystone | 15:19 | |
| amakarov | dstanek, I understand task may seem complex, though I'd like to have this solution built to last even in next releases as I like it more than mine. We'll just have to move it to oslo.cache eventually. | 15:20 |
| dstanek | amakarov: or better yet, in dogpile directly | 15:20 |
| amakarov | dstanek, I agree. I'll take a closer look if it can be done as invalidation strategy | 15:21 |
| dstanek | amakarov: invalidation strategy? | 15:24 |
| amakarov | dstanek, yes: https://bitbucket.org/zzzeek/dogpile.cache/src/669582c2e5bf12b1303f50c4b7ba3dad308eb1cc/dogpile/cache/region.py?at=master&fileviewer=file-view-default#region.py-28 | 15:24 |
| amakarov | it's new for dogpile.cache 0.6.2 | 15:24 |
| dstanek | amakarov: ah that. it doesn't allow you to intercept keys | 15:25 |
| zzzeek | dstanek: this review is not how I'd do it. | 15:26 |
| zzzeek | dstanek: subclassing region should never be needed. | 15:27 |
| zzzeek | dstanek: the thing that _add_region_key_qualfiier is doing should be with the key_mangler | 15:27 |
| amakarov | dstanek, yes, but keys can be changed by function passed to region | 15:28 |
| *** code-R has joined #openstack-keystone | 15:28 | |
| amakarov | function_key_generator | 15:28 |
| dstanek | zzzeek: i initially did that but ran into something.... | 15:28 |
| *** code-R has quit IRC | 15:29 | |
| dstanek | zzzeek: oh, right. i was having issues with the region key, but i could probably solve that by special casing a key...if it starts with <<region>> then don't add the region id | 15:29 |
| *** atod has joined #openstack-keystone | 15:30 | |
| *** code-R has joined #openstack-keystone | 15:30 | |
| zzzeek | dstanek: there is also proxybackend | 15:30 |
| dstanek | amakarov: i may try zzzeek's suggestion again and try to use an invalidation strategy | 15:31 |
| amakarov | dstanek, invalidation strategy can't be used for stable/* releases | 15:31 |
| amakarov | as dogpile.cache capped there | 15:31 |
| dstanek | amakarov: oh right. we need to backport | 15:31 |
| dstanek | ugg | 15:32 |
| *** bigdogstl has quit IRC | 15:32 | |
| dstanek | amakarov: i'll submit a second patch for that then | 15:32 |
| bknudson | dogpile.cache is not capped: http://git.openstack.org/cgit/openstack/keystone/tree/requirements.txt?h=stable/mitaka#n36 | 15:32 |
| *** bigdogstl has joined #openstack-keystone | 15:33 | |
| dstanek | bknudson: we had a discussion last week about using some of the new fangled things and the conclusion was we couldn't | 15:33 |
| amakarov | bknudson, so if I install Liberty, it will use latest dogpile.cache? | 15:33 |
| dstanek | i don't remember why though | 15:33 |
| bknudson | you can install the latest dogpile.cache with liberty. | 15:33 |
| bknudson | you can use any version newer than 0.5.7 | 15:34 |
| *** woodburn has quit IRC | 15:34 | |
| dstanek | amakarov: zzzeek: respinning with some changes | 15:34 |
| *** code-R has quit IRC | 15:35 | |
| amakarov | dstanek, here is my patch using inv. strategy approach: https://review.openstack.org/#/c/354831/ | 15:35 |
| *** Administrator__ has quit IRC | 15:36 | |
| *** Administrator__ has joined #openstack-keystone | 15:37 | |
| bknudson | amakarov: oh, you were asking about liberty -- it dogpile.cache>=0.5.4 on liberty. | 15:37 |
| amakarov | bknudson, good to know: we can backport my approach then if dstanek will not succeed for some reason | 15:38 |
| *** gyee has joined #openstack-keystone | 15:39 | |
| *** asettle has joined #openstack-keystone | 15:39 | |
| amakarov | bknudson, dstanek can you please help with gate-oslo.cache-requirements? Looks like oslo.cache don't like dogpile.cache>=0.6.2 | 15:41 |
| dstanek | amakarov: why not? | 15:42 |
| openstackgerrit | henry-nash proposed openstack/keystone: Modify sql banned opreations for each of the new repos https://review.openstack.org/358723 | 15:42 |
| dstanek | fg | 15:43 |
| dstanek | lol | 15:43 |
| bknudson | amakarov: you can't change requirements for any project. requirements changes have to be made to global requirements repo. | 15:43 |
| *** su_zhang has quit IRC | 15:43 | |
| bknudson | amakarov: http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt | 15:43 |
| *** su_zhang has joined #openstack-keystone | 15:43 | |
| *** su_zhang has quit IRC | 15:44 | |
| *** su_zhang has joined #openstack-keystone | 15:44 | |
| amakarov | bknudson, thank you. I'll remove my requirement and see then | 15:45 |
| *** thiagolib has joined #openstack-keystone | 15:45 | |
| *** bigdogstl has quit IRC | 15:48 | |
| *** su_zhang has quit IRC | 15:49 | |
| *** michauds has joined #openstack-keystone | 15:50 | |
| openstackgerrit | henry-nash proposed openstack/keystone: Fix issue of password created_at being left as nullable https://review.openstack.org/357789 | 15:53 |
| *** sdake has quit IRC | 15:54 | |
| *** sdake has joined #openstack-keystone | 15:55 | |
| henrynash | stevemar: on https://review.openstack.org/#/c/357789/, not sure grok your questions... | 15:56 |
| *** bigdogstl has joined #openstack-keystone | 15:56 | |
| *** Ephur has joined #openstack-keystone | 15:57 | |
| *** chrisshattuck has joined #openstack-keystone | 15:59 | |
| *** dgonzalez has quit IRC | 16:03 | |
| *** bradjones has quit IRC | 16:03 | |
| *** tonytan_brb has joined #openstack-keystone | 16:03 | |
| *** tlbr_ has quit IRC | 16:04 | |
| *** dgonzalez has joined #openstack-keystone | 16:05 | |
| *** tonytan4ever has quit IRC | 16:05 | |
| *** frickler has quit IRC | 16:06 | |
| *** bradjones has joined #openstack-keystone | 16:06 | |
| *** bradjones has quit IRC | 16:06 | |
| *** bradjones has joined #openstack-keystone | 16:06 | |
| *** atod has quit IRC | 16:07 | |
| *** amakarov has quit IRC | 16:07 | |
| *** frickler has joined #openstack-keystone | 16:07 | |
| *** amakarov has joined #openstack-keystone | 16:07 | |
| *** asettle has quit IRC | 16:11 | |
| *** bigdogstl has quit IRC | 16:12 | |
| openstackgerrit | David Stanek proposed openstack/keystone: Distributed cache namespace to invalidate regions https://review.openstack.org/349704 | 16:12 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Implement encryption of credentials at rest https://review.openstack.org/355618 | 16:12 |
| *** tlbr has joined #openstack-keystone | 16:13 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Document credential encryption https://review.openstack.org/354497 | 16:13 |
| *** bigdogstl has joined #openstack-keystone | 16:14 | |
| openstackgerrit | David Stanek proposed openstack/keystone: Distributed cache namespace to invalidate regions https://review.openstack.org/349704 | 16:14 |
| lbragstad | henrynash dolphm dstanek I added some migration tests to https://review.openstack.org/#/c/355618/10 but I'm still unable to figure out why the SqlLite tests fail | 16:14 |
| *** woodburn has joined #openstack-keystone | 16:14 | |
| lbragstad | so far - the only thing that is making the implementation of credential encryption fail the gate is this test - http://cdn.pasteraw.com/6zaqyxiupmfikpeqbzn86wwicgqcni3 | 16:15 |
| dstanek | lbragstad: is the migration not happening? | 16:17 |
| lbragstad | dstanek I tested it locally and with the new tests I wrote and it seems to be working for the sql case | 16:17 |
| lbragstad | dstanek something seems to be messed up with sqlite though | 16:17 |
| henrynash | lbragstad: also see https://review.openstack.org/357789 | 16:18 |
| lbragstad | it's failing to walk the versions in the expand repo because it doesn't think the credential table exists | 16:18 |
| dstanek | lbragstad: i looks like other tests fail | 16:18 |
| dstanek | lbragstad: look at henrynash's patch. you guys are using the same versions so your migrations probably are not applied? | 16:19 |
| lbragstad | dstanek neither of them have merged though? | 16:19 |
| *** asettle has joined #openstack-keystone | 16:23 | |
| stevemar | o/ | 16:26 |
| stevemar | henrynash: https://review.openstack.org/#/c/358723/ is looking crazy | 16:28 |
| *** tesseract- has quit IRC | 16:28 | |
| *** asettle has quit IRC | 16:28 | |
| stevemar | henrynash: for the follow on patch... is it sqlalchemy magic that know to use the postgres trigger when using postgres? | 16:28 |
| *** pcaruana has quit IRC | 16:29 | |
| lbragstad | henrynash how are the triggers applied? | 16:30 |
| lbragstad | henrynash are they applied based on the naming + the sql implementation being used? | 16:30 |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: Pre-cache new tokens https://review.openstack.org/309146 | 16:31 |
| *** chrisshattuck has quit IRC | 16:32 | |
| *** slberger has quit IRC | 16:32 | |
| *** chrisshattuck has joined #openstack-keystone | 16:32 | |
| stevemar | henrynash: yeah, what lbragstad is asking | 16:32 |
| *** slberger has joined #openstack-keystone | 16:34 | |
| *** chrisshattuck has quit IRC | 16:35 | |
| *** bigdogstl has quit IRC | 16:36 | |
| *** jmccrory_away is now known as jmccrory | 16:37 | |
| lbragstad | stevemar FYI - this is what we were talking about in the meeting a couple weeks ago http://lists.openstack.org/pipermail/openstack-dev/2016-August/102059.html | 16:40 |
| lbragstad | looks like the templates are proposed | 16:40 |
| henrynash | lbragstad: so sqlalchemy migrate will execute a file named '%03d_<name_of_db>_<upgrade or downgrade>.sql | 16:46 |
| henrynash | lbragstad: if that doesn't exist, it will, I think, execute the non dababase specific version | 16:47 |
| henrynash | stevemar: yes, just have to learn the magic of each DB language (yuk) | 16:48 |
| henrynash | stevemar: crazy in what way (on https://review.openstack.org/#/c/358723/) | 16:49 |
| stevemar | henrynash: all the lambdas! | 16:49 |
| stevemar | henrynash: cool, i didn't know <name_of_db> was magic | 16:49 |
| stevemar | TIL | 16:49 |
| *** gagehugo has joined #openstack-keystone | 16:51 | |
| henrynash | stevemar: yeah...exsiting version is actually broken....since it tries to pass in a parameter to the function being called in the lambda...which doesn't work since the variable isn't fixed at the time of setting up the lambda | 16:51 |
| *** gagehugo has quit IRC | 16:51 | |
| *** gagehugo has joined #openstack-keystone | 16:52 | |
| henrynash | stevemar: i.e. current version says lambda *a, **k: self._explode(resource, 'alter'))...but since resource variable gets changed after the monkeypatch, this is actually wrong | 16:53 |
| henrynash | stevemar: I couldn't think of a better way round the problem than the yucky duplication of lambdas | 16:53 |
| stevemar | henrynash: oh i'm sure it works, i just don't like seeing it :P | 16:54 |
| openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: Support domain-specific configuration management https://review.openstack.org/358770 | 16:54 |
| *** dims has quit IRC | 16:54 | |
| * stevemar is a special sort of exhausted today | 16:54 | |
| rodrigods | henrynash, ^ | 16:54 |
| henrynash | rodigods: cool...will look in a while, thanks for picking this up... | 16:55 |
| rodrigods | henrynash, created a different change since i did some big modifications in the code and i'd like your feedback :) | 16:55 |
| *** jaosorior has quit IRC | 16:55 | |
| stevemar | rodrigods: i like your print statements $$$$$$$$$$$$$$$$$ | 16:55 |
| rodrigods | stevemar, lol | 16:55 |
| rodrigods | will remove | 16:55 |
| henrynash | rodigods: gotta stand out, right | 16:56 |
| *** dims has joined #openstack-keystone | 16:56 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: Support domain-specific configuration management https://review.openstack.org/358770 | 16:56 |
| *** woodburn has quit IRC | 16:58 | |
| henrynash | stevemar: definitely open to suggestions on the lambdas....first one to admit I'm pretty much a lambda virgin (which I guess is marginally better than being a lama virgin...) | 16:58 |
| stevemar | lol | 16:59 |
| *** su_zhang has joined #openstack-keystone | 17:01 | |
| *** su_zhang has quit IRC | 17:01 | |
| *** su_zhang has joined #openstack-keystone | 17:01 | |
| *** tonytan4ever has joined #openstack-keystone | 17:06 | |
| *** tonytan_brb has quit IRC | 17:08 | |
| *** bigdogstl has joined #openstack-keystone | 17:10 | |
| *** tqtran has joined #openstack-keystone | 17:13 | |
| openstackgerrit | David Stanek proposed openstack/keystone: Distributed cache namespace to invalidate regions https://review.openstack.org/349704 | 17:16 |
| *** bigdogstl has quit IRC | 17:16 | |
| *** tqtran has quit IRC | 17:17 | |
| *** code-R has joined #openstack-keystone | 17:19 | |
| *** atod has joined #openstack-keystone | 17:20 | |
| *** code-R_ has joined #openstack-keystone | 17:22 | |
| *** gagehugo has quit IRC | 17:23 | |
| *** gagehugo has joined #openstack-keystone | 17:23 | |
| *** edtubill has joined #openstack-keystone | 17:24 | |
| *** atod has quit IRC | 17:25 | |
| *** code-R has quit IRC | 17:25 | |
| *** asettle has joined #openstack-keystone | 17:25 | |
| *** ddieterly is now known as ddieterly[away] | 17:25 | |
| stevemar | dstanek: thanks again for working on the cache issues | 17:26 |
| stevemar | let me know when you want me to formally transfer the title of cache-master from notmorgan to you :D | 17:27 |
| dikonoor | rderose: hi, was away. Will open a bug for the conflicting user problem | 17:27 |
| dikonoor | rderose: let me open .. | 17:28 |
| *** lamt has quit IRC | 17:28 | |
| dstanek | dikonoor: for the misconfiguration problem? | 17:29 |
| dikonoor | dstanek : "rderose> dikonoor: so do we have a bug?" >> I thought this is for the conflict user problem | 17:31 |
| *** asettle has quit IRC | 17:31 | |
| *** code-R_ has quit IRC | 17:31 | |
| dstanek | dikonoor: i would vote for a won't fix on a bug where during the initial setup the configuration was messed up | 17:31 |
| dstanek | i don't think there is really anything we can do about that | 17:32 |
| *** code-R has joined #openstack-keystone | 17:35 | |
| dikonoor | dstanek: ok.. rderose around? I get your point.. | 17:35 |
| *** tqtran has joined #openstack-keystone | 17:35 | |
| *** code-R has quit IRC | 17:40 | |
| notmorgan | so glad it's someone else's headache to deal with caching now. | 17:40 |
| *** code-R has joined #openstack-keystone | 17:42 | |
| dstanek | zzzeek: ah, i implemented in terms of a key_mangler and i found the problem again. it's that the key_mangler isn't used by the memoize decorator so i have to also provide a function_key_generator | 17:43 |
| *** haplo37__ has quit IRC | 17:49 | |
| lbragstad | henrynash when this class is setup - does it run the legacy migrations first? | 17:49 |
| lbragstad | https://github.com/openstack/keystone/blob/0cd732b2b0d3e18cbdbceecf66a83cd378c27717/keystone/tests/unit/test_sql_banned_operations.py#L211 | 17:49 |
| amakarov | dstanek, I think you function_key_generator is the thing - key_mangler is just sha1 encoder | 17:50 |
| amakarov | s/you// | 17:50 |
| lbragstad | henrynash if we weren't running the legacy migrations that would explain why this fails in my patch - http://cdn.pasteraw.com/6zaqyxiupmfikpeqbzn86wwicgqcni3 | 17:50 |
| dolphm | henrynash: still around? | 17:50 |
| dstanek | amakarov: zzzeek mentioned in terms of using the key_mangler earlier, which is what i originally wanted to do. unfortunately it isn't used by the decorator | 17:51 |
| lbragstad | since the credential table is created by a migration in another repo? | 17:51 |
| dstanek | amakarov: function_key_generator is only used by the decorator. so both have to be provided | 17:51 |
| zzzeek | dstanek: key mangler is used by the decorator, because the decorator calls get_or_create() | 17:51 |
| *** Gorian|work has joined #openstack-keystone | 17:52 | |
| amakarov | dstanek, iiuc key_mangler is just to keep keys short | 17:52 |
| zzzeek | amakarov: key_mangler is for whatever you need the keys to look like | 17:52 |
| dstanek | zzzeek: the key mangler is used by Region.get and get_or_create uses self.backend.get | 17:52 |
| notmorgan | dstanek: key_mangler is used by the decorator, not used by .get/.set | 17:52 |
| dstanek | amakarov: it's a good hook to change the key | 17:53 |
| bknudson | I was worried that the sha1 key mangler was causing collisions but that doesn't seem to be the case. | 17:53 |
| dstanek | notmorgan: https://bitbucket.org/zzzeek/dogpile.cache/src/669582c2e5bf12b1303f50c4b7ba3dad308eb1cc/dogpile/cache/region.py?at=master&fileviewer=file-view-default#region.py-624 | 17:53 |
| notmorgan | dstanek: without the keymangler the memoization can't work in keystone, we exceed the keysize allowed by memcache | 17:53 |
| notmorgan | dstanek: because we concat func name, class, and arguments | 17:54 |
| bknudson | won't work with pki tokens for sure | 17:54 |
| * zzzeek hoorays notmorgan is here :) | 17:54 | |
| dstanek | notmorgan: bknudson: maybe that is the cause of the bug then? i really don't see it being used in the decorator | 17:54 |
| dstanek | https://bitbucket.org/zzzeek/dogpile.cache/src/669582c2e5bf12b1303f50c4b7ba3dad308eb1cc/dogpile/cache/region.py?at=master&fileviewer=file-view-default#region.py-780 | 17:54 |
| bknudson | dstanek: what bug? | 17:54 |
| stevemar | uh oh, did notmorgan punch a hole in the bug / patch? :\ | 17:55 |
| amakarov | btw, backend may have own key_mangler :) | 17:55 |
| amakarov | https://bitbucket.org/zzzeek/dogpile.cache/src/669582c2e5bf12b1303f50c4b7ba3dad308eb1cc/dogpile/cache/region.py?at=master&fileviewer=file-view-default#region.py-432 | 17:55 |
| dstanek | bknudson: the one you were trying to solve by fixing the sha1 | 17:55 |
| stevemar | bknudson: this one: https://bugs.launchpad.net/bugs/1600393 and https://bugs.launchpad.net/bugs/1600394 | 17:55 |
| openstack | Launchpad bug 1600393 in OpenStack Identity (keystone) "v2.0 catalog seen in v3 token" [Critical,Confirmed] - Assigned to David Stanek (dstanek) | 17:55 |
| openstack | Launchpad bug 1600394 in OpenStack Identity (keystone) "memcache raising "too many values to unpack"" [Critical,Confirmed] - Assigned to David Stanek (dstanek) | 17:55 |
| *** code-R has quit IRC | 17:55 | |
| notmorgan | dstanek: in get_or_create which is what the decorator uses | 17:55 |
| notmorgan | https://bitbucket.org/zzzeek/dogpile.cache/src/669582c2e5bf12b1303f50c4b7ba3dad308eb1cc/dogpile/cache/region.py?at=master&fileviewer=file-view-default#region.py-777 | 17:55 |
| bknudson | dstanek: right, I tried changing the mangler to sha256 but browne tried it and still hit the errors. | 17:55 |
| notmorgan | bknudson: sha1 shouldn't be colliding | 17:56 |
| bknudson | also I tried to see if I could cause a collision with sha1 and couldn't. | 17:56 |
| notmorgan | what is the error? | 17:56 |
| bknudson | computer ran out of memory | 17:56 |
| notmorgan | lol | 17:56 |
| bknudson | notmorgan: the error is that keystone gets a value from the cache that's obviously not what was put in there. | 17:56 |
| notmorgan | uhm | 17:56 |
| dstanek | notmorgan: it looks like the cache is returning random object. like a list instead of a user, etc. | 17:57 |
| notmorgan | bknudson: in what context, where? | 17:57 |
| bknudson | notmorgan: here's where we saw it: https://bugs.launchpad.net/keystone/+bug/1609566 | 17:58 |
| openstack | Launchpad bug 1609566 in OpenStack Identity (keystone) "500 error from revocation event deserialize" [Medium,Incomplete] - Assigned to Brant Knudson (blk-u) | 17:58 |
| notmorgan | revocation events serialize badly and always have | 17:58 |
| bknudson | then there's this one from someone else: https://bugs.launchpad.net/keystone/+bug/1600394 | 17:59 |
| openstack | Launchpad bug 1600394 in OpenStack Identity (keystone) "memcache raising "too many values to unpack"" [Critical,Confirmed] - Assigned to David Stanek (dstanek) | 17:59 |
| notmorgan | it's been a horrible series of hacks to get around that | 17:59 |
| notmorgan | ok give me a few minutes let me get to my other machine and i'll look at it | 17:59 |
| bknudson | and this is another issue that looks similar: https://bugs.launchpad.net/keystone/+bug/1600393 | 17:59 |
| openstack | Launchpad bug 1600393 in OpenStack Identity (keystone) "v2.0 catalog seen in v3 token" [Critical,Confirmed] - Assigned to David Stanek (dstanek) | 17:59 |
| stevemar | notmorgan: yes, bknudson has listed the trifecta of similar looking caching bugs | 18:00 |
| notmorgan | i expect this is due to the cache code reshuffle that occured. | 18:00 |
| dstanek | stevemar: i haven't even started looking at those yet. just finally got all the tests written for invalidation this morning | 18:01 |
| * notmorgan rapidly feels like the answer is rm -rf keystone/common/cache | 18:01 | |
| *** roxanaghe has joined #openstack-keystone | 18:01 | |
| dstanek | notmorgan: lol | 18:01 |
| dstanek | we made this so much harder than it needed to be | 18:01 |
| notmorgan | then just rip out the decorator and use .get/set directly | 18:01 |
| notmorgan | seriously | 18:01 |
| notmorgan | make it simple if that will be easier to manage | 18:02 |
| notmorgan | :) | 18:02 |
| notmorgan | i'll look at those bugs in a moment. | 18:02 |
| dstanek | notmorgan: that may be simplier than the docorator. we have an osic task to look at that. i'm just working on invalidation now. | 18:03 |
| notmorgan | the __init__ thing is a fail in where someone changed the instantiation with msgpack | 18:03 |
| notmorgan | bug 1609566 | 18:03 |
| openstack | bug 1609566 in OpenStack Identity (keystone) "500 error from revocation event deserialize" [Medium,Incomplete] https://launchpad.net/bugs/1609566 - Assigned to Brant Knudson (blk-u) | 18:03 |
| notmorgan | that one i've seen and can probably isolate in a few moments. it's simply a bad refactor when folks removed the revocation tree | 18:04 |
| stevemar | notmorgan: by all means, that would be awesome... | 18:04 |
| notmorgan | the reinstantiation with **kwargs is a stupid pattern | 18:04 |
| notmorgan | and i'm sorry i used it as a workaround | 18:05 |
| lbragstad | lunch - brb | 18:06 |
| notmorgan | bug 1600394 is erroring in memcache library | 18:06 |
| openstack | bug 1600394 in OpenStack Identity (keystone) "memcache raising "too many values to unpack"" [Critical,Confirmed] https://launchpad.net/bugs/1600394 - Assigned to David Stanek (dstanek) | 18:06 |
| notmorgan | "/usr/lib/python2.7/dist-packages/memcache.py", line 1211, in _expectvalue | 18:06 |
| notmorgan | some how bad data is being passed into memcache itself. | 18:07 |
| notmorgan | python lib | 18:07 |
| notmorgan | this could be a memcache python bug, a bug in dogpile or a bug in our code | 18:07 |
| notmorgan | unrelated | 18:07 |
| notmorgan | to the previous one | 18:08 |
| notmorgan | bug 1600393 just is an issue where we need to transform the catalog because of $STUPID_CATALOG_IS_PART_OF_THE_TOKEN_BODY_AND_Is_A_CONTRACT$ issues, and we cache the response whole-sale. likely unrelated to the other two bugs | 18:09 |
| openstack | bug 1600393 in OpenStack Identity (keystone) "v2.0 catalog seen in v3 token" [Critical,Confirmed] https://launchpad.net/bugs/1600393 - Assigned to David Stanek (dstanek) | 18:09 |
| bknudson | 1600394 is the one that makes me wonder if this is a threading issue or something | 18:09 |
| notmorgan | maybe | 18:10 |
| notmorgan | but i'm going to guess it's just simply bad code. | 18:10 |
| notmorgan | before i blame threading | 18:10 |
| notmorgan | also memcache explicitly uses thread.local | 18:11 |
| notmorgan | so we had to hack around that, we might have introduced buggyness there | 18:11 |
| *** Ephur has quit IRC | 18:12 | |
| *** Ephur has joined #openstack-keystone | 18:14 | |
| *** ddieterly[away] has quit IRC | 18:26 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Fix credential update to ec2 type https://review.openstack.org/357950 | 18:28 |
| *** amakarov is now known as amakarov_away | 18:28 | |
| *** sdake has quit IRC | 18:29 | |
| *** ddieterly has joined #openstack-keystone | 18:31 | |
| *** markvoelker has quit IRC | 18:33 | |
| *** ddieterly is now known as ddieterly[away] | 18:34 | |
| rderose | dikonoor: you still there? | 18:41 |
| *** woodburn has joined #openstack-keystone | 18:41 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Fix credential update to ec2 type https://review.openstack.org/357950 | 18:45 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Fix credential update to ec2 type https://review.openstack.org/357950 | 18:46 |
| openstackgerrit | David Stanek proposed openstack/keystone: Distributed cache namespace to invalidate regions https://review.openstack.org/358812 | 18:47 |
| *** dikonoor has quit IRC | 18:47 | |
| *** su_zhang has quit IRC | 18:49 | |
| *** ddieterly[away] is now known as ddieterly | 18:56 | |
| *** haplo37__ has joined #openstack-keystone | 18:57 | |
| openstackgerrit | Merged openstack/python-keystoneclient: Do not send user ids as payload https://review.openstack.org/348881 | 19:06 |
| *** lamt has joined #openstack-keystone | 19:07 | |
| *** gagehugo has quit IRC | 19:13 | |
| dstanek | amakarov_away: let me know when you are back. i'm wondering if we need to try to implement hard/soft invalidation or just complete descructive invalidation like i'm doing | 19:13 |
| *** Ephur has quit IRC | 19:18 | |
| *** su_zhang has joined #openstack-keystone | 19:19 | |
| notmorgan | dstanek: fwiw, i think you can probably get away with just supplying a smarter key mangler | 19:21 |
| dstanek | notmorgan: my last review does that, but still needed a custom invalidate method. i could do it via the new interface though | 19:24 |
| dstanek | notmorgan: https://review.openstack.org/#/c/358812/1/keystone/common/cache/core.py | 19:24 |
| notmorgan | dstanek: i would much much rather not see a subclass of region need to be implemented just for this | 19:25 |
| dstanek | notmorgan: then i have to use the new interface | 19:25 |
| notmorgan | i would much prefer that if we could | 19:25 |
| *** su_zhang has quit IRC | 19:26 | |
| dstanek | notmorgan: halfway through testing that option | 19:26 |
| notmorgan | i do get we might need what you've implemented here for backporting | 19:26 |
| * notmorgan nods. | 19:26 | |
| *** haplo37__ has quit IRC | 19:26 | |
| notmorgan | fwiw, i wont block this implementation, just trying to limit the level of stuff we have to carry/override | 19:27 |
| *** david-lyle has joined #openstack-keystone | 19:30 | |
| *** markvoelker has joined #openstack-keystone | 19:32 | |
| openstackgerrit | David Stanek proposed openstack/keystone: Distributed cache namespace to invalidate regions https://review.openstack.org/358826 | 19:33 |
| *** markvoelker_ has joined #openstack-keystone | 19:34 | |
| dstanek | notmorgan: here is the other impl https://review.openstack.org/#/c/358826/1/keystone/common/cache/core.py | 19:34 |
| dstanek | the worry there was backporting | 19:34 |
| dstanek | it would require older keystone installations to update their dogpile.cache | 19:35 |
| *** markvoelker has quit IRC | 19:37 | |
| *** rcernin has joined #openstack-keystone | 19:41 | |
| *** david-lyle has quit IRC | 19:42 | |
| *** sdake has joined #openstack-keystone | 19:42 | |
| *** david-lyle has joined #openstack-keystone | 19:46 | |
| *** markvoelker has joined #openstack-keystone | 19:48 | |
| *** markvoelker_ has quit IRC | 19:51 | |
| *** asettle has joined #openstack-keystone | 19:59 | |
| *** asettle has quit IRC | 19:59 | |
| *** tonytan4ever has quit IRC | 19:59 | |
| *** tonytan4ever has joined #openstack-keystone | 20:00 | |
| *** ayoung has joined #openstack-keystone | 20:03 | |
| *** ChanServ sets mode: +v ayoung | 20:03 | |
| *** ddieterly is now known as ddieterly[away] | 20:05 | |
| *** su_zhang has joined #openstack-keystone | 20:08 | |
| *** tqtran has quit IRC | 20:09 | |
| *** ddieterly[away] is now known as ddieterly | 20:12 | |
| *** tqtran has joined #openstack-keystone | 20:13 | |
| *** markvoelker has quit IRC | 20:14 | |
| *** sdake has quit IRC | 20:21 | |
| dstanek | zzzeek: thoughts on this nugget of goodness when you have a few https://review.openstack.org/#/c/358826/1/keystone/common/cache/core.py | 20:28 |
| *** sdake has joined #openstack-keystone | 20:35 | |
| *** david-lyle has quit IRC | 20:38 | |
| *** david-lyle has joined #openstack-keystone | 20:39 | |
| *** ddieterly has quit IRC | 20:43 | |
| *** david-lyle has quit IRC | 20:44 | |
| *** david-lyle_ has joined #openstack-keystone | 20:44 | |
| *** david-lyle_ has quit IRC | 20:44 | |
| *** chrisshattuck has joined #openstack-keystone | 20:54 | |
| *** chrisshattuck has quit IRC | 20:55 | |
| *** chrisshattuck has joined #openstack-keystone | 20:56 | |
| *** chrisshattuck has quit IRC | 20:56 | |
| *** atod has joined #openstack-keystone | 20:57 | |
| *** chrisshattuck has joined #openstack-keystone | 20:57 | |
| *** raildo has quit IRC | 20:58 | |
| *** dgonzalez has quit IRC | 21:01 | |
| *** atod has quit IRC | 21:01 | |
| *** dgonzalez has joined #openstack-keystone | 21:03 | |
| notmorgan | dstanek: ... i think i already fixed 1609566 at one point | 21:03 |
| notmorgan | this feels super familiar | 21:03 |
| notmorgan | like... i already debugged it? | 21:03 |
| *** julim has quit IRC | 21:05 | |
| openstackgerrit | Merged openstack/keystone: Updated from global requirements https://review.openstack.org/356872 | 21:08 |
| openstackgerrit | Merged openstack/keystone: Create unit tests for the policy drivers https://review.openstack.org/212957 | 21:09 |
| *** chrisshattuck has quit IRC | 21:10 | |
| notmorgan | oh. | 21:12 |
| notmorgan | Hah | 21:12 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Implement encryption of credentials at rest https://review.openstack.org/355618 | 21:12 |
| notmorgan | i am almost positive i know exactly what is the cause the the keywords must be strings | 21:12 |
| notmorgan | rolling a fix now. | 21:12 |
| lbragstad | dolphm checkout the last test I added here - https://review.openstack.org/#/c/355618/11/keystone/tests/unit/test_sql_upgrade.py | 21:13 |
| lbragstad | dolphm per our discussion early | 21:13 |
| lbragstad | that passes for me locally | 21:13 |
| dolphm | lbragstad: looking | 21:13 |
| dolphm | lbragstad: what's up with this patch btw? https://review.openstack.org/#/c/317169/ | 21:16 |
| dolphm | lbragstad: same commit summary | 21:16 |
| lbragstad | dolphm ah - i ended up working the bits we were going to keep into a separate commit - i must have forgot to update the change-id of nonameentername's patch when i submitted | 21:17 |
| *** gagehugo has joined #openstack-keystone | 21:19 | |
| *** david-lyle_ has joined #openstack-keystone | 21:19 | |
| notmorgan | dolphm, ayoung: ugh I can't ever seem to remember atm "continue" or "next" -- hazards of working with multiple languages :P | 21:21 |
| ayoung | notmorgan, what tool? | 21:21 |
| ayoung | git rebase --continue? | 21:22 |
| notmorgan | ayoung: no in python | 21:23 |
| notmorgan | ayoung: in loops | 21:23 |
| notmorgan | some languages use "continue" some are "next" etc | 21:23 |
| openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: Support domain-specific configuration management https://review.openstack.org/358770 | 21:25 |
| notmorgan | ayoung: somehow I got roped into looking at cache code again | 21:26 |
| dolphm | lbragstad: is the credential_migrate command still useful? | 21:27 |
| lbragstad | dolphm I think we will still need that for operators to make sure all credentials encrypted with the same key before rotating credential keys | 21:28 |
| dolphm | lbragstad: ooooh | 21:29 |
| lbragstad | in other words - make sure all credentials are migrated to the latest primary key before doing a rotation to make sure we don't get rid of a secondary key that is still needed to decrypt a credential | 21:29 |
| dolphm | lbragstad: gotcha | 21:31 |
| lbragstad | dolphm i have a section on that in the docs for credential encryption | 21:32 |
| *** Ephur has joined #openstack-keystone | 21:33 | |
| *** david-lyle_ has quit IRC | 21:34 | |
| *** adriant has joined #openstack-keystone | 21:35 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Implement encryption of credentials at rest https://review.openstack.org/355618 | 21:37 |
| zzzeek | dstanek: does it work ? | 21:38 |
| *** edtubill has quit IRC | 21:40 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone: Filter data when deserializing RevokeEvents https://review.openstack.org/358872 | 21:40 |
| notmorgan | stevemar, dstanek: ^ cleanup bad serialization if it occurs | 21:41 |
| dolphm | lbragstad: i think you need more triggers and more complicated triggers :( | 21:46 |
| lbragstad | dolphm outside of the 3 in the 002 expand script? | 21:48 |
| dolphm | lbragstad: yeah... | 21:48 |
| dolphm | lbragstad: you need to block both INSERTs and UPDATEs, right? | 21:49 |
| lbragstad | dolphm oh - good point | 21:49 |
| lbragstad | i didn't think about that | 21:49 |
| dolphm | lbragstad: which means your data migration step will be rejected | 21:49 |
| *** pauloewerton has quit IRC | 21:49 | |
| lbragstad | dolphm ah | 21:50 |
| dolphm | lbragstad: which means you need more complicated triggers | 21:50 |
| *** markvoelker has joined #openstack-keystone | 21:52 | |
| lbragstad | hmmm | 21:54 |
| *** lamt has quit IRC | 21:55 | |
| dolphm | lbragstad: just posted a review with what i was thinking | 21:57 |
| lbragstad | dolphm sweet - thanks for the review | 22:05 |
| *** jdennis has quit IRC | 22:09 | |
| *** edmondsw has quit IRC | 22:10 | |
| *** bigdogst_ has joined #openstack-keystone | 22:10 | |
| *** jdennis has joined #openstack-keystone | 22:10 | |
| *** bigdogst_ has quit IRC | 22:14 | |
| *** spedione is now known as spedione|AWAY | 22:15 | |
| *** jamielennox|away is now known as jamielennox | 22:15 | |
| *** itisha has quit IRC | 22:20 | |
| *** slberger has left #openstack-keystone | 22:32 | |
| jamielennox | stevemar: wow, wo https://review.openstack.org/#/c/357633/ has a +A already | 22:35 |
| jamielennox | stevemar: i was going to check with you, dtroyer_zz, and mordred if you think it's sufficient to have just two additional components to the user_agent | 22:36 |
| jamielennox | to me that's the basic, nova/X glanceclient/X keystoneauth... | 22:36 |
| *** david-lyle_ has joined #openstack-keystone | 22:37 | |
| jamielennox | but i'm wondering if there's ever a need for more there, do we want to report an os-c-c version, or an osc-lib version? | 22:37 |
| jamielennox | or anything else | 22:37 |
| *** markvoelker has quit IRC | 22:39 | |
| *** tqtran has quit IRC | 22:41 | |
| *** tqtran has joined #openstack-keystone | 22:44 | |
| *** IgorYozhikov has joined #openstack-keystone | 22:45 | |
| IgorYozhikov | Hi, I have a question about openstackclient v3.x.x | 22:45 |
| IgorYozhikov | how could help me | 22:45 |
| IgorYozhikov | I faced issues with token auth | 22:46 |
| IgorYozhikov | when I'm trying to query keystone using python-openstackclient v 3.0.0 || 3.0.1 - I see this: openstack --os-token=ADMIN --os-url=http://127.0.0.1:35357/v3 user list | 22:47 |
| IgorYozhikov | Missing parameter(s): | 22:47 |
| IgorYozhikov | Set a username with --os-username, OS_USERNAME, or auth.username | 22:47 |
| IgorYozhikov | Set an authentication URL, with --os-auth-url, OS_AUTH_URL or auth.auth_url | 22:47 |
| IgorYozhikov | and when I'm switching back to v2.6.0 - everything works fine | 22:48 |
| *** david-lyle has joined #openstack-keystone | 22:49 | |
| *** BjoernT has quit IRC | 22:52 | |
| *** david-lyle_ has quit IRC | 22:52 | |
| *** Ephur has quit IRC | 22:53 | |
| *** dkehn_ has quit IRC | 22:55 | |
| *** hockeynut has quit IRC | 23:00 | |
| *** asettle has joined #openstack-keystone | 23:02 | |
| *** david-lyle has quit IRC | 23:02 | |
| *** dkehn_ has joined #openstack-keystone | 23:08 | |
| *** asettle has quit IRC | 23:10 | |
| *** ravelar has quit IRC | 23:11 | |
| *** hockeynut has joined #openstack-keystone | 23:14 | |
| mordred | jamielennox: I don't think we need to report an os-c-c version | 23:15 |
| mordred | jamielennox: ksa seems to be the most important thing, and/or novaclient and friends if they are driving ksa | 23:15 |
| mordred | jamielennox: I could see an argument for reportin osc-lib or shade if those are driving *client | 23:16 |
| jamielennox | mordred: i thought it was being a little pedantic, it's just annoying if as soon as we start using these features someone tells me they want more stuff in it | 23:16 |
| mordred | jamielennox: although I'm obviously not passing you anything from shade at the moment to make that actually do anything | 23:16 |
| mordred | jamielennox: so .... | 23:16 |
| jamielennox | actually yea, i could see shade being useful | 23:16 |
| mordred | jamielennox: I may not be tracking teh whole thing ... what's the feature? | 23:16 |
| *** sdake has quit IRC | 23:16 | |
| jamielennox | with like an ansible version or something | 23:17 |
| mordred | yah | 23:17 |
| *** michauds has quit IRC | 23:17 | |
| jamielennox | mordred: so we've needed a better way to do user-agent generation for a while | 23:17 |
| jamielennox | https://review.openstack.org/#/c/357633/ adds a service_name, service_version to the session | 23:17 |
| mordred | oh! I see the patch | 23:17 |
| jamielennox | and a client_name, client_version in the adapter | 23:17 |
| jamielennox | clients make the adapter internally so can fill that out | 23:17 |
| jamielennox | and which ever service creates the session can fill that part out | 23:18 |
| jamielennox | then we get a useful user agent | 23:18 |
| jamielennox | i'm not a fan of sean's thing that tries to figure out the current process name from a stack | 23:18 |
| mordred | I'm not sure I'd be a fan of that either | 23:19 |
| openstackgerrit | Merged openstack/keystone: Add entrypoint for mapped auth method https://review.openstack.org/358159 | 23:19 |
| mordred | jamielennox: so - in your current patch, I assume I'd pass shade to service_name and shade.__version__ to service_version? | 23:20 |
| mordred | jamielennox: (of session) | 23:20 |
| jamielennox | yea, but shade is interesting because you might want to pass what created shade | 23:20 |
| jamielennox | my scenarios were basically to end up with nova/X glanceclient/Y keystonauth/Z | 23:21 |
| jamielennox | and openstackclient would be the same | 23:21 |
| mordred | yah - but we could end up with nodepool/X shade/Y novaclient/Z keystoneauth/bunny | 23:21 |
| jamielennox | but i want to figure out if i need to put an extensible list in there instead of just service_name, service_version | 23:21 |
| mordred | I could totally grok a desire for a stack | 23:21 |
| mordred | and also a desire for not a stack | 23:21 |
| mordred | i'm definitely interested in passing along info once there is a thing to pass it along to | 23:22 |
| mordred | I suppose you could end up with a similar thing for CLIs - osc/X osc_lib/Y novaclient/Z ksa/bunny ... and nova/X novaclient/X ksa/bunny | 23:22 |
| jamielennox | so the other thing i could do is just add an additional_user_agent list to the session and shade or whatever could add to it manually | 23:22 |
| mordred | (which would give a sense as to whether or not someone is using the nova cli or the novaclient lib) | 23:23 |
| jamielennox | right - that's my question - do we care about osc_lib version in a user-agent? or shade in the user-agent? | 23:23 |
| mordred | dunno | 23:23 |
| jamielennox | neither :) | 23:23 |
| mordred | :) | 23:23 |
| mordred | so - shade does contain logic around things, as I think does osc_lib | 23:24 |
| jamielennox | anything is better than now, just don't want to rewrite it again in a few months and have two ways to do it | 23:24 |
| mordred | so honestly information as to whether an issue is being caused by shade trying to be too smart | 23:24 |
| mordred | might be useful | 23:24 |
| mordred | "zomg why does list_servers get called so much??? oh, shade" | 23:24 |
| jamielennox | yea, but do we thing the user agent is the place for that? if you have the server version that called it and probably the originating IP would we expect ops to just go and figure this stuff out | 23:25 |
| *** tonytan4ever has quit IRC | 23:25 | |
| mordred | possibly - BUT - there's all these appdev folks writing shade things now | 23:25 |
| *** dkehn_ has quit IRC | 23:25 | |
| mordred | should their programs report "my_fun_script"? or "shade" | 23:25 |
| mordred | and then would we like to see "my_fun_script shade" and "my_other_fun_script openstacksdk"? ... like, do we learn anything? | 23:26 |
| jamielennox | probably my_fun_script | 23:26 |
| mordred | (totally just tlaking out loud) | 23:26 |
| jamielennox | i expect we'd need to make shade and osc_lib take a server_name, server_version parameter that they pass to ksa | 23:26 |
| jamielennox | but yea, at that point shade is probably a useful thing to have in the user-agent | 23:27 |
| mordred | yah | 23:27 |
| mordred | so - if we wanted to be minimal ... I could take service_name|version in shade ... and then pass along if I get something, or pass shade if I don't | 23:28 |
| mordred | so most one-off scripts would just show "shade" | 23:28 |
| mordred | but ansible and nodepool would show ansible and nodepool | 23:28 |
| mordred | since those are big enough to bother | 23:28 |
| jamielennox | so the original case for this was once we went to keystoneauth everyone just had the ksa user agent string, which meant when you had some service hammering for tokens you didn't know what it was | 23:28 |
| jamielennox | passing shade is better but still obstructs what's doing the calling | 23:29 |
| mordred | yah | 23:29 |
| mordred | I think you're selling me ona stack :) | 23:29 |
| mordred | I think there are overlapping things to learn | 23:29 |
| jamielennox | yea, i think a list as well, just need to figure out a nice way to pass that | 23:30 |
| mordred | like, shade makes a ton of calls to get extra_specs for flavors when it does a flavor list ... that's a shade excess ... not a user script nor a novaclient | 23:30 |
| mordred | so fi that was a problem for folks, seeing "my_fun_script" would not help figure out | 23:30 |
| jamielennox | i don't think you'd want to change user_agent per request, but seeing shade in there is useful | 23:31 |
| *** sdake has joined #openstack-keystone | 23:33 | |
| mordred | well, if novaclient made an adapter, and glanceclient made an adapter | 23:34 |
| mordred | and I pass shade to the session | 23:34 |
| mordred | then we should get novaclient+shade and glanceclient+shade naturally, right? | 23:34 |
| jamielennox | yea | 23:34 |
| jamielennox | i meant there's no way you would want to drop the my_fun_script part for requests that are internal to shade | 23:35 |
| mordred | oh - yeah. totally agree | 23:35 |
| mordred | that's still the originator, even if it doesn't know it | 23:35 |
| mordred | here's a weird question for you ... | 23:35 |
| mordred | (trying to pull out the most curveball thing I can) | 23:36 |
| mordred | at some point in the not too distant future we'll start replacing python*client with either sdk or just ksa adapter | 23:36 |
| mordred | but it'll be piecemeal | 23:36 |
| mordred | so I suppose that means we could have "my_fun_script shade(session) shade(adapter) ksa" | 23:37 |
| *** su_zhang has quit IRC | 23:37 | |
| mordred | and maybe that's fine? | 23:37 |
| jamielennox | i haven't looked at sdk for a while | 23:37 |
| jamielennox | both the service_name and client_name stuff are added to the user-agent if they're available | 23:38 |
| *** su_zhang has joined #openstack-keystone | 23:38 | |
| jamielennox | so you'd probably drop the adapter part if you weren't using a client | 23:38 |
| *** dkehn_ has joined #openstack-keystone | 23:38 | |
| jamielennox | but for SDK, sdk would always be the client/adapter | 23:38 |
| jamielennox | if you go direct to an adapter then using shade as the adapter would make sense | 23:39 |
| mordred | and just drop service_name in that case | 23:39 |
| jamielennox | client=adapter from a ksa sense | 23:39 |
| mordred | we should probably write a document that explains client, service, etc. :) | 23:39 |
| jamielennox | well service is probably my_fun_script which could therefore do with a better name | 23:39 |
| * mordred imagines telling someone "go read the IRC log from that chat jamielennox and I had ... | 23:40 | |
| jamielennox | and then have them try to parse the above | 23:40 |
| mordred | as long as we don't have server AND service ... | 23:40 |
| mordred | jamielennox: you could just called them "adapter_agent" and "session_agent" and "$something_agent" :) | 23:42 |
| jamielennox | well session_agent is now a list of tuples | 23:43 |
| jamielennox | though maybe we do go back to the additional_agent list and leave service_agent and service_version alone | 23:44 |
| *** Gorian|work has quit IRC | 23:44 | |
| jamielennox | i know, and will probably end up writing, the only things that would ever expect to use additional_agent | 23:44 |
| mordred | :) | 23:45 |
| jamielennox | but service_name and service_version should probably be app_name and app_version or somethign | 23:45 |
| ayoung | IgorYozhikov, sometimes the error reporting is spotty. I wonder if something else is failing and it isjust reporting the first thing, which is the username | 23:48 |
| IgorYozhikov | ayoung, I need to use token based auth and can't | 23:48 |
| IgorYozhikov | I found similar error message in a bug and add my comments there - https://bugs.launchpad.net/python-openstackclient/+bug/1615110 | 23:49 |
| openstack | Launchpad bug 1615110 in python-openstackclient "Incorrect usage message" [Undecided,New] | 23:49 |
| ayoung | IgorYozhikov, did setting OS_CLOUD work for you? | 23:52 |
| *** sdake has quit IRC | 23:55 | |
| IgorYozhikov | ayoung, it is require to setup clouds.yaml file with additional parameters including password. Also this will lead to changes in puppet code too. According to documentation using token auth method with set up OS_TOKEN and OS_URL takes precedence over authentication plugins. | 23:55 |
| ayoung | IgorYozhikov, did you find a successful way to auth? | 23:56 |
| IgorYozhikov | ayoung, frankly - no | 23:56 |
| IgorYozhikov | I switched back to 2.6.0 | 23:57 |
| IgorYozhikov | and it works fine | 23:57 |
| ayoung | IgorYozhikov, even with V3 Keystone API? | 23:57 |
| *** Marcellin_ has quit IRC | 23:57 | |
| IgorYozhikov | yep | 23:57 |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Allow specifying client and service info to user_agent https://review.openstack.org/357633 | 23:57 |
| jamielennox | mordred, stevemar, dtroyer_zz: ^^ | 23:57 |
| IgorYozhikov | openstack --os-token=ADMIN --os-url=http://127.0.0.1:35357/v3 user list -f value -c Name | 23:58 |
| IgorYozhikov | admin | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!