morgan_404 | gyee: ok done with travel | 00:02 |
---|---|---|
morgan_404 | gyee: so the only concern i have with that bike is that the wheels are 700x30c instead of 700x25c | 00:03 |
morgan_404 | it'll be a bit wider wheels so more rolling resistance | 00:03 |
morgan_404 | but probably more comfortable | 00:03 |
morgan_404 | i also don't like disc brakes | 00:03 |
morgan_404 | but i ride for different reasons | 00:04 |
morgan_404 | gyee: i also wouldn't go for a bike that has less than ultegra 105 on it | 00:04 |
morgan_404 | gyee: again personal preference | 00:05 |
jamielennox | devstack run in v3 only gate complete! | 00:07 |
jamielennox | !!!! | 00:07 |
openstack | jamielennox: Error: "!!!" is not a valid command. | 00:07 |
jamielennox | openstack: you are not a valid command | 00:07 |
richm | jamielennox: +256 | 00:07 |
jamielennox | still 108 tempest failures but at least we can start using the gate to test this stuff | 00:08 |
morgan_404 | openstack: shush | 00:08 |
gyee | morgan_404, yeah, I am concern about the disc break too | 00:09 |
morgan_404 | you probably wont ever see an issue with them | 00:09 |
gyee | higher maintenance cost too, unless I do it myself | 00:09 |
morgan_404 | but I don't like them. it also prevents me from competing atm | 00:09 |
morgan_404 | so i wont convert to them until it doesn't prevent anything | 00:10 |
gyee | they are getting better, from what I've reading | 00:11 |
*** jecarey has joined #openstack-keystone | 00:13 | |
gyee | its more of a hybrid than pure road bike | 00:13 |
morgan_404 | yeah | 00:14 |
* morgan_404 sticks to pure roadbike | 00:15 | |
*** ankita_wagh has quit IRC | 00:15 | |
* morgan_404 sighs and didn't get a ride today ... | 00:15 | |
morgan_404 | stupid expense report submission | 00:15 |
*** markvoelker has joined #openstack-keystone | 00:15 | |
gyee | yeah, EEM was finally back online, I had to get creative a couple weeks back for the boston midcycle expenses | 00:16 |
openstackgerrit | Sam Leong proposed openstack/keystone: Tokenless authz with X.509 SSL client certificate https://review.openstack.org/156870 | 00:20 |
*** markvoelker has quit IRC | 00:21 | |
mordred | morgan_404, jamielennox https://review.openstack.org/#/c/211773/1 | 00:22 |
*** shadower has quit IRC | 00:23 | |
*** shadower has joined #openstack-keystone | 00:23 | |
mordred | morgan_404: I thnik my comment about it being better in ksa is correct, but if it's not it shoudl be :) | 00:23 |
morgan_404 | hehe | 00:23 |
morgan_404 | it should be better in KSA | 00:23 |
morgan_404 | thats for sure | 00:23 |
jamielennox | eww | 00:24 |
jamielennox | why are you manually testing that? | 00:24 |
jamielennox | oh, because token_endpoint doesn't have a setuptools entrypoint in ksc | 00:25 |
jamielennox | yea, OSC camped on that name so it loads their plugin, in ksa we take it back | 00:25 |
morgan_404 | jamielennox: exactly | 00:26 |
morgan_404 | keystoneauth is *way* better | 00:26 |
morgan_404 | jamielennox: so... session loading. | 00:26 |
morgan_404 | since you're here | 00:26 |
morgan_404 | not sure how to make that one better-ish | 00:26 |
jamielennox | morgan_404: neither | 00:26 |
morgan_404 | do we need to just camp it as is? | 00:27 |
morgan_404 | i mean... i'm ok with that | 00:27 |
jamielennox | part of the reason to split plugin loading is so you're not stuck with just one way to create a plugin | 00:27 |
morgan_404 | i just get the feeling it could be better | 00:27 |
jamielennox | like there are valid reasons particularly in federation to have different options for the same plugin | 00:27 |
jamielennox | in session... | 00:27 |
jamielennox | i don't know how many ways i want people to load a session, and it's useful having it on the class because i know for example OSC overrides those class methods | 00:27 |
morgan_404 | so like i said, i'll just press "goooooo" if that is really the fix | 00:28 |
jamielennox | but if we're removing oslo.config then sessoin loading needs to be in the same place to get the opts... | 00:28 |
jamielennox | torn | 00:28 |
*** sigmavirus24 is now known as sigmavirus24_awa | 00:32 | |
jamielennox | morgan_404, mordred: commented, looks ok to me | 00:33 |
mordred | jamielennox: ossum, thanks! | 00:33 |
rodrigods | easy review: https://review.openstack.org/#/c/209057/ | 00:35 |
rodrigods | some fixes for the API spec after the merge of the Project Tree Deletion sepc | 00:35 |
*** thedodd has quit IRC | 00:39 | |
*** gyee has quit IRC | 00:40 | |
*** jasonsb has quit IRC | 00:47 | |
*** lhcheng_ has joined #openstack-keystone | 00:49 | |
*** lhcheng has quit IRC | 00:52 | |
*** richm has quit IRC | 00:53 | |
*** roxanaghe has quit IRC | 00:54 | |
*** josecastroleon has quit IRC | 00:56 | |
*** boris-42 has quit IRC | 00:58 | |
*** flwang has quit IRC | 00:59 | |
*** flwang has joined #openstack-keystone | 01:00 | |
*** boris-42 has joined #openstack-keystone | 01:00 | |
*** richm has joined #openstack-keystone | 01:03 | |
*** chlong has joined #openstack-keystone | 01:03 | |
*** drjones has quit IRC | 01:11 | |
*** lhcheng_ has quit IRC | 01:25 | |
*** piyanai has joined #openstack-keystone | 01:27 | |
*** ayoung has quit IRC | 01:27 | |
jamielennox | morgan_404: are we sure that auth_token still does an in-memory cache if memcache isn't configured? | 01:41 |
morgan_404 | yes | 01:41 |
morgan_404 | at least afaik that hasn't changed | 01:41 |
morgan_404 | sec.. le tme find it | 01:41 |
jamielennox | morgan_404: oh, right found it | 01:42 |
jamielennox | it's an oslo thing | 01:42 |
morgan_404 | yeah | 01:42 |
morgan_404 | memorycache | 01:42 |
jamielennox | i guess it made sense with eventlet | 01:47 |
morgan_404 | sortof | 01:53 |
morgan_404 | even there not really | 01:53 |
morgan_404 | once worker eventlet maybe. | 01:53 |
openstackgerrit | Dave Chen proposed openstack/keystone: Fix the misspelling https://review.openstack.org/211876 | 01:59 |
*** fangzhou has quit IRC | 02:02 | |
*** markvoelker has joined #openstack-keystone | 02:05 | |
*** woodster_ has quit IRC | 02:10 | |
*** piyanai has quit IRC | 02:12 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/212253 | 02:13 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystoneauth: Updated from global requirements https://review.openstack.org/212254 | 02:13 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystoneauth-saml2: Updated from global requirements https://review.openstack.org/210893 | 02:13 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/212255 | 02:13 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/oslo.policy: Updated from global requirements https://review.openstack.org/212270 | 02:18 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/pycadf: Updated from global requirements https://review.openstack.org/212274 | 02:18 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/212275 | 02:18 |
*** piyanai has joined #openstack-keystone | 02:22 | |
*** jecarey has quit IRC | 02:26 | |
*** zzzeek has quit IRC | 02:27 | |
*** jecarey has joined #openstack-keystone | 02:28 | |
*** mylu has quit IRC | 02:36 | |
*** stevemar has joined #openstack-keystone | 02:46 | |
*** ChanServ sets mode: +v stevemar | 02:46 | |
*** stevemar has quit IRC | 02:49 | |
jamielennox | morgan_404: damnit, now i know way too much about how auth_token handles memcache | 02:49 |
*** stevemar_ has joined #openstack-keystone | 02:49 | |
*** ChanServ sets mode: +v stevemar_ | 02:49 | |
jamielennox | it's horrible | 02:49 |
*** jasonsb has joined #openstack-keystone | 02:50 | |
*** hakimo_ has joined #openstack-keystone | 02:52 | |
*** elmiko has quit IRC | 02:53 | |
*** hakimo has quit IRC | 02:54 | |
*** ankita_wagh has joined #openstack-keystone | 02:55 | |
jamielennox | stevemar_: have you seen https://bugs.launchpad.net/keystone/+bug/1482772 it may be something worth handling in OSC in the mean time | 02:56 |
openstack | Launchpad bug 1482772 in Keystone "Region filtering for endpoints does not work" [Medium,Confirmed] - Assigned to Lin Hua Cheng (lin-hua-cheng) | 02:56 |
jamielennox | python-memcached 1.56 release 17 days ago has python 3 support and is in global requirements | 03:06 |
morgan_404 | jamielennox: why do you think I hate that code so much :( | 03:23 |
jamielennox | i never knew... | 03:24 |
morgan_404 | I tried to save you. | 03:24 |
morgan_404 | You went for it anyway :P | 03:24 |
morgan_404 | The whole crypto thing is insane too | 03:24 |
morgan_404 | I should just rip that out and go to dogpile and make the crypto thing a proxy (dogpile lets you later proxies in seamlessly) | 03:25 |
jamielennox | right, it's a disaster - i wonder if anyone uses it? | 03:27 |
jamielennox | why would you crypt your memcache? | 03:27 |
jamielennox | is that a thing? | 03:28 |
morgan_404 | Swift | 03:31 |
morgan_404 | It is a swift thing | 03:31 |
jamielennox | morgan_404: so most of our caching tests are designed around memory cache) | 03:32 |
morgan_404 | Yep | 03:33 |
morgan_404 | It has always been unfun/unfriendly and just icky | 03:33 |
jamielennox | so yesterday, when you were saying just go remove the memory cache instead and implying it was easy - that was a lie | 03:34 |
*** ankita_wagh has quit IRC | 03:37 | |
*** piyanai has quit IRC | 03:43 | |
*** mylu has joined #openstack-keystone | 03:53 | |
openstackgerrit | Merged openstack/keystone: Give some message when an invalid token is in use https://review.openstack.org/199989 | 03:57 |
*** mylu has quit IRC | 03:58 | |
*** lhcheng has joined #openstack-keystone | 03:59 | |
*** ChanServ sets mode: +v lhcheng | 03:59 | |
*** richm has quit IRC | 04:04 | |
*** stevemar_ has quit IRC | 04:07 | |
openstackgerrit | Merged openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/212255 | 04:09 |
*** hrou has joined #openstack-keystone | 04:13 | |
morgan_404 | >.> | 04:14 |
*** hrou has quit IRC | 04:19 | |
*** hrou has joined #openstack-keystone | 04:19 | |
openstackgerrit | Merged openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/212275 | 04:26 |
*** Ephur has quit IRC | 04:36 | |
openstackgerrit | Merged openstack/pycadf: Updated from global requirements https://review.openstack.org/212274 | 04:37 |
openstackgerrit | Merged openstack/keystone: Updated from global requirements https://review.openstack.org/212253 | 04:48 |
*** hrou has quit IRC | 04:48 | |
anteaya | hey | 05:00 |
anteaya | so cryptography 1.0 was released yesterday, the 12th | 05:01 |
anteaya | has anyone in here fired up a keystone with it yet? | 05:01 |
anteaya | morgan_404: ^^ if you are still around | 05:02 |
anteaya | jamielennox: too | 05:02 |
anteaya | you might be up | 05:02 |
morgan_404 | anteaya: eating füds | 05:02 |
anteaya | ah | 05:02 |
anteaya | a must do thing | 05:02 |
anteaya | enjoy | 05:02 |
morgan_404 | But no haven't tried with new crypto lib | 05:02 |
jamielennox | anteaya: i saw the notice it had been released | 05:02 |
anteaya | okay thanks | 05:02 |
anteaya | jamielennox: do you have time to try it with keystone? | 05:03 |
morgan_404 | Gate didn't explode afaict | 05:03 |
anteaya | well we are running on images | 05:03 |
morgan_404 | That is a good thing? Or is it capped? | 05:03 |
morgan_404 | Ahhhhh | 05:03 |
jamielennox | anteaya: i don't know what we're using it for | 05:03 |
anteaya | some third party cis that don't have all gone bust | 05:03 |
jamielennox | oh fernet | 05:03 |
anteaya | yeah fernet | 05:03 |
morgan_404 | Oh hah fernets | 05:03 |
anteaya | might be nothing | 05:03 |
*** davechen has joined #openstack-keystone | 05:03 | |
anteaya | but might splode the gate when images refresh | 05:04 |
morgan_404 | I can try when I get home | 05:04 |
jamielennox | i can give it a run but fernet is really high level stuff that hasn't changed in a while, i don't expect any difference | 05:04 |
anteaya | thanks | 05:04 |
morgan_404 | But it'll be a couple hours | 05:04 |
anteaya | we have about 9 hours before images refresh | 05:04 |
anteaya | would be nice to at least say keystone works with 1.0 | 05:04 |
morgan_404 | Fernet shouldn't cause issues here though. Unless they totally screwed their contract up | 05:04 |
anteaya | like I said, might be nothing | 05:05 |
morgan_404 | We don't dig in under to the primatives. | 05:05 |
morgan_404 | Where I'd expect breakage | 05:05 |
anteaya | but something is causing some third party ci images to go boom | 05:05 |
anteaya | and so far cryptography is new | 05:05 |
morgan_404 | Got an example of the error? | 05:05 |
anteaya | that is as much as I have | 05:05 |
morgan_404 | I can look at the trace back and probably tell you pretty quickly | 05:05 |
anteaya | in -infra, jgriffith and I were talking | 05:05 |
jamielennox | anteaya: i don't think fernet is the default anyway so it shouldn't have an affect on third party ci | 05:05 |
morgan_404 | Fernet is not on in devstack | 05:06 |
anteaya | http://54.164.167.86/solidfire-ci-logs/refs-changes-47-212247-1/stack.sh.log.out | 05:06 |
anteaya | oh | 05:06 |
jamielennox | right, was going to spin up a devstack but wasn't sure how to even enable it | 05:06 |
anteaya | it is a devstack issue | 05:06 |
anteaya | jamielennox: can you spin up a devstack? | 05:06 |
anteaya | he is failing on stack.sh | 05:06 |
anteaya | when keystone is enabled | 05:06 |
anteaya | can you see what you experience? | 05:06 |
anteaya | I know I should be doing this myself | 05:07 |
jamielennox | anteaya: ok, i'll start from scratch | 05:07 |
anteaya | been so long since I spun up anything | 05:07 |
anteaya | thanks | 05:07 |
*** stevemar has joined #openstack-keystone | 05:08 | |
*** ChanServ sets mode: +v stevemar | 05:08 | |
morgan_404 | Ok i've seen this before its usually an associated thing not keystone directly. It could also be some odd devstack + syntax change in somethig else. | 05:08 |
morgan_404 | I'll need to poke the logs a bit more. See if I can do it from teh mobile | 05:08 |
morgan_404 | Oh they dont publish the screens :( | 05:09 |
morgan_404 | That doesn't help. | 05:09 |
jamielennox | 2015-08-13 03:21:42.119 | + export OS_TOKEN=111222333444 | 05:10 |
jamielennox | 2015-08-13 03:21:42.119 | + OS_TOKEN=111222333444 | 05:10 |
jamielennox | 2015-08-13 03:21:42.119 | + export OS_URL=http://127.0.0.1:35357/v2.0 | 05:10 |
jamielennox | 2015-08-13 03:21:42.119 | + OS_URL=http://127.0.0.1:35357/v2.0 | 05:10 |
jamielennox | 2015-08-13 03:21:42.119 | + create_keystone_accounts | 05:10 |
jamielennox | 2015-08-13 03:21:42.120 | ++ get_or_create_project admin default | 05:10 |
jamielennox | 2015-08-13 03:21:42.120 | ++ local project_id | 05:10 |
jamielennox | 2015-08-13 03:21:42.121 | +++ openstack --os-url=http://127.0.0.1:5000/v3 --os-identity-api-version=3 project create admin --domain=default --or-show -f value -c id | 05:10 |
jamielennox | 2015-08-13 03:21:42.779 | ERROR: openstack Missing parameter(s): | 05:10 |
jamielennox | 2015-08-13 03:21:42.779 | Set a service URL, with --os-url, OS_URL or auth.url | 05:10 |
jamielennox | so that looks like the first errror - and that's just weird | 05:10 |
anteaya | jamielennox: you get the same error | 05:10 |
anteaya | yay | 05:10 |
jamielennox | anteaya: no, looking at your log | 05:10 |
morgan_404 | jamielennox: Set a service URL, with --os-url, OS_URL or auth.url yeah | 05:10 |
jamielennox | that'll take a while | 05:10 |
anteaya | oh | 05:10 |
anteaya | and yeah, totally weird error | 05:11 |
morgan_404 | Wonder if something in keystonebootatrap changed | 05:11 |
*** stevemar has quit IRC | 05:11 | |
anteaya | first time it happens is when enabling keystone, so I'm in here | 05:11 |
jamielennox | internal cloud instance says "unable to schedule new instance" - so that cloud's out | 05:11 |
morgan_404 | And they just refreshed their devstack itself | 05:11 |
*** davechen1 has joined #openstack-keystone | 05:13 | |
*** vivekd has joined #openstack-keystone | 05:13 | |
anteaya | maybe? | 05:14 |
jamielennox | anteaya: actually OSC just had a release | 05:14 |
anteaya | oh | 05:14 |
anteaya | john said they didn't so I didn't look | 05:14 |
jamielennox | stevemar was planning it for yesterday at least | 05:14 |
*** davechen has quit IRC | 05:15 | |
jamielennox | 2015-08-11 | 05:15 |
anteaya | 38 hours ago | 05:15 |
jamielennox | so yesterday-ish depending on timezone | 05:15 |
anteaya | this error cropped up in the last 3 hours | 05:15 |
anteaya | looks like the timestamps in the log is utc time | 05:16 |
jamielennox | anteaya: it wouldn't have popped up in devstack until the requirements change merged to allow it: https://review.openstack.org/#/c/210988/3 | 05:17 |
anteaya | it was passing earlier: http://54.164.167.86/solidfire-ci-logs/refs-changes-04-211804-3/stack.sh.log.out | 05:17 |
* jamielennox learnt this the hard way yesterday | 05:17 | |
anteaya | jamielennox: oh | 05:17 |
jamielennox | so that's like still 19 hours | 05:18 |
anteaya | that still merged about 18 hours ago | 05:18 |
anteaya | yeah | 05:18 |
anteaya | round there | 05:18 |
anteaya | but thanks I didn't know that about the requirements change | 05:18 |
jamielennox | don't trust my maths | 05:18 |
anteaya | it is more than 5 hours | 05:19 |
anteaya | which takes us out of the window of change | 05:19 |
jamielennox | sure, but if this is third party i assume there's some pip caching | 05:19 |
anteaya | true | 05:19 |
anteaya | jgriffith is offline right now, so I don't know what caching he has going on | 05:20 |
anteaya | at least if you have a successful run we know it isn't crypto 1.0 | 05:20 |
anteaya | I think | 05:20 |
jamielennox | anteaya: i'm doubting it's crypto | 05:21 |
anteaya | good | 05:21 |
*** davechen has joined #openstack-keystone | 05:25 | |
*** davechen1 has quit IRC | 05:28 | |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Handle memcache pool arguments collectively https://review.openstack.org/212341 | 05:30 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Create Environment cache pool https://review.openstack.org/212342 | 05:30 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Import _memcache_pool normally https://review.openstack.org/212343 | 05:30 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Seperate standalone cache tests https://review.openstack.org/212344 | 05:30 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Disable memory caching of tokens https://review.openstack.org/212345 | 05:30 |
jamielennox | morgan_404: ^ | 05:30 |
jamielennox | oo, File "/usr/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 11, in <module> | 05:31 |
jamielennox | from cryptography.hazmat.bindings._openssl import ffi, lib | 05:31 |
jamielennox | AttributeError: 'module' object has no attribute '_init_cffi_1_0_external_module' | 05:31 |
jamielennox | that's a crypotgraphy issue | 05:31 |
anteaya | :( | 05:31 |
anteaya | that is from your devstack run? | 05:32 |
*** hafe has quit IRC | 05:32 | |
jamielennox | yes | 05:32 |
*** hafe has joined #openstack-keystone | 05:32 | |
jamielennox | it seems to be coming from a horizon manage command though | 05:32 |
jamielennox | no, i can't import OpenSSL from python | 05:33 |
anteaya | is this an openssl issue? | 05:33 |
anteaya | sorry I should just wait and let you share when you have something | 05:34 |
jamielennox | anteaya: i didn't log the devstack run, so http://paste.openstack.org/show/412820/ is as much trace as i have | 05:35 |
jamielennox | which is at least plenty to see this issue | 05:35 |
anteaya | well if it is an issue, it is reproducable, yeah? | 05:35 |
anteaya | what are you thinking? | 05:35 |
jamielennox | no idea atm, i've never really dived into how cffi works | 05:37 |
anteaya | is this something we can ask about in cryptography-dev? | 05:37 |
anteaya | because _I_ have no idea | 05:38 |
jamielennox | anteaya: that's my next guess | 05:38 |
anteaya | we == you in this case | 05:38 |
anteaya | I'm in that channel if you are willing to post a question | 05:39 |
anteaya | thanks | 05:39 |
*** markvoelker has quit IRC | 05:41 | |
anteaya | 0.9.3 was the cryptography version just prior to 1.0 | 05:44 |
anteaya | I'm going to offer a patch to requirements to pin it at 0.9.3 | 05:44 |
anteaya | jamielennox: thoughts? | 05:44 |
*** fifieldt has joined #openstack-keystone | 05:49 | |
morgan_404 | Icky :( | 05:49 |
morgan_404 | Safe is to cap at 0.9.3. | 05:49 |
*** med_ has quit IRC | 05:50 | |
morgan_404 | Of the req is proposed it can be abandoned if needed but it gets the gates running on it. | 05:50 |
morgan_404 | If* not of | 05:50 |
morgan_404 | jamielennox: can you try with 0.9.3 of crypto? | 05:51 |
morgan_404 | If it doesnt break that way we know crypto did a bad bad thing | 05:51 |
jamielennox | morgan_404, anteaya: so if i downgrade cryptography to <1.0 then i can at least import OpenSSL | 05:51 |
jamielennox | however something crazy is happening with pip caching | 05:51 |
morgan_404 | Ok sounds like we need a pin. | 05:51 |
morgan_404 | Erm cap | 05:51 |
jamielennox | i had to install a specific cffi to get it to work | 05:52 |
jamielennox | and now i can't upgrade again | 05:52 |
morgan_404 | *blink* | 05:52 |
morgan_404 | wtf? | 05:52 |
morgan_404 | Cliff released on monday | 05:53 |
anteaya | working on patches, I posted in infra asking about the order | 05:53 |
anteaya | cap is a better word then pin? | 05:53 |
*** Nirupama has joined #openstack-keystone | 05:53 | |
* anteaya edits the commit message | 05:53 | |
morgan_404 | Pin i think is == thisexactversion | 05:53 |
morgan_404 | Cap is "less than x" | 05:53 |
morgan_404 | In my mind | 05:54 |
jamielennox | http://paste.openstack.org/show/412821/ | 05:54 |
morgan_404 | Cliff shouldnt affect this though. | 05:54 |
jamielennox | i've no idea what's happening there | 05:54 |
jamielennox | somewhere there is a precompiled object with a different version of cffi and they are having a bad interaction | 05:55 |
jamielennox | but at this point i'm thinking i just kill the vm | 05:55 |
morgan_404 | Ugh :( | 05:55 |
openstackgerrit | Anita Kuno proposed openstack/keystone: Cap cryptography to less than 1.0 https://review.openstack.org/212353 | 06:03 |
*** ParsectiX has joined #openstack-keystone | 06:04 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex https://review.openstack.org/212359 | 06:10 |
*** hafe has quit IRC | 06:18 | |
*** vivekd has quit IRC | 06:18 | |
*** med_ has joined #openstack-keystone | 06:23 | |
*** med_ is now known as Guest471 | 06:23 | |
*** afazekas has joined #openstack-keystone | 06:40 | |
*** markvoelker has joined #openstack-keystone | 06:41 | |
*** rdo has quit IRC | 06:42 | |
openstackgerrit | Eric Brown proposed openstack/keystone: Utilize min and max of oslo.config https://review.openstack.org/212373 | 06:42 |
*** rdo has joined #openstack-keystone | 06:43 | |
*** Guest471 has quit IRC | 06:44 | |
openstackgerrit | Merged openstack/keystone-specs: Fix nits from Project Tree Deletion spec https://review.openstack.org/209057 | 06:45 |
*** markvoelker has quit IRC | 06:46 | |
*** yottatsa has joined #openstack-keystone | 06:49 | |
*** lhcheng has quit IRC | 06:58 | |
*** med_ has joined #openstack-keystone | 07:15 | |
*** med_ is now known as Guest61394 | 07:15 | |
*** fifieldt has quit IRC | 07:17 | |
*** e0ne has joined #openstack-keystone | 07:17 | |
*** browne has quit IRC | 07:20 | |
*** charz has quit IRC | 07:22 | |
*** mtreinish has quit IRC | 07:24 | |
*** therve has quit IRC | 07:25 | |
*** therve has joined #openstack-keystone | 07:25 | |
*** dguerri` is now known as dguerri | 07:26 | |
*** henrynash has joined #openstack-keystone | 07:26 | |
*** ChanServ sets mode: +v henrynash | 07:26 | |
*** charz has joined #openstack-keystone | 07:27 | |
*** mtreinish has joined #openstack-keystone | 07:27 | |
*** henrynash has quit IRC | 07:28 | |
*** dguerri is now known as dguerri` | 07:31 | |
*** e0ne has quit IRC | 07:41 | |
*** shadower has quit IRC | 07:41 | |
*** haneef_ has quit IRC | 07:41 | |
*** tellesnobrega_af has quit IRC | 07:41 | |
*** alex_xu has quit IRC | 07:41 | |
*** openstackgerrit has quit IRC | 07:41 | |
*** akscram has quit IRC | 07:41 | |
*** nonameentername has quit IRC | 07:41 | |
*** hogepodge has quit IRC | 07:41 | |
*** csd has quit IRC | 07:41 | |
*** crinkle has quit IRC | 07:41 | |
*** _fortis has quit IRC | 07:41 | |
*** Kiall has quit IRC | 07:41 | |
*** timburke has quit IRC | 07:41 | |
*** devananda has quit IRC | 07:41 | |
*** rmstar has quit IRC | 07:41 | |
*** ParsectiX has quit IRC | 07:41 | |
*** henrynash has joined #openstack-keystone | 07:42 | |
*** ChanServ sets mode: +v henrynash | 07:42 | |
*** hughsaunders has quit IRC | 07:42 | |
*** shadower has joined #openstack-keystone | 07:43 | |
*** haneef_ has joined #openstack-keystone | 07:43 | |
*** tellesnobrega_af has joined #openstack-keystone | 07:43 | |
*** alex_xu has joined #openstack-keystone | 07:43 | |
*** openstackgerrit has joined #openstack-keystone | 07:43 | |
*** akscram has joined #openstack-keystone | 07:43 | |
*** nonameentername has joined #openstack-keystone | 07:43 | |
*** hogepodge has joined #openstack-keystone | 07:43 | |
*** csd has joined #openstack-keystone | 07:43 | |
*** crinkle has joined #openstack-keystone | 07:43 | |
*** _fortis has joined #openstack-keystone | 07:43 | |
*** Kiall has joined #openstack-keystone | 07:43 | |
*** timburke has joined #openstack-keystone | 07:43 | |
*** devananda has joined #openstack-keystone | 07:43 | |
*** rmstar has joined #openstack-keystone | 07:43 | |
*** _fortis has quit IRC | 07:44 | |
*** crinkle_ has joined #openstack-keystone | 07:44 | |
*** csd has quit IRC | 07:45 | |
*** shadower has quit IRC | 07:45 | |
*** alex_xu has quit IRC | 07:45 | |
*** openstackgerrit has quit IRC | 07:45 | |
*** akscram has quit IRC | 07:45 | |
*** nonameentername has quit IRC | 07:45 | |
*** devananda has quit IRC | 07:45 | |
*** rmstar has quit IRC | 07:45 | |
*** hafe has joined #openstack-keystone | 07:45 | |
*** haneef_ has quit IRC | 07:46 | |
*** tellesnobrega_af has quit IRC | 07:46 | |
*** hogepodge has quit IRC | 07:46 | |
*** crinkle has quit IRC | 07:46 | |
*** Kiall has quit IRC | 07:46 | |
*** timburke has quit IRC | 07:46 | |
*** hughsaunders has joined #openstack-keystone | 07:47 | |
*** devananda has joined #openstack-keystone | 07:47 | |
*** rmstar has joined #openstack-keystone | 07:47 | |
*** yottatsa has quit IRC | 07:47 | |
*** Kiall has joined #openstack-keystone | 07:48 | |
*** tellesnobrega has joined #openstack-keystone | 07:50 | |
*** alex_xu has joined #openstack-keystone | 07:51 | |
*** csd has joined #openstack-keystone | 07:52 | |
*** nonameentername has joined #openstack-keystone | 07:52 | |
*** timburke has joined #openstack-keystone | 07:55 | |
*** rm_work is now known as rm_work|away | 07:56 | |
*** rm_work|away is now known as rm_work | 07:58 | |
*** akscram has joined #openstack-keystone | 07:58 | |
*** haneef_ has joined #openstack-keystone | 07:58 | |
*** openstackgerrit has joined #openstack-keystone | 08:00 | |
*** rm_work is now known as rm_work|away | 08:00 | |
*** _fortis has joined #openstack-keystone | 08:00 | |
*** shadower has joined #openstack-keystone | 08:00 | |
*** rm_work|away is now known as rm_work | 08:03 | |
*** ParsectiX has joined #openstack-keystone | 08:08 | |
*** fhubik has joined #openstack-keystone | 08:11 | |
*** chlong has quit IRC | 08:13 | |
*** Kennan has quit IRC | 08:14 | |
*** fhubik is now known as fhubik_brb | 08:14 | |
*** fhubik_brb is now known as fhubik | 08:19 | |
*** Kennan has joined #openstack-keystone | 08:21 | |
*** katkapilatova has joined #openstack-keystone | 08:23 | |
*** katkapilatova has left #openstack-keystone | 08:24 | |
*** katkapilatova has joined #openstack-keystone | 08:24 | |
*** rdo has quit IRC | 08:24 | |
*** rm_work is now known as rm_work|away | 08:25 | |
*** rm_work|away is now known as rm_work | 08:25 | |
*** jistr has joined #openstack-keystone | 08:26 | |
*** rm_work is now known as rm_work|away | 08:28 | |
*** rm_work|away is now known as rm_work | 08:29 | |
*** knl has joined #openstack-keystone | 08:29 | |
*** yottatsa has joined #openstack-keystone | 08:35 | |
*** rdo has joined #openstack-keystone | 08:38 | |
*** crinkle_ is now known as crinkle | 08:41 | |
*** ankita_wagh has joined #openstack-keystone | 08:42 | |
*** markvoelker has joined #openstack-keystone | 08:43 | |
*** hogepodge has joined #openstack-keystone | 08:43 | |
knl | hi all, I think that bug https://bugs.launchpad.net/keystone/+bug/1054362?comments=all resurfaced again, and is not a duplicate of the reported bug | 08:47 |
openstack | Launchpad bug 1057436 in Keystone "duplicate for #1054362 Delete role does not delete roles assignment in tenants" [High,Fix released] - Assigned to Jose Castro Leon (jose-castro-leon) | 08:47 |
*** markvoelker has quit IRC | 08:47 | |
knl | we recently upgraded to kilo and started seeing this behavirour, which didn't exist in icehouse | 08:48 |
knl | could anyone confirm? | 08:48 |
*** yottatsa has quit IRC | 08:49 | |
openstackgerrit | Dave Chen proposed openstack/keystone: Show helpful message when request body is not provided https://review.openstack.org/195903 | 08:51 |
*** davechen has left #openstack-keystone | 08:53 | |
rodrigods | henrynash, can you check the replies in https://review.openstack.org/#/c/157427/? | 08:53 |
*** stevemar has joined #openstack-keystone | 09:09 | |
*** ChanServ sets mode: +v stevemar | 09:09 | |
*** stevemar has quit IRC | 09:12 | |
*** rodrigods has quit IRC | 09:13 | |
*** rodrigods has joined #openstack-keystone | 09:13 | |
*** navid__ has joined #openstack-keystone | 09:18 | |
*** navid___ has joined #openstack-keystone | 09:22 | |
*** navid__ has quit IRC | 09:27 | |
*** navid___ has quit IRC | 09:27 | |
henrynash | rodigods: will be doing so in an hour or os | 09:27 |
*** navid__ has joined #openstack-keystone | 09:27 | |
*** navid__ has quit IRC | 09:31 | |
*** navid__ has joined #openstack-keystone | 09:32 | |
*** ankita_wagh has quit IRC | 09:41 | |
*** ali_ has joined #openstack-keystone | 09:41 | |
*** ali_ has quit IRC | 09:42 | |
*** henrynash has quit IRC | 09:44 | |
*** navid__ has quit IRC | 09:45 | |
*** navid__ has joined #openstack-keystone | 09:46 | |
*** navid__ has quit IRC | 09:47 | |
*** Navid__ has joined #openstack-keystone | 09:48 | |
knl | I see in etc/keystone.conf.sample that a lot of options in [ldap] section is deprecated. Is there any document that explains why, and what will be the replacements? | 09:48 |
*** fhubik is now known as fhubik_brb | 09:58 | |
*** boris-42 has quit IRC | 10:00 | |
*** Navid__ has quit IRC | 10:01 | |
*** Navidp has joined #openstack-keystone | 10:01 | |
*** fhubik_brb is now known as fhubik | 10:05 | |
*** navid_ has quit IRC | 10:23 | |
*** Navidp is now known as navid_ | 10:23 | |
navid_ | /nick navid | 10:25 |
breton | folks, I am concerned about https://review.openstack.org/#/c/208069/7 | 10:33 |
breton | it broke heat and I wonder what impact it had on multiple backends for domains | 10:35 |
*** yottatsa has joined #openstack-keystone | 10:37 | |
breton | when we use multiple backends for domain, service users are in default domain, human users in non-default domain. Human user gets a token and it will not be validated by any component who still cannot use keystone v3 | 10:37 |
*** markvoelker has joined #openstack-keystone | 10:43 | |
*** markvoelker has quit IRC | 10:48 | |
*** claudiub has joined #openstack-keystone | 10:51 | |
*** chlong has joined #openstack-keystone | 11:04 | |
*** stevemar has joined #openstack-keystone | 11:10 | |
*** ChanServ sets mode: +v stevemar | 11:10 | |
*** stevemar has quit IRC | 11:14 | |
*** fhubik is now known as fhubik_brb | 11:25 | |
*** dikonoor has joined #openstack-keystone | 11:30 | |
*** dikonoo has joined #openstack-keystone | 11:30 | |
*** shunliz has joined #openstack-keystone | 11:31 | |
*** dikonoor has quit IRC | 11:33 | |
*** ParsectiX has quit IRC | 11:33 | |
*** annasort has quit IRC | 11:42 | |
*** markvoelker has joined #openstack-keystone | 11:44 | |
*** fhubik_brb is now known as fhubik | 11:45 | |
*** markvoelker has quit IRC | 11:49 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Create unit tests for endpoint policy SQL driver https://review.openstack.org/212006 | 11:50 |
*** marzif has joined #openstack-keystone | 11:51 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Fixes query.one() return usage in endpoint-policy https://review.openstack.org/208609 | 11:52 |
*** markvoelker has joined #openstack-keystone | 11:53 | |
openstackgerrit | Paweł Pamuła proposed openstack/keystone: IdP deletion triggers token revocation https://review.openstack.org/210456 | 11:55 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Enable Cache-Control HTTP values in responses https://review.openstack.org/211271 | 11:55 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Create Cached Policy Table https://review.openstack.org/211679 | 11:57 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Centralized Policies Distribution Mechanism https://review.openstack.org/209695 | 11:57 |
*** mylu has joined #openstack-keystone | 12:00 | |
*** knl has quit IRC | 12:02 | |
*** piyanai has joined #openstack-keystone | 12:03 | |
*** mylu has quit IRC | 12:09 | |
*** gordc has joined #openstack-keystone | 12:13 | |
*** annasort has joined #openstack-keystone | 12:30 | |
*** annasort_ has joined #openstack-keystone | 12:31 | |
*** topol has joined #openstack-keystone | 12:32 | |
*** ChanServ sets mode: +v topol | 12:32 | |
*** annasort has quit IRC | 12:35 | |
*** annasort_ is now known as annasort | 12:35 | |
*** yottatsa has quit IRC | 12:50 | |
*** jsavak has joined #openstack-keystone | 12:50 | |
*** gordc has quit IRC | 12:51 | |
*** piyanai has quit IRC | 12:52 | |
*** fhubik is now known as fhubik_brb | 12:53 | |
*** richm has joined #openstack-keystone | 12:54 | |
*** doug-fish has joined #openstack-keystone | 12:54 | |
*** Nirupama has quit IRC | 12:55 | |
*** bapalm has joined #openstack-keystone | 12:55 | |
*** richm has quit IRC | 12:56 | |
*** richm has joined #openstack-keystone | 12:56 | |
*** bapalm__ has joined #openstack-keystone | 12:57 | |
samueldmq | breton, I think the response is in your question | 12:57 |
samueldmq | breton, if one wants to use multiple identity backends, this implies in multiples domains | 12:58 |
samueldmq | breton, if multiple domains is required, v3 must be used | 12:58 |
samueldmq | breton, :) | 12:58 |
*** bapalm___ has joined #openstack-keystone | 12:58 | |
*** jecarey has quit IRC | 12:58 | |
*** bapalm has quit IRC | 12:59 | |
*** openstackgerrit has quit IRC | 13:01 | |
*** bapalm__ has quit IRC | 13:01 | |
samueldmq | dolphm, I will likely need to add unit tests to /policy as well, besides /endpoint_policy | 13:02 |
*** fhubik_brb is now known as fhubik | 13:02 | |
samueldmq | dolphm, should I create a bp for them? | 13:02 |
*** openstackgerrit has joined #openstack-keystone | 13:02 | |
breton | samueldmq: it is not possible to use v3 everywhere now. | 13:03 |
*** mestery has quit IRC | 13:03 | |
dolphm | samueldmq: a bp to write tests? absolutely not | 13:03 |
samueldmq | dolphm, just a bug then? it's not likely a bug as well | 13:04 |
samueldmq | dolphm, I am just worried on how to target them | 13:04 |
samueldmq | dolphm, maybe nothing at all? just proposing them? | 13:04 |
dolphm | samueldmq: things that have zero impact on end users do not need to be tracked in bugs or blueprints (tests, refactors, docstr changes, etc) | 13:04 |
*** edmondsw has joined #openstack-keystone | 13:05 | |
*** topol has quit IRC | 13:05 | |
dolphm | samueldmq: if the audience for your patch is only developers, then gerrit provides all the tracking we need | 13:05 |
samueldmq | dolphm, makes sense, except in special cases where the change is complex and we need a spec (and then a bp?) | 13:05 |
*** bapalm___ has quit IRC | 13:05 | |
samueldmq | dolphm, but that isn't the case | 13:05 |
dolphm | samueldmq: when the change is complex, break it down into digestible patches so that it can be easily reviewed | 13:06 |
samueldmq | dolphm, ++ | 13:06 |
samueldmq | dolphm, all the tracking on lp is used is to generate the release notes? | 13:07 |
dolphm | samueldmq: we land complicated multi-step refactors all the time... as long as they're broken down into multiple digestible patches | 13:07 |
dolphm | samueldmq: yes | 13:07 |
dolphm | samueldmq: Wishlist bugs and blueprints feed directly into release notes | 13:07 |
samueldmq | dolphm, nice, so what you said makes sense to me | 13:07 |
samueldmq | dolphm, makes sense (yes, I worked on the release notes with you last cycle) | 13:08 |
samueldmq | dolphm, that's why that question :) | 13:08 |
openstackgerrit | Marianne Linhares Monteiro proposed openstack/keystone: List credentials by type https://review.openstack.org/208620 | 13:09 |
samueldmq | dolphm, thanks for the clarifications | 13:09 |
*** stevemar has joined #openstack-keystone | 13:11 | |
*** ChanServ sets mode: +v stevemar | 13:11 | |
*** mestery has joined #openstack-keystone | 13:12 | |
*** henrynash has joined #openstack-keystone | 13:12 | |
*** ChanServ sets mode: +v henrynash | 13:12 | |
*** atiwari1 has joined #openstack-keystone | 13:13 | |
*** atiwari has quit IRC | 13:14 | |
*** stevemar has quit IRC | 13:15 | |
dstanek | dolphm: i have a question about that EC2 crud when you have sec | 13:19 |
*** bebech has joined #openstack-keystone | 13:24 | |
breton | I guess yesterdays's change broke a lot of things. | 13:24 |
dstanek | breton: ? | 13:26 |
dstanek | samueldmq: if your cache policy table for auditing? | 13:26 |
*** bebech has quit IRC | 13:27 | |
samueldmq | dstanek, auditing isn't the initial intention | 13:28 |
dstanek | what is the intention then? | 13:28 |
samueldmq | dstanek, since I need to deliver a version of the policy for the next {policy_timeout} seconds | 13:28 |
samueldmq | dstanek, I store a copy at the start time, and deliver the copy in the policy_cache table | 13:28 |
samueldmq | dstanek, so endpoint processes coming at different times always get the same policy | 13:28 |
samueldmq | dstanek, even if updates in the policy occur in the meantime | 13:29 |
*** browne has joined #openstack-keystone | 13:30 | |
dstanek | ok, we are super paranoid here :-) | 13:31 |
breton | dstanek: https://bugs.launchpad.net/keystone/+bug/1484086 . After the patch mentioned there I suddenly see a lot of discussion of EC2 | 13:31 |
openstack | Launchpad bug 1484086 in Keystone "ec2tokens authentication is failing during Heat tests" [Undecided,New] | 13:31 |
*** jsavak has quit IRC | 13:31 | |
breton | (maybe it's just a coincident) | 13:31 |
samueldmq | dstanek, hehe, remember the meantime can be long (5 minutes), and it isn't hard to occur updates in the meantime | 13:32 |
samueldmq | dstanek, otherwise, if we havent that table, one would accept endpoints to be inconsistent for the next {policy_timeout} seconds | 13:33 |
samueldmq | dstanek, if that's acceptable, we don't need that table :) | 13:33 |
samueldmq | dstanek, but I don't think it is | 13:34 |
*** zzzeek has joined #openstack-keystone | 13:35 | |
*** henrynash has quit IRC | 13:35 | |
dstanek | maybe 5 mins is too long? | 13:35 |
samueldmq | dstanek, so making the default like 1 min ? | 13:37 |
dstanek | breton: i don't know about that bug. i was the ML and was wondering how version of the client they were using. i don't know how to install the "kilo" version | 13:37 |
*** gordc has joined #openstack-keystone | 13:41 | |
*** hrou has joined #openstack-keystone | 13:42 | |
samueldmq | dstanek, maybe that's acceptable, however reducing the timeout implies on lots of unnecessary requests, since the policy does not change that much all the time | 13:42 |
samueldmq | dstanek, and we don't do If-Modified-Since requests | 13:42 |
*** henrynash has joined #openstack-keystone | 13:43 | |
*** ChanServ sets mode: +v henrynash | 13:43 | |
samueldmq | dstanek, (I think we should implements IMS requests, to avoid unnecessary network traffic) | 13:43 |
rodrigods | henrynash, hi... should we chat about the domain_id = None issue here? | 13:43 |
henrynash | rodigods: sure | 13:43 |
*** jsavak has joined #openstack-keystone | 13:43 | |
henrynash | rodigods: I don’t see how we can break that without a deprecation period | 13:44 |
rodrigods | henrynash, yeah =( | 13:44 |
rodrigods | so we should go with the bad UX than, right? | 13:44 |
rodrigods | projects acting as domains and regular projects act different in that case | 13:44 |
rodrigods | htruta, ^ | 13:45 |
henrynash | rodigods: I think you are right, maybe we do deprecate the whole idea of using a domin token (especially as we are going to kill domain tokens if I get my way) | 13:45 |
dstanek | samueldmq: i'm not worried about the network traffic as it would be minimal - i am more worries about the application | 13:45 |
rodrigods | henrynash, ++ | 13:45 |
dstanek | samueldmq: that's why my poc for caching roughed out if-none-match support | 13:45 |
henrynash | rodigods: I’m not sure we have much choice. but to go with what we have (I agree with the 6 cases you laid out) | 13:46 |
htruta | henrynash: ++ | 13:46 |
samueldmq | dstanek, if-none-match support ? | 13:46 |
htruta | henrynash, rodrigods, but we'll still have the case of project scope tokens, as I said in the comment in the patch | 13:46 |
henrynash | rodigods: I’ll have to work out how we exaplin that clearly in the API doc?!! | 13:46 |
dstanek | samueldmq: that's for etags | 13:47 |
rodrigods | henrynash, htruta, project scoped tokens falls back to the behavior it is implemented right now / the one henrynash is fixing | 13:47 |
rodrigods | henrynash, +1, maybe add a follow up patch here https://review.openstack.org/#/c/200624/ ? | 13:48 |
henrynash | hruta: so I think that works the same as it does now, if you use a project token then we haev to honor this undocumented functionality of trying the default domin until the deprecation time is up | 13:48 |
*** alex_xu has quit IRC | 13:48 | |
henrynash | rodigods: yes, I’m writing one already to follow that to state that teh fall back to default domain is deprecated | 13:49 |
htruta | henrynash, rodrigods, I see. that's some really bad UX. But I guess we can work this out for a while | 13:49 |
rodrigods | henrynash, great! | 13:49 |
henrynash | hruta, rodigods: yep, the sins of our fathers….oh, that was us!! | 13:50 |
htruta | so, as long as it is well documented, I'm fine with it. someone will need to read something before using reseller, anyway | 13:50 |
htruta | henrynash: heh | 13:50 |
*** alex_xu has joined #openstack-keystone | 13:51 | |
samueldmq | dstanek, so you think that it would be acceptable | 13:54 |
*** petertr7_away is now known as petertr7 | 13:54 | |
samueldmq | dstanek, the model would be simpler though with this approach | 13:54 |
samueldmq | dstanek, and policy 'instability' would occur only when updates occur | 13:55 |
samueldmq | morgan_404, you around ? | 13:56 |
samueldmq | morgan_404, what do you think about it ? ^ | 13:56 |
dstanek | samueldmq: i really don't know. since you are saying that you think policy has very strict caching requirements you are building CMS feature into it, which seems too much | 13:56 |
samueldmq | dstanek, I am being as much restrict as I can be in policy caching, to deliver the closer to CMS as it could be | 13:57 |
samueldmq | dstanek, if I am being to paranoid on how much strict it should be, I really want to listen to others and get some feedback :) | 13:59 |
*** doug-fish has quit IRC | 13:59 | |
henrynash | anyone know what the .[ldap] line is meant to do in the dependences in tox.ini? | 13:59 |
*** diazjf has joined #openstack-keystone | 13:59 | |
henrynash | (line 12 of current trunk version) | 14:00 |
dstanek | henrynash: it adds the optional dependency | 14:03 |
dstanek | henrynash: some of the testing deps where moved into extras | 14:03 |
*** afazekas has quit IRC | 14:03 | |
*** annasort has quit IRC | 14:03 | |
dstanek | henrynash: http://git.openstack.org/cgit/openstack/keystone/tree/setup.cfg#n24 | 14:03 |
henrynash | dstanek: do you knwo what I have to do to make it satified, runing tox just start fainling on my machine | 14:03 |
*** marzif has quit IRC | 14:04 | |
henrynash | saying it couldn;t satisfy that dependency | 14:04 |
dstanek | henrynash: you may have to update your pdr | 14:04 |
henrynash | dtsanek: oh….right | 14:04 |
*** marzif has joined #openstack-keystone | 14:04 | |
henrynash | dstanek: let me give that a go…thanks | 14:05 |
dstanek | np | 14:05 |
dstanek | samueldmq: i'm a little worried about the herd problem again here. how many different policies will nova typically use? 1 endpint right? | 14:07 |
samueldmq | dstanek, yes 1 policy | 14:07 |
samueldmq | dstanek, if we reduce the timeout, we increase the prob of occurring the herd problem | 14:08 |
dstanek | samueldmq: so ever 5 minutes 10s of 1000s of nova instances could hit keystone at nearly the same time? | 14:08 |
*** henrynash has quit IRC | 14:08 | |
*** hafe has quit IRC | 14:08 | |
*** fifieldt has joined #openstack-keystone | 14:08 | |
samueldmq | dstanek, only the endpoints sharing the same policy id hits the server at the same time | 14:08 |
dstanek | exactly | 14:09 |
*** sigmavirus24_awa is now known as sigmavirus24 | 14:10 | |
*** stevemar has joined #openstack-keystone | 14:12 | |
*** ChanServ sets mode: +v stevemar | 14:12 | |
samueldmq | dstanek, so if we define a policy for nova service, all nova endpoints will get at the same time | 14:12 |
dstanek | samueldmq: yeah, that doesn't scale | 14:13 |
samueldmq | dstanek, that's because the timeout expires based on a hash of the policy_id | 14:13 |
samueldmq | dstanek, I can make that dependent of the endpoint_id | 14:13 |
samueldmq | dstanek, so only endpoints with the same id will hit keystone at the same time | 14:14 |
dstanek | won't that basically be the same for all nova anyway? | 14:14 |
samueldmq | dstanek, maybe makes more sense | 14:14 |
samueldmq | dstanek, the same endpoint id ? | 14:14 |
*** narengan has joined #openstack-keystone | 14:14 | |
dstanek | samueldmq: yeah | 14:14 |
samueldmq | dstanek, I don't no, since there are different regions, etc | 14:15 |
samueldmq | dstanek, but I don't know how that is used in practice | 14:15 |
samueldmq | dstanek, need to listen from gyee on that | 14:15 |
*** stevemar has quit IRC | 14:15 | |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Add is_domain field in Project Table https://review.openstack.org/157427 | 14:16 |
samueldmq | dstanek, that's an interesting point though | 14:16 |
samueldmq | dstanek, I am glad you understand the proposed solution deeply too | 14:16 |
samueldmq | :) | 14:16 |
samueldmq | dstanek, I don't think so actually, otherwise we didn't need to implement endpoint filter | 14:17 |
dstanek | samueldmq: that's why i worry about having something expire at exactly X time for everyone | 14:17 |
samueldmq | dstanek, if we always used a single endpoint/service, and wouldn't need to make endpoints different of services | 14:18 |
*** fhubik has quit IRC | 14:19 | |
dstanek | samueldmq: if you have 10k nova instances in a region will they use a different endpoint_id or the same one? | 14:19 |
*** jecarey has joined #openstack-keystone | 14:19 | |
*** fhubik has joined #openstack-keystone | 14:19 | |
*** fhubik has quit IRC | 14:20 | |
dolphm | lbragstad: not that you have a use for this, but here's a list of every git SHA that has touched fernet in master (in order by date) http://cdn.pasteraw.com/4qlhmt3vc998yrfwsmft2m8njk3cz3m | 14:21 |
samueldmq | dstanek, it really depends on the deployment, but I think it is expected to be more than one | 14:22 |
samueldmq | dstanek, maybe we need to listen to operators on that front, (operators midcycle next week?) | 14:23 |
samueldmq | dstanek, maybe gyee has a good idea on this as well .. so we can be sure on how we distribute the endpoint processes to avoid the herd | 14:23 |
*** devlaps has quit IRC | 14:24 | |
*** phalmos has joined #openstack-keystone | 14:24 | |
dstanek | samueldmq: their midcycle is a good place to bring this up | 14:25 |
dstanek | i worry that is we don't have some amount of variance then we can't scale this | 14:25 |
samueldmq | dstanek, are you going to attend it ? | 14:25 |
dstanek | samueldmq: no | 14:25 |
samueldmq | dstanek, what if we do ims calls ? | 14:26 |
samueldmq | dstanek, anyway they would be calls hitting keystone | 14:26 |
samueldmq | :/ | 14:26 |
*** stevemar has joined #openstack-keystone | 14:27 | |
*** ChanServ sets mode: +v stevemar | 14:27 | |
dstanek | samueldmq: let me paint my picture for you...now i have no idea how buys these servers are so i may be way off | 14:27 |
dstanek | samueldmq: 1 nova in 1 region that does 10 request/sec will hit use up to 10 times the second it needs to fetch policy | 14:28 |
dstanek | samueldmq: with 10 novas that's up to 100 | 14:28 |
dstanek | samueldmq: with 1000 we just locked up keystone for 5 seconds and API requests fail | 14:29 |
samueldmq | dstanek, are you supposing we fetch policy at every nova api call? | 14:29 |
*** e0ne has joined #openstack-keystone | 14:29 | |
*** doug-fish has joined #openstack-keystone | 14:29 | |
dstanek | samueldmq: no, i'm assuming they use it at every API call and then every 5 minutes need to fetch it | 14:30 |
samueldmq | dstanek, sure, misunderstood | 14:31 |
samueldmq | dstanek, so with 1000 novas, we have 1k policy requests on keystone | 14:32 |
*** topol has joined #openstack-keystone | 14:32 | |
*** ChanServ sets mode: +v topol | 14:32 | |
samueldmq | dstanek, and 10k nova requests waiting for that to then proceed | 14:33 |
samueldmq | dstanek, right? | 14:33 |
dstanek | right | 14:33 |
samueldmq | dstanek, would 1k request lock up keystone? | 14:33 |
dstanek | maybe? not sure. plus there is other traffic like token validations happening on keystone | 14:34 |
samueldmq | dstanek, keystone is also expected to be high-available to serve 1k novas receiving a total amount of 10k request/seconds altogether | 14:35 |
samueldmq | dstanek, maybe we would be expecting too much of a single keystone instance... | 14:35 |
dstanek | samueldmq: the point is that this makes too many request simultaneously | 14:40 |
samueldmq | dstanek, hmm, actually this doesn't make _simultaneously_ ... it's when the first request arrives in the middleware, after the policy is obsolete | 14:41 |
*** vmbrasseur has quit IRC | 14:42 | |
samueldmq | dstanek, maybe makes things slightly better, or not ? | 14:42 |
dstanek | assuming my numbers for 1000 novas is correct... the operator scales keystone to handle peak traffic let say (avg * 1.45); now they have to scale much higher | 14:42 |
dstanek | samueldmq: if you assume each node is getting 10 rps then those 10 would simultaneously hit keystone | 14:43 |
lbragstad | dolphm: nice, thanks | 14:43 |
samueldmq | dstanek, I think the number of rps nova gets doesn't matter | 14:47 |
*** vmbrasseur has joined #openstack-keystone | 14:47 | |
samueldmq | dstanek, just the number of nova endpoints asking for the policy, right? | 14:48 |
*** dikonoo has quit IRC | 14:48 | |
dstanek | samueldmq: how will each thread know another thread is already getting the policy? | 14:50 |
dstanek | samueldmq: i'm not trying to make this overly complicated, but caching is very hard | 14:51 |
dstanek | there's an old saying that "if your app is too slow add caching; if your app has too many bug remove caching" or something like that | 14:51 |
*** petertr7 is now known as petertr7_away | 14:52 | |
lbragstad | jamielennox: do you want me to add myself as an "Other Contributor" - https://review.openstack.org/#/c/199339/2 | 14:54 |
samueldmq | dstanek, yes I completely understand your point, and I think it is valid | 14:54 |
samueldmq | dstanek, that an intersting saying :p | 14:54 |
morgan_404 | dstanek: your app is slow, so you add caching. Now you have two problems | 14:54 |
*** marzif has quit IRC | 14:54 | |
samueldmq | dstanek, I think like this: the first request arrives in middleware, makes it request the policy, and let the requests pass | 14:54 |
samueldmq | dstanek, don't block requests when getting the policy | 14:55 |
samueldmq | dstanek, if that makes sense | 14:55 |
*** morgan_404 is now known as morgan_302 | 14:55 | |
samueldmq | morgan_404, hey o/ | 14:55 |
dstanek | morgan_404: how critical do you think it is that policies can't be out of sync at all? | 14:55 |
dstanek | samueldmq: so you are going to add some thread coordination logic to middleware? | 14:55 |
samueldmq | dstanek, actually it's 302 now | 14:55 |
morgan_302 | dstanek: at a given endpoint it would be bad afaict. | 14:55 |
morgan_302 | But between endpoint not as bad | 14:56 |
samueldmq | dstanek, just a var set to fetch_mode=True, don't need overly complicated coordination | 14:56 |
morgan_302 | This is the classic thundering herd issue if i'm reading correctly | 14:56 |
samueldmq | morgan_302, this is exactly what we are talking about | 14:57 |
*** jistr is now known as jistr|mtg | 14:57 | |
* morgan_302 wants a distributed kvs so keystone can push policy out once and all endpoints can get it | 14:58 | |
morgan_302 | So if you use dogpile cacher, you can use an async runner to grab the policy and keep it alive for longer in memory. But lets be fair keystone distributing policy is kindof rife with issues. | 14:59 |
dstanek | morgan_302: yeah, well maybe that. but the more we talk about strange requirements the more i think HTTP isn't right for the job | 14:59 |
dstanek | samueldmq: what var? | 14:59 |
morgan_302 | dstanek: honestly i think policy is a config management issue still. | 14:59 |
stevemar | ++ | 15:00 |
morgan_302 | dstanek: part of the reason ive stayed out of this discussion for the most part | 15:00 |
dstanek | morgan_302: so the way i want thinking abut it is that right now if they roll out policy they don't reboot everything at once to reread - so they already have a period where things are out of sync | 15:00 |
morgan_302 | Policy is refreshed from disk automatically iirc | 15:01 |
dstanek | samueldmq: somehow thread 1 will need to know that thread 0 is getting a policy and not get one | 15:01 |
samueldmq | dstanek, each request gets it thread? | 15:01 |
samueldmq | its* | 15:01 |
dstanek | samueldmq: to make matters worse what about multiple processes? | 15:01 |
dstanek | samueldmq: eventlet :-) | 15:01 |
samueldmq | dstanek, well .. there is env_var that needs to be set to true, and then the request continue | 15:02 |
*** Ephur has joined #openstack-keystone | 15:02 | |
dstanek | so yes, basically | 15:02 |
samueldmq | dstanek, doesn't matter how many times it was set to true | 15:02 |
samueldmq | dstanek, dunno if that works actually :) | 15:02 |
dstanek | samueldmq: is that across threads? | 15:02 |
morgan_302 | So it is doable to use a single async runner | 15:02 |
dstanek | i think you'll have to use a lock | 15:02 |
morgan_302 | And just have that lock-enforced runner (non-blocking but so one only runs) drops the file on disk | 15:03 |
dstanek | morgan_302: ++ but i think someone rules that out because it was yet another thing to have operators run | 15:03 |
*** jsavak has quit IRC | 15:03 | |
morgan_302 | Nah. Async runner can be spawned by kystone. Its how dogpile works | 15:03 |
morgan_302 | If you build your tool to do thst | 15:03 |
morgan_302 | But... Otherwise it is a cron/other service. | 15:04 |
morgan_302 | I didnt say async runner was the best idea either. Just that it could be used | 15:04 |
samueldmq | morgan_302, dstanek policy in its own service? | 15:04 |
dstanek | samueldmq: no | 15:04 |
morgan_302 | If it drops the policy on disk all processes can load from that single endpoint. So thundering herd is limited to number of real servers without shared disk for a given service type no services * processes | 15:05 |
*** phalmos has quit IRC | 15:05 | |
* morgan_302 | 15:05 | |
samueldmq | ok so service * processes can be solved | 15:06 |
* morgan_302 dislikes having to design these types of systems. They always have tons of edge cases | 15:06 | |
samueldmq | morgan_302, so a previous discussion included 'how many novas can be in the same endpoint_id?' | 15:06 |
*** Ephur has quit IRC | 15:06 | |
morgan_302 | It is still a thundering herd | 15:06 |
samueldmq | morgan_302, if it can be 10k, it would be 10k requests at the same time | 15:06 |
morgan_302 | samueldmq: behind a loadbalancer? I dont know how many? | 15:07 |
*** jsavak has joined #openstack-keystone | 15:07 | |
morgan_302 | 10k would be silly | 15:07 |
morgan_302 | But not impossible | 15:07 |
*** phalmos has joined #openstack-keystone | 15:07 | |
morgan_302 | This is the "what level of scale are we talking about"? And we dont have numbers | 15:08 |
samueldmq | morgan_302, a single nova region is expected to contain multiple endpoints registered in keystone? | 15:08 |
morgan_302 | It could | 15:08 |
samueldmq | morgan_302, or could one register a single one and use it for all its 10k novas | 15:08 |
morgan_302 | We dont prevent it | 15:08 |
dstanek | that's why i think we should find out what the tolerance is for differences. even as little as 10 seconds dramatically helps. this is why people often use a splay to get updates in a distributed system | 15:08 |
morgan_302 | All of these are possible | 15:08 |
samueldmq | morgan_302, dstanek yes, that's all possible, but is that acceptable to have a concrete and very well documented solution for this cycle | 15:08 |
samueldmq | morgan_302, dstanek as it is experimental | 15:09 |
morgan_302 | dstanek: part of the issue is you break requests going through the system when they hit different endpoints in a LB | 15:09 |
samueldmq | so we look further starting next cycle, as this policy work will open the door for other things .. | 15:09 |
dstanek | samueldmq: since it is experimental i think using the simpler solution of having the differences would be better anyway | 15:09 |
dstanek | samueldmq: why over engineer now when we can do it later! | 15:09 |
samueldmq | and we don't accept it as stable if we don't solve all that, or at least find good explanations | 15:10 |
samueldmq | dstanek, if morgan's ok, I have no objection | 15:10 |
morgan_302 | dstanek: honestly i really think we need something like consul where keystone could just push the policy file to the dkvs. | 15:10 |
morgan_302 | Then the endpoints just read it | 15:10 |
morgan_302 | Or keystone pushes to some other similar shared *fast* storage | 15:10 |
dstanek | i have no issue with that. if the past i've uses zookeeper for similar configuration | 15:11 |
morgan_302 | Zk is the same concept ;) | 15:11 |
dstanek | i just don't want to develop a CMS inside of keystone | 15:11 |
morgan_302 | Hope we get that next cycle. See DLM mailinglist topic | 15:11 |
morgan_302 | ;) | 15:11 |
dstanek | current code is trending toward a publish-based cms | 15:11 |
*** roxanaghe has joined #openstack-keystone | 15:12 | |
morgan_302 | Im also leaning towards policy doesnt belong in keystone at all | 15:12 |
morgan_302 | It almost needs to be a separate process/endpoint | 15:12 |
morgan_302 | For distribution / management | 15:13 |
* morgan_302 greatly dislikes the "be everything for everyone" mentality we keep pushing into openstack projects | 15:13 | |
morgan_302 | There is a reason i've mostly stayed out of this convo | 15:14 |
samueldmq | morgan_302, and that is the reason ? ^ | 15:14 |
morgan_302 | Yep | 15:14 |
samueldmq | morgan_302, I still think we can enable this as experimental, maybe simpler as dstanek proposes | 15:15 |
samueldmq | then we can talk at the summit about a policy service? cms policy? next steps, etc | 15:15 |
samueldmq | consul? | 15:15 |
samueldmq | and so on.. | 15:15 |
samueldmq | if that makes sense | 15:15 |
* morgan_302 waves at roxanaghe | 15:18 | |
morgan_302 | roxanaghe: if guang is in the office today... Throw things at him for me :P. Mostly cause im not there to do so today ;) | 15:19 |
morgan_302 | roxanaghe: throw things at a person as a service ;) :P | 15:19 |
samueldmq | Throwing As A Service | 15:20 |
dstanek | roxanaghe: please have someone video it if you do :-) that would be great in a keystone core team trailer | 15:20 |
* lbragstad feels a spin off of http://opensax.com/ coming on... | 15:20 | |
*** arunkant_ has joined #openstack-keystone | 15:22 | |
roxanaghe | morgan_302, hehe, I would be glad to do that only if you approve it with a +2 :) | 15:23 |
morgan_302 | ^_^ | 15:23 |
*** geoffarnold has joined #openstack-keystone | 15:23 | |
roxanaghe | but I would have to delegate it for today since I'm stuck with fever at home :( | 15:23 |
roxanaghe | San Francisco summer... | 15:24 |
samueldmq | morgan_302, you ok with endpoints having 'different' policies for {policy_timeout} seconds, only when policy updates occur? | 15:27 |
samueldmq | morgan_302, that'd make the implementation/model slightly simpler .. | 15:27 |
dstanek | samueldmq: we should find out who will actually use this feature and then we can know how much not to build | 15:28 |
*** shunliz has quit IRC | 15:29 | |
*** arunkant_ has quit IRC | 15:31 | |
*** e0ne has quit IRC | 15:32 | |
samueldmq | dstanek, ok so the questions are: i) how much of thundering it can actually happen ? (this depends on how deployments are and how we can distribute the policy timeout) | 15:32 |
samueldmq | dstanek, ii) what level of inconsistency is acceptable? some minutes when updates occur? | 15:33 |
dstanek | or seconds | 15:33 |
*** arunkant_ has joined #openstack-keystone | 15:33 | |
dstanek | iii) what is the current level of inconsistency | 15:33 |
samueldmq | dstanek, ++ | 15:33 |
samueldmq | dstanek, so yes, we can get the answers from ops-summit next week | 15:34 |
*** jistr|mtg is now known as jistr | 15:34 | |
samueldmq | dstanek, let's leave our current implementation as paranoid as it is for now | 15:34 |
dstanek | samueldmq: i think we need to wait on merging implementation until then | 15:34 |
samueldmq | dstanek, and we adjust depending on the feedback | 15:34 |
samueldmq | dstanek, so we can 'relax' the implementation (if needed) once we get feedback | 15:37 |
samueldmq | dstanek, probably yes, were you planning to have the code merged before the ending of next week? | 15:37 |
*** henrynash has joined #openstack-keystone | 15:37 | |
*** ChanServ sets mode: +v henrynash | 15:37 | |
samueldmq | dstanek, I am finishing some tests on the server side, so I will prepare a demo with multiple glance servers behind a proxy next week | 15:38 |
dolphm | lbragstad: remember when you suggested that we put all the fernet backports into a single review sequence to avoid merge conflicts as they're approved? | 15:38 |
samueldmq | dstanek, all the code will be ready, and we do the adjustments according to fedback from their midcyle | 15:39 |
lbragstad | dolphm: I suggested that? | 15:39 |
dolphm | lbragstad: with a couple specific patches, yes | 15:39 |
dolphm | lbragstad: and also breaking out those patches i squashed so brant will review them... | 15:39 |
*** yottatsa has joined #openstack-keystone | 15:39 | |
samueldmq | dstanek, sounds a good plan? | 15:39 |
lbragstad | dolphm: yep, I saw that | 15:40 |
dstanek | samueldmq: sure....we (gyee) need to make it clear that we are talking about policy over HTTP | 15:41 |
dolphm | did the bot that links to newly posted reviews / patchset vanish? | 15:41 |
samueldmq | dstanek, what would be alternative for HTTP within openstck services? | 15:42 |
samueldmq | dstanek, if any . | 15:42 |
dolphm | samueldmq: ooh, HTTPS! | 15:42 |
*** phalmos has quit IRC | 15:42 | |
dstanek | lol | 15:42 |
samueldmq | dolphm, my ' ' ometime fail when I type it | 15:43 |
samueldmq | hehe | 15:43 |
dstanek | samueldmq: i guess the real question is "how complicated do we want Keystone to become?" | 15:43 |
dolphm | lbragstad: anywaym, i'm backporting all the fernet things into a single review sequence right now | 15:43 |
dstanek | dolphm: re: the ML thread. are they actually running the Kilo client? | 15:43 |
lbragstad | dolphm: thank you | 15:44 |
dolphm | dstanek: *shrug* | 15:44 |
samueldmq | dstanek, yes, that's the concern from morgan_302 | 15:44 |
*** petertr7_away is now known as petertr7 | 15:44 | |
openstackgerrit | Terry Howe proposed openstack/keystoneauth: Keep a consistent logger name for keystoneauth https://review.openstack.org/212602 | 15:44 |
samueldmq | dstanek, and that's why I asked if that should be a separate service | 15:44 |
dolphm | lbragstad: review sequence will start here https://review.openstack.org/#/c/212596/ | 15:44 |
samueldmq | dstanek, all that can be discussed at the summit I think | 15:44 |
dstanek | dolphm: i'm just wondering if there is actually a problem in the server in kilo and they are confusing client side changes with a server commit | 15:45 |
samueldmq | dstanek, I mean, the next steps.. if policy shouldn't be under keystone, let's create a separate service to manage/distribute it | 15:45 |
dstanek | samueldmq: yeah, but you are pushing for L, which is why it's a problem to solve now | 15:45 |
*** piyanai has joined #openstack-keystone | 15:45 | |
dolphm | dstanek: i believe if you install the client from debian packaging for example, you'll get the stable/kilo client | 15:46 |
samueldmq | dstanek, putting it as experimental? experimenting it is another reason to see how good/bad it can be | 15:46 |
dolphm | dstanek: and their complaint seems to line up with jamie's fix, and i think jamie's fix is backportable | 15:46 |
samueldmq | dstanek, another way* | 15:46 |
dolphm | dstanek: sooo, i was happy to oblige :) | 15:46 |
dstanek | samueldmq: see, that is where i disagree. i don't believe that 'experimental' should be used for science experiments. it's for features we are sure we want and are just not production ready yet | 15:47 |
samueldmq | dstanek, we want that, I am not saying we don't want | 15:47 |
samueldmq | dstanek, but I agree that may require changes in the future | 15:47 |
*** jistr has quit IRC | 15:48 | |
samueldmq | dstanek, like migrating to its own service? consul in openstack? | 15:48 |
samueldmq | dstanek, I am for the feature, and some operators also told us that they agree that it's useful (our email in the ops list) | 15:48 |
dstanek | samueldmq: that's what scares me...the main implementor isn't sure if it belongs in keystone :-) | 15:48 |
dstanek | when i say we i mean keystone not openstack | 15:49 |
samueldmq | dstanek, policy crud association is already in place | 15:49 |
samueldmq | dstanek, we're just allowing to effectively use it by fetching | 15:50 |
samueldmq | dstanek, I suppose the person who introduced the policy CRUD + endpoint policy has the answers for why they're in keystone | 15:50 |
dstanek | ..or how many people use it | 15:51 |
*** afazekas has joined #openstack-keystone | 15:51 | |
dolphm | dstanek: ++ experimental means it's intended for production, it just hasn't been proven as stable yet | 15:51 |
dolphm | it's like debian's testing branch :) it's not unstable -- but there's no guarantees and limited support | 15:52 |
dstanek | why is everyone so allergic to the phrase "out of tree"? | 15:53 |
samueldmq | dstanek, today I don't know if anyone does, since we don't allow the fetch | 15:53 |
samueldmq | dstanek, also we want to allow that so we can work on the other bits it opens the door for | 15:53 |
*** petertr7 is now known as petertr7_away | 15:53 | |
stevemar | morgan_302: https://bugs.launchpad.net/keystone/+bug/1484366 wishlist or won't fix? | 15:54 |
openstack | Launchpad bug 1484366 in Keystone "No way to specify password strength in keystone." [Undecided,New] | 15:54 |
dstanek | samueldmq: so does this current work make up an mvp? or is it still useless without more work | 15:54 |
samueldmq | dstanek, mvp? | 15:55 |
samueldmq | dstanek, I think it makes the existing code for policy crud + association useful | 15:55 |
samueldmq | dstanek, so it's useful | 15:56 |
morgan_302 | stevemar: uhh wut? | 15:56 |
*** woodster_ has joined #openstack-keystone | 15:57 | |
morgan_302 | Today i think is wont fix. But it is more wishlist and "not this cycle" | 15:57 |
dstanek | samueldmq: minimum viable product | 15:57 |
morgan_302 | dstanek: most valuable player! :p | 15:58 |
morgan_302 | More Vibrant Plant | 15:58 |
*** yottatsa has quit IRC | 15:58 | |
dstanek | #vote morgan_302 | 15:58 |
morgan_302 | Maximum Vital... No wait lets stop there | 15:59 |
dstanek | #vote ficus | 15:59 |
*** _cjones_ has joined #openstack-keystone | 15:59 | |
*** _cjones_ has quit IRC | 15:59 | |
*** _cjones_ has joined #openstack-keystone | 15:59 | |
morgan_302 | #startvote mvp means? MostValuablePlayer, MoreVibrantPlants,ficus | 16:00 |
morgan_302 | :P | 16:00 |
samueldmq | haha | 16:00 |
samueldmq | dstanek, is that ^ enough to make you believe it's a mvp? | 16:01 |
stevemar | morgan_302: i was asking if https://bugs.launchpad.net/keystone/+bug/1484366 should be marked as wishlist or won't fix? | 16:01 |
openstack | Launchpad bug 1484366 in Keystone "No way to specify password strength in keystone." [Undecided,New] | 16:01 |
samueldmq | dstanek, (minimum viable product in this case) :) | 16:01 |
*** yottatsa has joined #openstack-keystone | 16:01 | |
morgan_302 | Id say wont fix. But its probably wishlist and "not this cycle". I wont devote time to fixing the sql backend | 16:02 |
*** Ephur has joined #openstack-keystone | 16:02 | |
morgan_302 | In that regard. Ldap is better and does that for us | 16:02 |
dstanek | samueldmq: no idea, it depends on who will use this in L | 16:02 |
*** jasonsb has quit IRC | 16:05 | |
*** jasonsb has joined #openstack-keystone | 16:05 | |
*** edmondsw has quit IRC | 16:06 | |
samueldmq | dstanek, sure, but again, having this in L allow us to work on the other bits next cycle, otherwise we will only get this in M, I believe | 16:06 |
dstanek | samueldmq: if this doesn't land in L you can still work on it in M. that is not a prereq | 16:07 |
*** jasonsb has quit IRC | 16:10 | |
stevemar | morgan_302: i'll mark it as wishlist then | 16:10 |
*** tsubic has quit IRC | 16:10 | |
*** katkapilatova has left #openstack-keystone | 16:10 | |
openstackgerrit | Merged openstack/keystoneauth: Updated from global requirements https://review.openstack.org/212254 | 16:12 |
stevemar | poke all keystone folks presently chatting: dstanek morgan_302 dolphm samueldmq the tokenless auth patch could use some eyes/love https://review.openstack.org/#/c/156870/ | 16:12 |
dstanek | samueldmq: really i guess the question for gyee is what does he need to use it and what release does he use... | 16:12 |
breton | yes, please review x.509 | 16:13 |
samueldmq | stevemar, looking :) | 16:14 |
*** bknudson has joined #openstack-keystone | 16:15 | |
*** ChanServ sets mode: +v bknudson | 16:15 | |
dolphm | stevemar: sweeet, i didn't realize that had ever been published | 16:15 |
samueldmq | dstanek, why asking the level of inconsistency acceptable for deployers + providing it in L isn't acceptable? | 16:16 |
samueldmq | dstanek, because possibly all the policy model is bad and we shouldn't build on the top of it? | 16:16 |
samueldmq | dstanek, and then fix it (new service? consul?) etc before going further? | 16:17 |
dstanek | samueldmq: i'm not sure what you are asking. but my view on this has always been that we need to find a sponsor on the ops side to help guide direction | 16:18 |
samueldmq | dstanek, what I am arguing is that we already have the implementation (I'd say almost ready) | 16:20 |
*** diazjf has quit IRC | 16:20 | |
samueldmq | dstanek, and the message in the ops-list revealed operators interested in it | 16:20 |
dstanek | samueldmq: is it the right implementation? | 16:20 |
samueldmq | dstanek, it's only missing some details (the help to guide the implementation) | 16:21 |
samueldmq | dstanek, I don't know if it's the right implementation, but it's as precise as it could be (from an operator side) | 16:21 |
samueldmq | dstanek, what we need now is to listen to them next week | 16:21 |
dstanek | samueldmq: and find one to use it | 16:22 |
samueldmq | dstanek, and see if we are being paranoid with the cache mechanism | 16:22 |
*** gyee has joined #openstack-keystone | 16:22 | |
*** ChanServ sets mode: +v gyee | 16:22 | |
*** alejandrito has joined #openstack-keystone | 16:22 | |
samueldmq | dstanek, I suppose people who responded saying that 'synchronizing policy in endpoints behind a proxy isn't an easy task' and so will use it | 16:23 |
samueldmq | dstanek, basically people saying, yes we want it should be using it | 16:23 |
*** tsubic has joined #openstack-keystone | 16:24 | |
samueldmq | dstanek, did you see the operators feedback on the ml? https://www.mail-archive.com/openstack-operators@lists.openstack.org/msg02805.html | 16:25 |
samueldmq | dstanek, I think we are ok with stackholders now, it's more a matter of adjusting the details on the implementation | 16:25 |
samueldmq | if that makes sense | 16:25 |
dstanek | samueldmq: which one signed up to help with the design? | 16:27 |
samueldmq | dstanek, we didn't ask for that, and that's what I am proposing we look for in the ops-summit | 16:28 |
dstanek | samueldmq: iirc the ML thread people were agreeing that the global admin thing isn't good. was there talk about fetching the policy from keystone? | 16:28 |
dstanek | samueldmq: a stakeholder should be involved in the design to some extent | 16:28 |
samueldmq | dstanek, yes we also talk about fetching it from keystone, but lots of conversation are about the admin | 16:28 |
dstanek | at least inform the design | 16:28 |
dstanek | samueldmq: the original email talked about fetching from keystone, but did the operators? | 16:29 |
samueldmq | dstanek, sure, so we have people interested on it, and we need someone to validate/refine the design, right? | 16:29 |
*** diazjf has joined #openstack-keystone | 16:30 | |
*** edmondsw has joined #openstack-keystone | 16:30 | |
samueldmq | dstanek, https://www.mail-archive.com/openstack-operators@lists.openstack.org/msg02821.html | 16:31 |
dstanek | samueldmq: so in a normal software development process this would be the step where you would work with the stakeholder to see how to solve the problem in a tech agnostic way. then you come up with a tech design to present and explain it's constraints. then iterate and finally build. | 16:31 |
*** openstackgerrit has quit IRC | 16:31 | |
samueldmq | dstanek, talking about distributing the polciies : "Not the easiest task to either get right, or make sure that the files | 16:31 |
samueldmq | are distributed around in an HA setting. But absolutely necessary. | 16:31 |
samueldmq | " | 16:31 |
*** openstackgerrit has joined #openstack-keystone | 16:32 | |
samueldmq | dstanek, yeah, makes sense, but I suspect some guys here have some background in deployment, so we aren't totally lost | 16:32 |
*** petertr7_away is now known as petertr7 | 16:32 | |
dstanek | samueldmq: you mean the ops guys? | 16:33 |
samueldmq | dstanek, and what I am trying to do, at this point, is to fix it | 16:33 |
samueldmq | dstanek, no, I think some of us, like adam and gyee who have been involved on the solution discussion, so that's not the case our solution is bad | 16:33 |
samueldmq | dstanek, we just need to validate with a real stackholder, at this point | 16:33 |
samueldmq | dstanek, that's how I see it | 16:34 |
dstanek | samueldmq: that very well could be | 16:36 |
*** ankita_wagh has joined #openstack-keystone | 16:36 | |
*** ankita_wagh has quit IRC | 16:37 | |
samueldmq | dstanek, if we're going to fetch from an openstack server, the only thing we need to sync up with them is "how often? for how long inconsistencies are ok?" | 16:38 |
samueldmq | dstanek, the other options are: don't implement that on openstack at all (and forget the other benefits | 16:39 |
samueldmq | dstanek, and then deprecate the current apis for policy | 16:39 |
samueldmq | dstanek, or provide a common CMS implementation, which is not our task | 16:39 |
dstanek | samueldmq: so you have 3 designs to pitch? | 16:40 |
samueldmq | dstanek, so I think that for where we want to get, we are okay, just need some validation | 16:40 |
*** petertr7 is now known as petertr7_away | 16:40 | |
samueldmq | dstanek, basically yes: i) do it ii) don't do and deprecate the existing apis or iii) do it with a tool outside openstack (as today) | 16:41 |
*** ankita_wagh has joined #openstack-keystone | 16:41 | |
samueldmq | dstanek, so we are only interested on i) and ii) | 16:41 |
samueldmq | dstanek, and people already said i) so do it, we just need to agree on how to do it | 16:42 |
samueldmq | dstanek, that's then the validation of the architecture with operators | 16:42 |
dstanek | samueldmq: so i didn't see were anybody cared about the HTTP solution. let's wait and discuss next week. | 16:43 |
samueldmq | dstanek, http solution == managing/fetching using openstack services, right? | 16:43 |
dstanek | yes | 16:44 |
samueldmq | dstanek, there are a lot of benefits ... that's the whole dynamic policies work | 16:44 |
samueldmq | dstanek, like providing better interfaces for defining policies | 16:44 |
samueldmq | dstanek, distributing them transparently, and so on | 16:44 |
samueldmq | dstanek, gyee 's up, want to take some conversation if he is available? | 16:45 |
dstanek | samueldmq: that's find it that's the only way to solve the global admin problem, but it looks like several operators have developed their own solution to the problems | 16:45 |
*** jamielennox is now known as jamielennox|away | 16:45 | |
dstanek | s/find it/fine if/ | 16:45 |
*** afaranha has joined #openstack-keystone | 16:49 | |
*** afaranha has left #openstack-keystone | 16:49 | |
samueldmq | dstanek, yes and they are building their own tools on top of openstack | 16:50 |
gyee | samueldmq, \o | 16:50 |
gyee | reading back | 16:50 |
*** spandhe has joined #openstack-keystone | 16:50 | |
samueldmq | gyee, hey, that's a huge conversation, I can summarize it for you :) | 16:51 |
gyee | k | 16:51 |
samueldmq | gyee, so .. I and dstanek have been discussing about the policy solution we are proposing | 16:52 |
samueldmq | dstanek, .. correct me if I am wrong :) | 16:52 |
samueldmq | gyee, so basically we need to validate our proposed design with operators | 16:52 |
*** henrynash has quit IRC | 16:52 | |
samueldmq | gyee, for example, is it acceptable to have policies inconsistent through endpoint processes when a policy update occurs? if so, for how long? | 16:53 |
samueldmq | gyee, also, we need to know a bit more how is the architecture of big deployments, so we can avoid the classical thundering herd problem | 16:54 |
*** browne has quit IRC | 16:54 | |
gyee | that's all depends on the deployment | 16:54 |
samueldmq | gyee, for example, if the cloud has a region and there are 10k nova nodes under that region using the same endpoint_id ? | 16:54 |
samueldmq | dstanek, am I missing something else? | 16:55 |
gyee | say if you revoke a token, would the Nova instance become inaccessible of it was started by that token? | 16:55 |
gyee | security is a process, software is a tool :) | 16:55 |
gyee | it all depends of the security requirements for a particular deployment | 16:56 |
dstanek | gyee: what does the token have to do with the policy files? | 16:56 |
gyee | dstanek, same deal, if policy are inconsistent for a few seconds while the system is absorbing the new policy changes, that's customer's choice | 16:57 |
gyee | we don't dictate that | 16:57 |
dstanek | i don't think we can do that in a scalable way in keystone then | 16:57 |
gyee | we just provide the flexibility to allow them to make that choice | 16:57 |
navid_ | nick navid | 16:57 |
*** navid_ has quit IRC | 16:58 | |
dstanek | we basically need a distributed datastore accessible to all nodes that use policy | 16:59 |
dstanek | gyee: the problem i see is that we cause the herd because of an exact timeout | 17:00 |
*** jsavak has quit IRC | 17:00 | |
gyee | dstanek, isn't Keystone a distributed store? | 17:02 |
gyee | if Keystone dies, the system is unusable | 17:04 |
dstanek | gyee: not in the same way as consule, zookeeper, etc. | 17:04 |
dstanek | it is not as easy for use to absorb a few thousand extra concurrent requests | 17:04 |
*** petertr7_away is now known as petertr7 | 17:05 | |
gyee | dstanek, how about 50 keystone nodes spread across? :) | 17:05 |
haneef | stevemar: What does observor mean in cadf? | 17:05 |
gyee | observor usually means read-only | 17:06 |
dstanek | gyee: is that acceptable? | 17:06 |
gyee | dstanek, it depends on expectations, HA, scale and performance | 17:06 |
*** jsavak has joined #openstack-keystone | 17:06 | |
haneef | gyee: I don't get you. I cadf payload what does observor contain? | 17:07 |
dstanek | haneef: no idea, but this may be a good starting point http://git.openstack.org/cgit/openstack/keystone/tree/keystone/notifications.py#n721 | 17:08 |
stevemar | haneef: the service that "sees" the request | 17:09 |
dstanek | gyee: my though it that is we use caching things will be out of sync, so we can embrace it in the design | 17:09 |
haneef | stevemar: example please? If I do create user , does that mean, it is keystone? | 17:10 |
*** petertr7 is now known as petertr7_away | 17:10 | |
gyee | dstanek, even with consul and zookeeper, there still opportunity for things to get out of sync right? | 17:10 |
stevemar | haneef: right | 17:10 |
dstanek | gyee: yes, to some extent | 17:10 |
stevemar | haneef: if it were a request to create a VM, the observer shuld be nova | 17:10 |
gyee | so we have some risk tolerance either way | 17:10 |
dstanek | gyee: the currently impl we have is going out of it's way to cause the thundering herd problem; and the question i have to the operators is how big of a problem is that? | 17:11 |
haneef | stevemar: Also question about id. Some ids are prefixed by openstack: ... does that mean, those ids are cadf specific? | 17:11 |
dstanek | gyee: how many nodes they they have for either endpoints and what the average traffic across those nodes | 17:11 |
haneef | e.g: "id": "openstack:11fc2c26-0d67-4875-90d0-09186863e502" | 17:11 |
stevemar | haneef: pycadf does that if you don't specify an ID when creating the cadf event | 17:11 |
*** boris-42 has joined #openstack-keystone | 17:11 | |
samueldmq | dstanek, the herd problem it can suffer is: N endpoints processes which have the same id in keystone and receive an user request at the same time after the policy becomes stale, will cause N policy requests to keystone | 17:13 |
haneef | stevemar: One more thing , If observer is id of service , doesn't it have to same every time? If I do 2 user create, will I get same id for observor | 17:13 |
samueldmq | dstanek, right? not endpoint vs request, as we talked wiht morgan | 17:13 |
gyee | dstanek, that all depends on the size of the deployment too. HP public cloud, for example, even support multiple regions | 17:14 |
dstanek | almost | 17:14 |
stevemar | haneef: you should, yes | 17:14 |
dstanek | N * (number of concurrent eventlet threads) | 17:14 |
gyee | so replicating stuff across region is going to be a bit slower, but should now be slower than order of miliseconds | 17:14 |
stevemar | haneef: i think you're getting at this? https://bugs.launchpad.net/keystone/+bug/1428946 | 17:14 |
openstack | Launchpad bug 1428946 in Keystone "add keystone service id to observer audit" [Low,Triaged] | 17:14 |
dstanek | gyee: we're not talking replication | 17:15 |
gyee | we also have monitoring tools in place to make sure things are running at *normal speed* | 17:15 |
dstanek | gyee: assume you have 1000 nodes for an endpoint with an average of 10 requests per second - that means up to 10,000 requests to keystone every 5 minutes to get policy | 17:16 |
dstanek | and not over 5 minutes; *at* the 5 minute mark | 17:16 |
dstanek | so my question for the operators is how many nodes they have for an endpoint and how much traffic they see | 17:16 |
haneef | stevemar: yes. Isn't it as simple as adding an identifier for kesytone in conf file? | 17:17 |
samueldmq | dstanek, at the 5 minute mark if they all get a request at that exact time | 17:17 |
dstanek | gyee: so that size of a deployment would need to add 20 keystone servers to handle the extra traffic... | 17:17 |
gyee | dstanek, 5 minutes is nothing compare to token validation | 17:17 |
samueldmq | dstanek, since that's how middleware works | 17:17 |
samueldmq | dstanek, that's a good quesiton though | 17:18 |
dstanek | samueldmq: right. assuming 10 request per second they absolutely could | 17:18 |
stevemar | haneef: you could do that, but we already store the service ID in the keystone database, so we should get it from there | 17:18 |
*** lhcheng has joined #openstack-keystone | 17:18 | |
*** ChanServ sets mode: +v lhcheng | 17:18 | |
gyee | policy request should be relatively fast, either the policy has been updated or not | 17:18 |
gyee | if updated, fetch and cache | 17:18 |
dstanek | gyee: a few db records to at least look at, but yes relatively fast | 17:19 |
gyee | most of time, it is nothing more than a ping | 17:19 |
dstanek | gyee: no, we still have to check | 17:19 |
gyee | assume we don't update policy every few mins | 17:19 |
haneef | stevemar: got it. Thanks | 17:20 |
dstanek | gyee: even if we 304, we still do the server side work to make sure a 304 is the correct response | 17:20 |
gyee | dstanek, there's no DB hit on policy check I hope | 17:20 |
samueldmq | dstanek, but that's quick, just re-calculate the max-age to tell the endpoint to ask again | 17:20 |
dstanek | gyee: sure there is! | 17:21 |
gyee | whahhh? | 17:21 |
samueldmq | last time it is updated have to be stored in db | 17:21 |
dstanek | gyee: and whey you guys start doing dynamic policies it'll be serveral! | 17:21 |
gyee | we're not caching it on the server side? | 17:21 |
* gyee needs to read the fantastical code | 17:22 | |
dstanek | gyee: because we don't want it to get out of sync at all we are using the database at a system of record for when a policy is valid | 17:22 |
dstanek | otherwise the policy could change in between the 5 minute mark (because an admin updated it) and only a few nodes would get the update | 17:22 |
samueldmq | and that's ^ bad behind a proxy | 17:23 |
samueldmq | where processes should apply the same access control rules at a given time | 17:23 |
gyee | hold the phone, aren't we caching it on the server side the same way? | 17:23 |
gyee | just like storing per-domain config in sql right? | 17:23 |
samueldmq | gyee, not yet, there is no granular CRUD on policies now, we just store the blob so far | 17:25 |
samueldmq | gyee, if that's your question .. | 17:25 |
*** petertr7_away is now known as petertr7 | 17:25 | |
*** piyanai has quit IRC | 17:26 | |
gyee | samueldmq, yeah, we can think of ways to optimize it later | 17:26 |
gyee | I suspect we won't know till we have a chance to kick the tire on this one | 17:26 |
samueldmq | gyee, yes, I am planning to have it next cycle | 17:27 |
gyee | hell I need to find me 1000 nodes to start with :) | 17:27 |
samueldmq | gyee, to easily update the policy rules without looking at the whole policy | 17:27 |
*** pgbridge has quit IRC | 17:27 | |
dstanek | gyee: HP public cloud? | 17:27 |
*** petertr7 is now known as petertr7_away | 17:27 | |
dstanek | gyee: download the code and start kicking the tires! | 17:28 |
gyee | dstanek, sure | 17:28 |
gyee | I suspect they'll revoke my parking space if I use HP public cloud as the playground | 17:28 |
dstanek | gyee: what is the amount of time machines in HP public cloud have inconsistent policies now? | 17:28 |
samueldmq | #vote gyee | 17:29 |
dstanek | gyee: and that's what i'm worried about :-) current impl is probably fine for small private cloud | 17:29 |
stevemar | #vote gyee | 17:29 |
gyee | dstanek, we don't have inconsistent policy right now cause we don't use that feature in public cloud | 17:30 |
dstanek | gyee: you don't use policy files? | 17:30 |
gyee | we do | 17:30 |
openstackgerrit | Terry Howe proposed openstack/keystoneauth: Use human readable exception messages https://review.openstack.org/212670 | 17:30 |
gyee | but we don't do dynamic policy fetch right now | 17:30 |
gyee | policy update still done via chef/ansible | 17:31 |
dstanek | so after an update how long are things inconsistent? | 17:31 |
dstanek | gyee: ^ | 17:32 |
gyee | it depends, usually just a push of a deploy button | 17:32 |
*** HT_sergio has joined #openstack-keystone | 17:32 | |
gyee | afaik, they don't go out of sync publically | 17:32 |
gyee | update usually goes like this | 17:32 |
samueldmq | the time ansible/chef takes, it is the maximum inconsistency, i.e updating the first and last endpoints | 17:32 |
gyee | 1) remove the node from LB | 17:33 |
gyee | 2) update it | 17:33 |
samueldmq | hmm | 17:33 |
gyee | 3) put it back on | 17:33 |
samueldmq | so there is no inconsistency | 17:33 |
gyee | not publically I don't think | 17:34 |
dstanek | gyee: what you just said creates inconsistency unless you take all nodes out at the same time! | 17:34 |
*** diazjf has left #openstack-keystone | 17:35 | |
samueldmq | dstanek, or half of them | 17:35 |
gyee | dstanek, take x number of nodes off line, update them, then swap | 17:35 |
samueldmq | dstanek, update a half, and them the other half later :) | 17:35 |
samueldmq | gyee, ++ | 17:35 |
dstanek | gyee: exactly, so for some periiod of time some nodes are serving old policy and some are serving the new policy | 17:36 |
gyee | but the ones serving new policy are not back onto LB till the swap | 17:36 |
dstanek | samueldmq: i think x usually depends on the current traffic and other things. i've not done amy 50/50 swaps in the past; that's why i'm asking | 17:37 |
dstanek | gyee: so you do a 50% swap? | 17:37 |
gyee | doesn't have to be 50/50 | 17:37 |
dstanek | gyee: so you only have a few seconds on inconsistency then | 17:38 |
gyee | probably, depending on how quickly they can switch the nodes over | 17:39 |
gyee | I can double check with the ops guys | 17:39 |
samueldmq | dstanek, is it possible to lock/coordinate the policy fetch in a system var? so it would be shared even across eventlet threads | 17:41 |
samueldmq | dstanek, or even a file .. | 17:41 |
*** browne has joined #openstack-keystone | 17:42 | |
dstanek | samueldmq: sure, it's possible - don't know if it's wise yet | 17:42 |
gyee | samueldmq, lets not trying to solve that for now | 17:42 |
gyee | if folks can't tolerate inconsistency for a short period of time, let them do it the old fashion way | 17:43 |
gyee | take down the nodes and do chef/ansible | 17:43 |
samueldmq | gyee, k just making sure the herd problem will be solved as well ;) | 17:43 |
gyee | its really about choice and risk management | 17:44 |
*** ankita_w_ has joined #openstack-keystone | 17:44 | |
samueldmq | gyee, dstanek k let's keep on the requirements now | 17:44 |
gyee | what requirement? zero inconsistency? | 17:45 |
dstanek | gyee: yes, that's one | 17:45 |
gyee | ouch! | 17:45 |
dstanek | that's what causes the herd | 17:45 |
gyee | I don't think we'll ever going to achieve that | 17:45 |
gyee | not even with zookeeper I don't think | 17:46 |
dstanek | gyee: we've got lots of code and a new DB table to try | 17:46 |
gyee | but sure, if we're gonna do it, do it big :) | 17:46 |
*** Ephur_ has joined #openstack-keystone | 17:46 | |
dstanek | gyee: i totally agree and what i was saying yesterday(?) is that we should say what the timeframe for inconsistency will be for the experimental feature and go with that | 17:46 |
*** ankita_wagh has quit IRC | 17:47 | |
gyee | dstanek, no objection here | 17:47 |
dstanek | gyee: i agre with gyee[-2] not the 'go big' | 17:47 |
gyee | go big or go home :) | 17:47 |
samueldmq | hehe | 17:47 |
dstanek | i'm very comfortable saying that this is experimental any under the default config your policy could be out of whack for 1 minute or whatever | 17:48 |
samueldmq | you guys are fun to work with :) | 17:48 |
dstanek | gyee: side note. today is the first pre-season game | 17:48 |
*** Ephur has quit IRC | 17:48 | |
gyee | go browns! | 17:49 |
gyee | and bucks | 17:49 |
gyee | dstanek, 1 minutes inconsistency may not fly, 5 seconds, sure | 17:50 |
*** Ephur has joined #openstack-keystone | 17:50 | |
*** diazjf has joined #openstack-keystone | 17:50 | |
dstanek | gyee: you're free to reconfigure the default and overload your keystone :-) | 17:51 |
gyee | if network latency is more than a few miliseconds, all hell break loose | 17:51 |
*** Ephur_ has quit IRC | 17:51 | |
*** petertr7_away is now known as petertr7 | 17:51 | |
samueldmq | dstanek, haha that'd happen if we only depend on the timeout | 17:51 |
gyee | samueldmq, yeah, we should avoid DB hit on check | 17:52 |
samueldmq | gyee, we can't do that I believe, think of proxied keystone servers | 17:52 |
samueldmq | gyee, proxied (don't know if this word even exists) | 17:53 |
samueldmq | gyee, the only way a keystone process can check if the policy is valid is looking into db :/ | 17:53 |
gyee | I wonder if we can make use of notification mechanism | 17:56 |
gyee | anyway, more investigation work to do | 17:56 |
samueldmq | gyee, I think there is no guarantee the other side is going to receive the notification | 17:56 |
samueldmq | gyee, I've heard something like that | 17:57 |
gyee | I mean notification among keystone nodes to update the cache | 17:58 |
*** rm_work is now known as rm_work|away | 17:58 | |
*** rm_work|away is now known as rm_work | 18:00 | |
dstanek | gyee: now you're getting crazy | 18:00 |
samueldmq | hahaha | 18:01 |
*** ankita_wagh has joined #openstack-keystone | 18:02 | |
*** narengan has quit IRC | 18:02 | |
*** ankita_w_ has quit IRC | 18:04 | |
gyee | dstanek, yeah, btw, how does consul or zookeeper sync up? | 18:05 |
*** ankita_w_ has joined #openstack-keystone | 18:06 | |
*** ankita_wagh has quit IRC | 18:09 | |
dstanek | gyee: each has their own replication ability; i think consul's is a separate server/application to run | 18:10 |
gyee | nice, lemme play with it to see how it goes | 18:15 |
*** piyanai has joined #openstack-keystone | 18:17 | |
*** petertr7 is now known as petertr7_away | 18:23 | |
*** piyanai has quit IRC | 18:23 | |
*** fangzhou has joined #openstack-keystone | 18:27 | |
*** ParsectiX has joined #openstack-keystone | 18:31 | |
*** ParsectiX has quit IRC | 18:34 | |
*** petertr7_away is now known as petertr7 | 18:39 | |
*** narengan has joined #openstack-keystone | 18:40 | |
openstackgerrit | Merged openstack/python-keystoneclient: Stop using .keys() on dicts where not needed https://review.openstack.org/194894 | 18:45 |
*** gyee has quit IRC | 18:45 | |
*** piyanai has joined #openstack-keystone | 18:47 | |
*** HT_sergio has quit IRC | 18:47 | |
*** diazjf has left #openstack-keystone | 18:48 | |
*** nkinder has joined #openstack-keystone | 18:49 | |
*** atiwari1 has quit IRC | 18:49 | |
*** nkinder has quit IRC | 18:50 | |
*** jsavak has quit IRC | 18:51 | |
*** ankita_wagh has joined #openstack-keystone | 18:52 | |
*** jasonsb has joined #openstack-keystone | 18:52 | |
*** narengan has quit IRC | 18:53 | |
*** jsavak has joined #openstack-keystone | 18:54 | |
*** narengan has joined #openstack-keystone | 18:54 | |
*** ankita_w_ has quit IRC | 18:55 | |
*** akscram has quit IRC | 18:56 | |
*** narengan has quit IRC | 18:57 | |
*** narengan has joined #openstack-keystone | 18:57 | |
*** akscram has joined #openstack-keystone | 18:58 | |
*** narengan has quit IRC | 18:58 | |
*** jsavak has quit IRC | 18:58 | |
*** Navid_ has joined #openstack-keystone | 18:58 | |
*** jsavak has joined #openstack-keystone | 18:59 | |
*** narengan has joined #openstack-keystone | 18:59 | |
samueldmq | dstanek, have you heard about any python tool to check architectural constraints? | 19:00 |
samueldmq | dstanek, or something like that ... | 19:00 |
*** vivekd has joined #openstack-keystone | 19:00 | |
samueldmq | dstanek, I just noticed that some drivers don't inherit from the Driver class defined at core.py | 19:00 |
dstanek | samueldmq: what sort of architectural constraints are you referring to? | 19:00 |
*** narengan_ has joined #openstack-keystone | 19:01 | |
samueldmq | dstanek, look at endpoint_policy/backends/sql for example | 19:01 |
samueldmq | dstanek, to this ^ | 19:01 |
dstanek | i don't believe i've heard of anything that can automatically check architectural constraints | 19:01 |
*** henrynash has joined #openstack-keystone | 19:01 | |
*** ChanServ sets mode: +v henrynash | 19:01 | |
dstanek | samueldmq: that's not an architecture thing at all. technically it doesn't have to subclass it, but we probably want it to | 19:03 |
*** narengan has quit IRC | 19:03 | |
samueldmq | dstanek, hmm, I thought it was part of our architecture, like defining classes, the communication between them and so on | 19:04 |
samueldmq | dstanek, although I was wondering how that works if it don't inherit from the Driver class defined there | 19:04 |
dstanek | python is duck-typed so it doesn't need to | 19:05 |
*** phalmos has joined #openstack-keystone | 19:05 | |
samueldmq | dstanek, facepalm | 19:07 |
*** bapalm_ is now known as bapalm | 19:07 | |
samueldmq | dstanek, had forget about that :/ | 19:07 |
samueldmq | dstanek, all this policy discussion today made me crazy I think | 19:07 |
*** pgbridge has joined #openstack-keystone | 19:12 | |
*** phalmos has quit IRC | 19:17 | |
samueldmq | dstanek, I will adapt the implementation to variate the policy timeout based on the endpoint_id (currently it is on policy_id) | 19:20 |
*** petertr7 is now known as petertr7_away | 19:20 | |
samueldmq | dstanek, tomorrow we can discuss a little bit more about it with gyee | 19:20 |
samueldmq | dstanek, sounds good ? or have you any idea / conclusion already? | 19:20 |
samueldmq | dstanek, I learned he wants 0 inconsistency .. like we're doing now | 19:21 |
samueldmq | dstanek, we need to solve the herd problem though | 19:21 |
*** yottatsa has quit IRC | 19:23 | |
*** phalmos has joined #openstack-keystone | 19:24 | |
*** petertr7_away is now known as petertr7 | 19:25 | |
*** piyanai has quit IRC | 19:27 | |
*** piyanai has joined #openstack-keystone | 19:31 | |
*** fifieldt_ has joined #openstack-keystone | 19:33 | |
*** fifieldt has quit IRC | 19:34 | |
*** alejandrito has quit IRC | 19:44 | |
anteaya | stevemar: do you feel like updating this bug? https://bugs.launchpad.net/devstack/+bug/1484448 | 19:48 |
openstack | Launchpad bug 1484448 in devstack "ERROR: openstack Missing parameter(s): Set a service URL, with --os-url, OS_URL or auth.url" [Undecided,New] | 19:48 |
anteaya | or jamielennox|away? | 19:48 |
*** piyanai has quit IRC | 19:53 | |
*** spandhe has quit IRC | 19:59 | |
*** piyanai has joined #openstack-keystone | 19:59 | |
stevemar | anteaya: hmm, i thought i caught all the dupes | 20:10 |
stevemar | looks like i missed one | 20:11 |
stevemar | anteaya: marked as dupe | 20:14 |
*** jsavak has quit IRC | 20:15 | |
anteaya | thanks | 20:19 |
*** jsavak has joined #openstack-keystone | 20:21 | |
*** petertr7 is now known as petertr7_away | 20:27 | |
*** tjcocozz has joined #openstack-keystone | 20:27 | |
*** alejandrito has joined #openstack-keystone | 20:28 | |
*** jasonsb has quit IRC | 20:29 | |
*** jasonsb has joined #openstack-keystone | 20:29 | |
*** petertr7_away is now known as petertr7 | 20:32 | |
*** jasonsb has quit IRC | 20:34 | |
htruta | henrynash: are you still here? | 20:35 |
*** topol has quit IRC | 20:35 | |
*** mylu has joined #openstack-keystone | 20:37 | |
*** ayoung has joined #openstack-keystone | 20:37 | |
*** ChanServ sets mode: +v ayoung | 20:37 | |
*** phalmos has quit IRC | 20:37 | |
dstanek | anyone have thoughts on https://bugs.launchpad.net/keystone/+bug/1240163 ? | 20:41 |
openstack | Launchpad bug 1240163 in Keystone "Can't store a PKI token with a large catalog" [High,Triaged] - Assigned to Adam Young (ayoung) | 20:41 |
ayoung | dstanek, deprecate PKI tokens | 20:42 |
dstanek | ayoung: i'm happy with a wontfix we'll be deprecating pki tokens soon :-) | 20:43 |
ayoung | dstanek, testing that the tokens starts with MI[IJK] is probably a better short term fix | 20:44 |
*** narengan_ has quit IRC | 20:46 | |
*** narengan has joined #openstack-keystone | 20:46 | |
ayoung | http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/common/cms.py#n284 dstanek | 20:46 |
*** rdo has quit IRC | 20:50 | |
*** woodster_ has quit IRC | 20:50 | |
*** narengan has quit IRC | 20:50 | |
*** narengan has joined #openstack-keystone | 20:51 | |
*** Guest61394 is now known as med_ | 20:51 | |
*** med_ has joined #openstack-keystone | 20:51 | |
*** rdo has joined #openstack-keystone | 20:52 | |
*** narengan has quit IRC | 20:52 | |
*** narengan has joined #openstack-keystone | 20:52 | |
*** woodster_ has joined #openstack-keystone | 20:54 | |
*** mylu has quit IRC | 20:57 | |
*** narengan has quit IRC | 20:57 | |
*** mylu has joined #openstack-keystone | 20:59 | |
*** raildo is now known as raildo-afk | 20:59 | |
*** mylu has quit IRC | 21:00 | |
*** narengan has joined #openstack-keystone | 21:03 | |
*** tjcocozz has quit IRC | 21:04 | |
*** petertr7 is now known as petertr7_away | 21:07 | |
*** piyanai has quit IRC | 21:07 | |
*** narengan has quit IRC | 21:16 | |
*** narengan has joined #openstack-keystone | 21:16 | |
*** jsavak has quit IRC | 21:18 | |
*** narengan has quit IRC | 21:21 | |
*** ayoung has quit IRC | 21:21 | |
*** narengan has joined #openstack-keystone | 21:22 | |
*** ankita_wagh has quit IRC | 21:26 | |
*** ankita_wagh has joined #openstack-keystone | 21:27 | |
openstackgerrit | Brant Knudson proposed openstack/keystone: Remove "tenants" from user_attribute_ignore default https://review.openstack.org/189029 | 21:29 |
*** ankita_wagh has quit IRC | 21:31 | |
dstanek | bknudson: any reason for me to not mark this as invalid for Keystone? https://bugs.launchpad.net/keystone/+bug/1359995 | 21:32 |
openstack | Launchpad bug 1359995 in Keystone "Tempest failed to delete user" [Undecided,Incomplete] | 21:32 |
bknudson | dstanek: go ahead. I'll open a new bug next time there's a failure and the keystone logs are useless. | 21:33 |
*** narengan has quit IRC | 21:35 | |
*** narengan has joined #openstack-keystone | 21:36 | |
*** narengan has quit IRC | 21:40 | |
*** alejandrito has quit IRC | 21:41 | |
*** fangzhou has quit IRC | 21:41 | |
*** gyee has joined #openstack-keystone | 21:42 | |
*** ChanServ sets mode: +v gyee | 21:42 | |
*** ankita_wagh has joined #openstack-keystone | 21:42 | |
*** ankita_wagh has quit IRC | 21:43 | |
*** ankita_wagh has joined #openstack-keystone | 21:43 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 21:46 | |
openstackgerrit | Brant Knudson proposed openstack/keystone: Bandit config updates https://review.openstack.org/194417 | 21:48 |
openstackgerrit | Brant Knudson proposed openstack/keystone: Enable bandit check for password_config_option_not_marked_secret https://review.openstack.org/194420 | 21:49 |
*** stevemar has quit IRC | 21:51 | |
*** morgan_302 has quit IRC | 22:04 | |
*** morganfainberg has joined #openstack-keystone | 22:07 | |
*** ChanServ sets mode: +v morganfainberg | 22:07 | |
*** doug-fish has left #openstack-keystone | 22:11 | |
*** gyee is now known as gyee_500 | 22:12 | |
*** ayoung has joined #openstack-keystone | 22:13 | |
*** ChanServ sets mode: +v ayoung | 22:13 | |
*** jecarey has quit IRC | 22:19 | |
openstackgerrit | Roxana Gherle proposed openstack/keystone: Domain configs are loaded with wrong type from db https://review.openstack.org/212816 | 22:20 |
openstackgerrit | ayoung proposed openstack/python-keystoneclient: Shorten PKI Token Identifier to MI https://review.openstack.org/212819 | 22:23 |
*** gordc has quit IRC | 22:25 | |
openstackgerrit | Vivek Dhayaal proposed openstack/keystone: Stable Keystone Driver Interfaces https://review.openstack.org/209524 | 22:26 |
*** stevemar has joined #openstack-keystone | 22:26 | |
*** ChanServ sets mode: +v stevemar | 22:26 | |
openstackgerrit | Merged openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/212745 | 22:33 |
*** jamielennox|away is now known as jamielennox | 22:33 | |
*** vivekd has quit IRC | 22:34 | |
ayoung | roxanaghe, so...good catch on the bug. I'd recommend making the patch title the positive: | 22:42 |
ayoung | Something like: maintain datatypes when loading configs frm DB | 22:43 |
ayoung | it should be saying what you are doing, not what the bug was that you are fixing. | 22:44 |
roxanaghe | ayoung, ok - thanks for suggestion - I'll make it positive | 22:48 |
*** edmondsw has quit IRC | 22:48 | |
ayoung | roxanaghe, I added a revew...no rating | 22:49 |
ayoung | roxanaghe, I wonder if it makes sense to ever convert? If so...does doing a blanket convert=False might break something else... | 22:49 |
ayoung | need some context on that change, I think | 22:49 |
openstackgerrit | Merged openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/212762 | 22:50 |
roxanaghe | ayoung: so I added that optional flag in oslo.config recently | 22:51 |
ayoung | roxanaghe, so there is one case where we want ot explicitly convert? | 22:51 |
ayoung | or, some other project did? | 22:51 |
roxanaghe | if we change it with enforce_type=True always it will break a lot of other code mostly because people use None as values and they want None not the string 'None' | 22:52 |
roxanaghe | *None as an override value | 22:53 |
ayoung | roxanaghe, what is the default you set in upstream? | 22:53 |
roxanaghe | ayoung, False | 22:53 |
ayoung | roxanaghe, so that is no change in default behavior,right 4 | 22:54 |
ayoung | ? | 22:54 |
roxanaghe | because that was the behaviour previously - it would override the config with whatever value you pass to the function, I added the enforcement part | 22:55 |
roxanaghe | ayoung, right | 22:55 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Disable memory caching of tokens https://review.openstack.org/212345 | 22:55 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Seperate standalone cache tests https://review.openstack.org/212344 | 22:55 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Handle memcache pool arguments collectively https://review.openstack.org/212341 | 22:55 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Import _memcache_pool normally https://review.openstack.org/212343 | 22:55 |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Create Environment cache pool https://review.openstack.org/212342 | 22:55 |
*** hrou has quit IRC | 22:55 | |
*** morganfainberg is now known as morgan_404 | 22:57 | |
*** woodster_ has quit IRC | 23:00 | |
openstackgerrit | Roxana Gherle proposed openstack/keystone: Maintain datatypes when loading configs from DB https://review.openstack.org/212816 | 23:03 |
*** ayoung has quit IRC | 23:07 | |
*** jamielennox is now known as jamielennox|away | 23:18 | |
*** stevemar has quit IRC | 23:20 | |
*** stevemar has joined #openstack-keystone | 23:21 | |
*** ChanServ sets mode: +v stevemar | 23:21 | |
*** geoffarnold has quit IRC | 23:22 | |
*** stevemar has quit IRC | 23:24 | |
*** spandhe has joined #openstack-keystone | 23:26 | |
*** geoffarnold has joined #openstack-keystone | 23:32 | |
*** gildub has joined #openstack-keystone | 23:36 | |
openstackgerrit | Brant Knudson proposed openstack/keystone: Fix logging in federation/idp.py https://review.openstack.org/203047 | 23:41 |
openstackgerrit | Brant Knudson proposed openstack/keystone: Enhance tests for saml2 signing exception logging https://review.openstack.org/212845 | 23:41 |
*** zzzeek has quit IRC | 23:42 | |
openstackgerrit | Brant Knudson proposed openstack/keystone: Fix logging in federation/idp.py https://review.openstack.org/203047 | 23:43 |
openstackgerrit | Brant Knudson proposed openstack/keystone: Enhance tests for saml2 signing exception logging https://review.openstack.org/212845 | 23:43 |
*** jamielennox|away is now known as jamielennox | 23:47 | |
openstackgerrit | Brant Knudson proposed openstack/keystone: Documentation for other services https://review.openstack.org/204801 | 23:48 |
*** markvoelker has quit IRC | 23:50 | |
*** topol has joined #openstack-keystone | 23:57 | |
*** ChanServ sets mode: +v topol | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!