notmorgan | not opposed to the opt having the info encoded in it that this is something you may want to prompt for | 00:00 |
---|---|---|
mordred | me either | 00:00 |
notmorgan | i think that is reasonable | 00:00 |
notmorgan | it's the actual prompting i don't want | 00:00 |
notmorgan | in ksa | 00:00 |
jamielennox | so the way we're pushing atm this would become OCC's job | 00:01 |
jamielennox | because OSC is pushing that way | 00:01 |
mordred | jamielennox: so - occ wants to stich together all of the possible opt sources into one version of truth - but it wants ksa to know what are the list of args it should be stiching together | 00:01 |
jamielennox | sure, but if password is unfilled then it would be OCC that has to prompt so it can be the one version | 00:02 |
jamielennox | i was picking through OCC the other day, i didn'trealize you actually updated the cloud dict if values were missing | 00:02 |
mordred | I don't think so - that's a thing that's really only useful in interactive programs - I have a hard time imagining where/how occ would even know to do a prompting ... but gimme a sec and lemme think about that more ... | 00:03 |
notmorgan | OCC has real user-facing interactions though | 00:03 |
notmorgan | so that wouldn't be the worst place.. but likely the consumer of OCC (or the gcloud init thing) would prompt | 00:04 |
mordred | occ _does_ instantiate from ksa to verify that the auth arguments are valid so that it can give an error | 00:04 |
mordred | maybe OCC is the thing that you'd pass a prompt callback to | 00:04 |
notmorgan | mordred: i could see that | 00:04 |
mordred | and if you don't pass one in, it would never do it - but if you do, it can inject it to the right place in the data collection | 00:04 |
mordred | so, like, right before it asks ksa to validate the auth params | 00:05 |
mordred | it checks the list from ksa, sees if any are marked as prompt - and if they are and are missing, it tries calling the prompt callback | 00:05 |
mordred | (we could also put the prompt callback code _in_ occ) | 00:06 |
mordred | because osc and nova client both might want to choose to enable prompting | 00:06 |
mordred | (and, in fact, both do) | 00:06 |
mordred | so you could say get_one_cloud(prompt_callback=occ.prompt_callback) or something | 00:06 |
mordred | oh - yea | 00:09 |
mordred | this will actually be reasonably clean/easy | 00:09 |
mordred | in _validate_auth | 00:09 |
mordred | we already have a loop over plugin options | 00:09 |
mordred | would be SUPER easy to call a callback if one is required and missing and labeled prompt_for_value | 00:10 |
jamielennox | yep, this was something i didn't understand about occ until i went looking into this that it tries to create the full dictionary there as well as the auth plugin | 00:10 |
jamielennox | so it's doing that loop anyway | 00:10 |
*** chlong has quit IRC | 00:13 | |
*** jerrygb has quit IRC | 00:15 | |
mordred | jamielennox: something like this: https://review.openstack.org/253969 | 00:15 |
mordred | notmorgan: ^^ | 00:15 |
mordred | NOT TESTED AT ALL - that's just tossed up for discussion | 00:15 |
notmorgan | mordred: very much like that | 00:16 |
notmorgan | _VERY_ much just like that | 00:16 |
jamielennox | mordred: would you bother doing the getpass check? | 00:16 |
jamielennox | that would seem to be osc's job if it's available | 00:17 |
mordred | jamielennox: what do you mena? | 00:17 |
jamielennox | grr, see if we didn't actually re-populate the config['auth'] dict there that's exactly what's in ksa | 00:18 |
mordred | I have to rebuild the auth dict though because of OS_USERNAME and friends - I'm not guaranteed to get the auth params in the auth dict | 00:18 |
jamielennox | mordred: well if you're going to callback for missing options you may as well call back for all missing options and do the getpass check in the callback | 00:18 |
mordred | jamielennox: OH!!! | 00:19 |
mordred | jamielennox: yeah - I totally get what you mean | 00:19 |
mordred | yeah - I like that | 00:19 |
mordred | jamielennox: https://review.openstack.org/253969 updated with that in mind | 00:19 |
jamielennox | also as a nit i'd call it auth_prompt_callback as you're not doing it for everything | 00:20 |
mordred | well, I like your thing better | 00:20 |
mordred | call the callback on everything | 00:20 |
mordred | and let the callback have smarts | 00:20 |
jamielennox | it's still auth_ unless you start prompting for like OS_IMAGE_API_VERSION | 00:20 |
mordred | oh - nod | 00:21 |
mordred | done | 00:21 |
*** mylu_ has quit IRC | 00:21 | |
jamielennox | yea, that seems simple enough | 00:22 |
jamielennox | i wonder if that solves deans' auth_config_hook | 00:22 |
*** mylu has joined #openstack-keystone | 00:22 | |
mordred | you konw - maybe in addition to the p_opt we should pass the plugin loader too | 00:22 |
mordred | because in addition to password - one might want an oauth "trigger a browser window open" sort of thing | 00:22 |
jamielennox | i can see OSC needing that | 00:22 |
mordred | let's add it, why not | 00:23 |
*** gildub has joined #openstack-keystone | 00:24 | |
notmorgan | mordred: i kindof like that | 00:24 |
notmorgan | jamielennox: OSC may not need it | 00:24 |
notmorgan | but other consumers might find it useful | 00:24 |
notmorgan | ... also if i get my way and i get everyone to deploy openstack as <api>.<cloud>/<service> | 00:24 |
jamielennox | i can see special casing | 00:24 |
notmorgan | oauth becomes much more interesting | 00:24 |
mordred | can you use abc on non-class functions? :) | 00:25 |
mordred | I feel bad I can't put in a data type in the doc string | 00:25 |
jamielennox | if isinstance(loader, password) and opt.name == 'xxx': | 00:25 |
*** dims has quit IRC | 00:25 | |
mordred | ++ | 00:25 |
mordred | would be a simple way forward for the password case | 00:25 |
*** dims has joined #openstack-keystone | 00:26 | |
jamielennox | in this case i might just leave the param off ksa.opt for a bit and see if we can do it from ksa just special casing things | 00:26 |
mordred | jamielennox: ++ | 00:27 |
*** mylu has quit IRC | 00:27 | |
*** chlong has joined #openstack-keystone | 00:27 | |
jamielennox | i still think we'll want it for like saml plugins in future, but i'm not too worried about that for now | 00:27 |
mordred | jamielennox: yup. I think special casing will get us down the road | 00:27 |
mordred | jamielennox: do you think we should put the default prompting function in occ so that it's easy for consumers to reuse? or skip that and just have that live in both osc and novaclient? | 00:27 |
*** mylu has joined #openstack-keystone | 00:28 | |
jamielennox | if we're not doing the opt.getpass thing in ksa then i'd leave it | 00:28 |
jamielennox | oh, novaclient... | 00:29 |
jamielennox | bah | 00:29 |
jamielennox | if it were using opt.getpass i think it'd be ok in OCC, if you want to do special case handling i'd prefer to leave that to OSC | 00:29 |
mordred | well, I know that novaclient is going to want me to deal with this - my original take on it was going to be a loud and grumpy "meh" | 00:30 |
jamielennox | mordred: actually have you seen https://review.openstack.org/#/c/243348/ | 00:30 |
mordred | yah - I tink that's awesome | 00:31 |
mordred | I'm moving novaclient and friends to occ/ksa as a stepping stone to making that transition easier for people | 00:31 |
jamielennox | so it's not like an openstack-specs spec has any real impact, but it means we could tell novaclient CLI to stop running there own thing because the whole community said to move | 00:32 |
jamielennox | s/real impact/direct impact | 00:32 |
jamielennox | also i've no idea what you need to do to get a +A there | 00:32 |
mordred | because it's super frustrating to be using osc with a clouds.yaml and then need to fall back to a *client for something that isn't there yet and have to source a random openrc file or something | 00:32 |
mordred | I tink ttx eventually does something | 00:32 |
*** dims has quit IRC | 00:35 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/python-keystoneclient: Initialize /v2_0 and /v3 functional tests dirs https://review.openstack.org/253970 | 00:35 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/python-keystoneclient: WIP: Implements base class for functional tests https://review.openstack.org/253971 | 00:36 |
samueldmq | jamielennox: mordred: ^this is the very very beginning of improving functional tests on the client, as I see them | 00:36 |
samueldmq | would be glad to get an initial couple of eyes on them | 00:37 |
samueldmq | I am basically importing keystoneclient (expecting it's getting the one installed by devstack in its env), instantiating the client, and doing some testing | 00:37 |
samueldmq | (for now just creating a user) | 00:38 |
openstackgerrit | Brad Topol proposed openstack/keystone: Deprecate ldap Role https://review.openstack.org/252669 | 00:38 |
jamielennox | samueldmq: i'm not sure how you recieve credentials for functional tests, i think it's the standard OS_ variables | 00:38 |
jamielennox | so you'd want to do the plugin probably via load_from_argparse_arguments | 00:38 |
jamielennox | i don't know how you test auth that way.. | 00:39 |
notmorgan | ayoung: api.tempusfrangit.org/dashboard | 00:39 |
jamielennox | oh - ksc, we don't need to test auth | 00:39 |
notmorgan | ayoung: it mostly works [don't boot instances] | 00:39 |
samueldmq | jamielennox: ++ | 00:39 |
mordred | there's actually an oslotest fixture for getting creds | 00:39 |
notmorgan | ayoung: but the dashboard is all there. | 00:39 |
jamielennox | mordred: oh? i bet that's doing it wrong :) | 00:40 |
samueldmq | jamielennox: what is that ? load_from_argparse_arguments | 00:40 |
mordred | jamielennox: I wrote it :) | 00:40 |
samueldmq | jamielennox: is it the way OS_ variables are provided ? | 00:40 |
mordred | jamielennox: one sec - getting link | 00:40 |
mordred | no - don't use those | 00:40 |
samueldmq | mordred: kk | 00:40 |
mordred | use the clouds.yaml we write - it has both admin and non-admin users defined | 00:40 |
jamielennox | samueldmq: it's a way of loading auth from CLI arguments, but when the CLI args aren't available it defaults to env, so you could use it with an empty argv | 00:40 |
mordred | one sec - getting link for example of usage | 00:40 |
* notmorgan uses all the OS_<variables> just cause mordred said dont (*pre-emptive duck of wet cat*) | 00:41 | |
jamielennox | heh, whoops | 00:41 |
*** topol has quit IRC | 00:42 | |
mordred | oh - piddle | 00:42 |
samueldmq | jamielennox: so when calling the functional tests via tox, one could provide the arguments via that command? like: | 00:42 |
mordred | this is not using the fixture: | 00:42 |
mordred | http://git.openstack.org/cgit/openstack/python-glanceclient/tree/glanceclient/tests/functional/base.py | 00:42 |
mordred | samueldmq: ^^ | 00:42 |
samueldmq | tox -e functioanl user=a password=b and so on ? | 00:43 |
samueldmq | jamielennox: ^ | 00:43 |
samueldmq | or if not, we would get from env | 00:43 |
samueldmq | mordred: looking | 00:43 |
jamielennox | samueldmq: it was designed for CLI like --os-auth-type, i wouldn't suggest passing them through tox | 00:43 |
mordred | http://git.openstack.org/cgit/openstack/oslotest/tree/oslotest/functional.py | 00:44 |
mordred | is the thing in oslotest | 00:44 |
samueldmq | jamielennox: so that doesnt' apply to that work on functional tests ? | 00:44 |
jamielennox | mordred: all that work and glanceclient then rips the creds['username'] out to do functional tests :( | 00:44 |
mordred | looks like nothing is usin git yet : | 00:44 |
samueldmq | jamielennox: like the creds can't be passed for running the functional tests that way | 00:44 |
mordred | jamielennox: well - it was a start | 00:44 |
mordred | novaclient: http://git.openstack.org/cgit/openstack/python-novaclient/tree/novaclient/tests/functional/base.py | 00:45 |
jamielennox | samueldmq: i know some of the other clients used to look for the OS_ environment variables directly | 00:45 |
* mordred is slowly working on migrating all of those clients, fwiw | 00:45 | |
samueldmq | jamielennox: would that be acceptable for us to start ? | 00:45 |
mordred | please no | 00:45 |
mordred | please use the clouds.yaml file | 00:45 |
samueldmq | mordred: :-) | 00:45 |
jamielennox | samueldmq: yea, use the oslotest hook mordred is suggesting | 00:45 |
jamielennox | mordred: ksc -> ksa you mean? | 00:46 |
samueldmq | mordred: and that's what that os_client_config do ? | 00:46 |
mordred | it'll make you happier | 00:46 |
mordred | samueldmq: yah | 00:46 |
jamielennox | swift is the only one i'm aware of that doesn't do either | 00:46 |
mordred | jamielennox: so many things- ksc -> ksa , functional tests using clouds.yaml | 00:46 |
mordred | client utils using clouds.yaml/occ - servers using ksa | 00:46 |
mordred | TOO MANY TASKS!!! | 00:46 |
samueldmq | cool, where can I learn about clouds.yaml ? | 00:47 |
jamielennox | mordred: i've heard you have people that work for you that know this stuff | 00:47 |
samueldmq | I need to start there, then look at the existing examples | 00:47 |
mordred | (although jamielennox did you see https://review.openstack.org/#/c/253783/ ) ? | 00:47 |
mordred | samueldmq: http://docs.openstack.org/developer/os-client-config/ | 00:47 |
mordred | samueldmq: devstack writes a clouds.yaml to /etc/openstack that defines too clouds "devstack" and "devstack-admin" | 00:48 |
mordred | the "devstack" cloud is the unprivileged user, the devstack-admin cloud is the admin user | 00:48 |
samueldmq | hmm, that's very very interesting actually, thanks for the link mordred | 00:48 |
mordred | samueldmq: woot! | 00:48 |
mordred | jamielennox: hah. you make it sound like I could get the people who work for me to do what I told them to :) | 00:49 |
samueldmq | mordred: and at the end all the deployer (wanting to run the tests against his cloud) needs to do is to write or provide something os-client-config understands | 00:49 |
jamielennox | oh - nice | 00:49 |
samueldmq | jamielennox: mordred: gotta sleep now, talk to you tomorrow | 00:52 |
samueldmq | g'night | 00:52 |
*** miyagishi_t has joined #openstack-keystone | 00:53 | |
mordred | night samueldmq ! | 00:55 |
openstackgerrit | Merged openstack/keystoneauth: Add BetaMax Fixture https://review.openstack.org/250476 | 00:56 |
*** chlong has quit IRC | 01:01 | |
ayoung | notmorgan, I'm in | 01:04 |
*** EinstCrazy has joined #openstack-keystone | 01:04 | |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Don't like deprecated opts in sample config https://review.openstack.org/253972 | 01:04 |
notmorgan | ayoung: i am chasing down an issue with "cannot get volume information" | 01:05 |
ayoung | notmorgan, "Error: Unable to retrieve volume limit information" We've seen that before. Looks at the config | 01:05 |
notmorgan | yeah | 01:05 |
ayoung | for nova and for cinder...there is a two way set up there that needs t o be done. | 01:05 |
ayoung | I have a link in roppowam..one sec | 01:05 |
notmorgan | 2015-12-07 01:04:37.783 16796 ERROR cinder.api.middleware.fault [req-5c710c42-26df-406d-a26d-ef11de50c7ba dec22eac2f0a4973bf83e481a539d434 114a5f90aed44c408f3b4e49b5aff709 - - -] Caught error: SSL exception connecting to https://api.tempusfrangit.org/identity/v3/projects/114a5f90aed44c408f3b4e49b5aff709: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate | 01:05 |
notmorgan | verify failed | 01:05 |
notmorgan | something somewhere is having SSL issues | 01:05 |
ayoung | notmorgan, https://github.com/admiyo/rippowam/blob/master/roles/packstack/tasks/serviceauth.yml | 01:06 |
notmorgan | yeah this is something in the cinder log | 01:06 |
ayoung | notmorgan, the requests issue? | 01:06 |
notmorgan | so... | 01:06 |
notmorgan | yeah this is requests | 01:06 |
ayoung | cinder needs to call back to nova | 01:06 |
notmorgan | but i don't know where/how i can say "insecure" | 01:06 |
notmorgan | yeah | 01:06 |
ayoung | you need to configure a second section in cinder.conf | 01:07 |
notmorgan | so, something is busted... i *think* i know what it is though | 01:07 |
ayoung | https://github.com/admiyo/rippowam/blob/master/roles/packstack/tasks/serviceauth.yml#L16 | 01:07 |
notmorgan | rigth | 01:07 |
ayoung | when cinder calls nova, it uses different auth info for some reason | 01:07 |
ayoung | same thing is an issue with neutron to nova for the callback "port's connected" | 01:07 |
notmorgan | i have that configured i just don't know where to say "insecure" | 01:08 |
ayoung | jamielennox, ^^ question for you | 01:08 |
notmorgan | it's having issues hitting the letsencrypt TLS endpoint | 01:08 |
notmorgan | api. is useing a *real* SSL cert from letsencrypt | 01:08 |
ayoung | notmorgan, what if you add the letsencryp generated CA to the requests bundle? | 01:09 |
ayoung | would that be a better way to go? | 01:09 |
notmorgan | requests doesn't use system CA | 01:09 |
notmorgan | =/ | 01:09 |
notmorgan | it's kindof a point of ... i'm annoyed with requests | 01:10 |
notmorgan | over | 01:10 |
notmorgan | they role their own ca bundle. | 01:10 |
ayoung | in that section you can try | 01:10 |
ayoung | verify=false | 01:10 |
notmorgan | which config section? | 01:10 |
notmorgan | oh hah in the code | 01:11 |
notmorgan | yes | 01:11 |
notmorgan | i'm trying to do it with config first | 01:11 |
jamielennox | ayoung: sorry what | 01:23 |
notmorgan | jamielennox: trying to figure out how to get cinder to do verify=False when it's talking to keystone to look up project info | 01:23 |
jamielennox | insecure=True in conf from memory | 01:24 |
ayoung | jamielennox, notmorgan is doing a POC with https, but needs to avoid cert issues, so trying to do a "insecure" when one service is taolking to another | 01:24 |
ayoung | thanks | 01:24 |
ayoung | jamielennox, you know how to add to the requests bundler? | 01:24 |
notmorgan | jamielennox: it's Volume limit data? | 01:24 |
notmorgan | ayoung: certifi package | 01:24 |
jamielennox | ayoung: your email is sitting there unread and taunting me because i feel it's going to be a rabbit whole to wihch i loose a week | 01:24 |
notmorgan | ayoung: it's ultimately doable but me | 01:24 |
notmorgan | h | 01:24 |
ayoung | a whole Rabbit, maybe? | 01:25 |
ayoung | jamielennox, but, not really. | 01:25 |
notmorgan | ugh... | 01:25 |
jamielennox | ayoung: yea, but i have all this WIP stuff around how to change policy enforcement | 01:25 |
ayoung | just the start of an etherpad on how to do URL based auth | 01:25 |
ayoung | jamielennox, just keep on it, then | 01:26 |
notmorgan | jamielennox, ayoung: yep not configuable | 01:26 |
notmorgan | http://paste.openstack.org/show/480974/ | 01:26 |
notmorgan | joy | 01:26 |
* notmorgan sighs. | 01:26 | |
jamielennox | ayoung: nah - it's fine, i agree that the keys in policy make no senes | 01:26 |
jamielennox | also i love that it's "first quack at ..." | 01:27 |
notmorgan | really this is why requests irritates me. | 01:27 |
notmorgan | use.the.system.ca.info | 01:27 |
notmorgan | seriously | 01:27 |
jamielennox | notmorgan: define your own in env | 01:27 |
jamielennox | or use the system package | 01:27 |
notmorgan | jamielennox: requests uses certifi | 01:27 |
notmorgan | it doesn't use the linux system CAs | 01:28 |
jamielennox | i know | 01:28 |
notmorgan | it's stupid. | 01:28 |
jamielennox | but all the system packages fix that | 01:28 |
notmorgan | and i don't *want* to use the system packages when i'm hacking on things | 01:28 |
notmorgan | i am using VENVs for a reason | 01:28 |
jamielennox | notmorgan: https://github.com/kennethreitz/requests/blob/master/requests/sessions.py#L624 | 01:28 |
jamielennox | set REQUESTS_CA_BUNDLE in env | 01:28 |
notmorgan | again | 01:28 |
notmorgan | horrible | 01:28 |
notmorgan | it shouldn't be needed like that | 01:29 |
notmorgan | this is a stupid choice on requests side | 01:29 |
jamielennox | notmorgan: agreed | 01:29 |
notmorgan | they should default to let us use the system CA | 01:29 |
jamielennox | so there was a thread about this on the ML a while ago | 01:29 |
jamielennox | that maybe ksa should default this above requests | 01:29 |
notmorgan | probably | 01:30 |
notmorgan | or we should fork requests and stop vendoring urllib3 and do system ca things | 01:30 |
notmorgan | for openstack | 01:30 |
jamielennox | notmorgan: hoewver i don't want to deal with all the different system cas either | 01:30 |
notmorgan | jamielennox: so for linux there are very few places | 01:30 |
jamielennox | if i wrote ksa again i'd use urllib3 directly | 01:31 |
jamielennox | but | 01:31 |
notmorgan | jamielennox: we *could* do that . | 01:31 |
notmorgan | i mean, the interfaces would look very similar even if we used urllib3 | 01:31 |
jamielennox | if you're doing this via ansible just set cacert wherever you're doing insecure = | 01:31 |
notmorgan | no, this is a hand-configured openstack cloud | 01:32 |
jamielennox | there's a couple of places we export requests stuff directly | 01:32 |
*** jed56 has quit IRC | 01:32 | |
notmorgan | because nothing works with sub-mounted urls | 01:32 |
*** jed56 has joined #openstack-keystone | 01:32 | |
notmorgan | jamielennox: http://paste.openstack.org/show/480971/ | 01:32 |
jamielennox | ayoung: so that's not that big a proposal | 01:32 |
jamielennox | what would happen if the keys changed though | 01:32 |
jamielennox | like user_id is just a key for substitution | 01:33 |
notmorgan | jamielennox: anyway...... | 01:33 |
* notmorgan grumbles | 01:34 | |
ayoung | jamielennox, in the policy-by-url approach? | 01:34 |
ayoung | hmmm | 01:34 |
ayoung | jamielennox, not sure what you mean there? | 01:35 |
*** wangqun has joined #openstack-keystone | 01:36 | |
stevemar | o/ | 01:43 |
notmorgan | jamielennox: setting that env var doesn't work well | 01:44 |
notmorgan | because eventlet etc | 01:45 |
notmorgan | its... | 01:45 |
notmorgan | frustrating... i can fix it but gah. | 01:45 |
notmorgan | this is terrible | 01:45 |
*** ayoung has quit IRC | 02:02 | |
*** navidp has joined #openstack-keystone | 02:05 | |
*** navidp has quit IRC | 02:07 | |
*** navidp has joined #openstack-keystone | 02:07 | |
*** navidp has quit IRC | 02:12 | |
*** diegows has joined #openstack-keystone | 02:27 | |
jamielennox | notmorgan: why does eventlet change the env var? | 02:32 |
*** navidp has joined #openstack-keystone | 02:35 | |
*** navidp has quit IRC | 02:35 | |
mordred | notmorgan, jamielennox: I updated that patch again, this time with a copy of the novaclient prompting function added in | 02:36 |
mordred | https://review.openstack.org/#/c/253969/ | 02:36 |
notmorgan | jamielennox: it's because it spins up separate processes and it loses envs | 02:36 |
*** chlong has joined #openstack-keystone | 02:36 | |
openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Don't list deprecated opts in sample config https://review.openstack.org/253972 | 02:37 |
notmorgan | jamielennox: so, out of curiosity... is there a way in KSC to register auth options from auth.register_conf_options(CONF, NEUTRON_GROUP) but then have them torn down at the end? | 02:37 |
notmorgan | jamielennox: i don't... think we have a fixture way to handle that | 02:37 |
jamielennox | notmorgan: i'm not sure what you mean | 02:37 |
*** jamielennox has left #openstack-keystone | 02:37 | |
*** jamielennox has joined #openstack-keystone | 02:37 | |
*** ChanServ sets mode: +v jamielennox | 02:37 | |
notmorgan | jamielennox: CONF is global | 02:37 |
notmorgan | jamielennox: registering opts is a one-time thing | 02:38 |
notmorgan | ksc.auth/ksa will not de-register the options in tests for example | 02:38 |
notmorgan | i'm wondering if it matters. | 02:38 |
* notmorgan thinks not... | 02:38 | |
jamielennox | notmorgan: mostly for tests we want to use the conf fixture to isolate that sort of thing anyway | 02:39 |
jamielennox | whether projects do that or not... | 02:39 |
jamielennox | this is how we ended up with that horrible hack in auth_token middleware as well | 02:40 |
notmorgan | yeah | 02:40 |
*** navid_ has left #openstack-keystone | 02:40 | |
notmorgan | ok i'll do something here... | 02:40 |
mordred | notmorgan: updated | 02:41 |
*** navid_ has joined #openstack-keystone | 02:41 | |
jamielennox | mordred: why would i want verify? | 02:42 |
jamielennox | also, i don't really mind but i think the abc is overkill, i know notmorgan asked for that | 02:43 |
*** links has joined #openstack-keystone | 02:45 | |
*** navid_ has quit IRC | 02:46 | |
*** mylu has quit IRC | 02:47 | |
mordred | jamielennox: I was basically doing that to make a way to commuicate the type expected in the doc string | 02:49 |
mordred | jamielennox: I also agree- it's a bit heavy | 02:49 |
*** yangyapeng has joined #openstack-keystone | 02:49 | |
*** diegows has quit IRC | 02:50 | |
mordred | jamielennox: for verify - that's mainly there just cause I ported in the code from novaclient and that's what they do | 02:52 |
jamielennox | stevemar: you back/ | 03:23 |
*** btully has joined #openstack-keystone | 03:46 | |
*** mylu has joined #openstack-keystone | 03:56 | |
*** btully has quit IRC | 03:56 | |
*** flwang1 has quit IRC | 04:00 | |
*** amakarov has quit IRC | 04:02 | |
*** dims has joined #openstack-keystone | 04:03 | |
*** wanghua has quit IRC | 04:03 | |
*** ayoung has joined #openstack-keystone | 04:09 | |
*** ChanServ sets mode: +v ayoung | 04:09 | |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Extract SAML fixtures into templates https://review.openstack.org/253999 | 04:16 |
openstackgerrit | Stanislaw Pitucha proposed openstack/keystone: Fix multiline strings with missing spaces https://review.openstack.org/254000 | 04:17 |
stevemar | jamielennox aye aye | 04:22 |
jamielennox | stevemar: how was the break? | 04:22 |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Extract SAML fixtures into templates https://review.openstack.org/253999 | 04:26 |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Get versioned url for K2K auth https://review.openstack.org/251686 | 04:30 |
openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Cleanups to K2K plugin https://review.openstack.org/251687 | 04:30 |
*** dims has quit IRC | 04:34 | |
*** btully has joined #openstack-keystone | 05:03 | |
*** chlong has quit IRC | 05:05 | |
stevemar | jamielennox: just took thursday/friday off, i spent most of thursday trying to find internet access so i could confirm m-1 was released | 05:14 |
stevemar | among other things related to release | 05:14 |
stevemar | glad to see it went through fine though | 05:14 |
stevemar | i have a lot of stuff and things to do tomorrow, but i'll save that for tomorrow | 05:15 |
stevemar | i went through all my email today, looks like nothing too crazy happened, aside from a ksa point release | 05:15 |
jamielennox | stevemar: yea, i didn't expect to see you around at all | 05:15 |
jamielennox | save it for the week | 05:16 |
*** chlong has joined #openstack-keystone | 05:22 | |
stevemar | jamielennox: yeah, i'll go through the specs monday morning, i think henry and gyee have some issues with domain roles | 05:24 |
*** dims has joined #openstack-keystone | 05:24 | |
*** Nirupama has joined #openstack-keystone | 05:26 | |
*** mylu has quit IRC | 05:32 | |
*** mylu has joined #openstack-keystone | 05:34 | |
*** dims has quit IRC | 05:46 | |
*** roxanaghe has joined #openstack-keystone | 05:59 | |
*** mylu has quit IRC | 05:59 | |
*** mylu has joined #openstack-keystone | 05:59 | |
*** navidp has joined #openstack-keystone | 06:14 | |
*** dims has joined #openstack-keystone | 06:32 | |
*** boris-42_ has quit IRC | 06:33 | |
*** jaosorior has joined #openstack-keystone | 06:39 | |
*** dims has quit IRC | 06:45 | |
*** openstackgerrit_ has joined #openstack-keystone | 06:51 | |
*** dims has joined #openstack-keystone | 06:52 | |
*** roxanaghe has quit IRC | 06:55 | |
*** josecastroleon has joined #openstack-keystone | 07:02 | |
*** mylu has quit IRC | 07:03 | |
openstackgerrit | Merged openstack/keystoneauth: Get versioned url for K2K auth https://review.openstack.org/251686 | 07:05 |
*** wanghua has joined #openstack-keystone | 07:22 | |
*** chlong has quit IRC | 07:29 | |
*** gildub has quit IRC | 07:32 | |
*** btully has quit IRC | 07:43 | |
*** amakarov has joined #openstack-keystone | 07:52 | |
*** henrynash has joined #openstack-keystone | 07:56 | |
*** ChanServ sets mode: +v henrynash | 07:56 | |
openstackgerrit | ChangBo Guo(gcb) proposed openstack/oslo.policy: Don't generate doc from test https://review.openstack.org/254061 | 08:12 |
*** ntt has joined #openstack-keystone | 08:18 | |
*** e0ne has joined #openstack-keystone | 08:31 | |
*** fhubik has joined #openstack-keystone | 08:39 | |
*** e0ne has quit IRC | 08:55 | |
*** mkoderer has quit IRC | 08:59 | |
*** mkoderer has joined #openstack-keystone | 09:00 | |
*** e0ne has joined #openstack-keystone | 09:00 | |
*** e0ne has quit IRC | 09:03 | |
*** fhubik is now known as fhubik_brb | 09:07 | |
*** fhubik_brb is now known as fhubik | 09:08 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystoneauth: Updated from global requirements https://review.openstack.org/254088 | 09:10 |
*** flwang1 has joined #openstack-keystone | 09:27 | |
*** jistr has joined #openstack-keystone | 09:36 | |
*** flwang1 has quit IRC | 09:42 | |
*** btully has joined #openstack-keystone | 09:45 | |
*** flwang1 has joined #openstack-keystone | 09:46 | |
*** dims has quit IRC | 09:48 | |
*** flwang1 has quit IRC | 09:50 | |
*** mhickey has joined #openstack-keystone | 09:53 | |
*** flwang1 has joined #openstack-keystone | 09:55 | |
*** e0ne has joined #openstack-keystone | 09:56 | |
*** aix has joined #openstack-keystone | 10:19 | |
*** cburgess has quit IRC | 10:22 | |
*** openstackgerrit_ has quit IRC | 10:23 | |
*** cburgess has joined #openstack-keystone | 10:27 | |
*** jistr has quit IRC | 10:29 | |
*** jistr has joined #openstack-keystone | 10:30 | |
*** ccard_ has joined #openstack-keystone | 10:30 | |
openstackgerrit | Mehdi Abaakouk (sileht) proposed openstack/keystonemiddleware: Keystonemiddleware shouldn't list options of other lib https://review.openstack.org/252373 | 10:31 |
*** cburgess has quit IRC | 10:31 | |
*** sudorandom has quit IRC | 10:31 | |
*** cburgess has joined #openstack-keystone | 10:32 | |
ccard_ | We have a multi-site HA OpenStack installation, with a Galera cluster at each site. Currently, one of the sites is providing keystone to all the sites, so that they all see the same set of domains, projects, users etc., but clearly this centralised keystone is a single point of failure, so we want to be able to switch over quickly to one of the other sites running the keystone. The first thing that springs to mind is to | 10:36 |
ccard_ | replicate the keystone db to the other sites using MySQL async replication, so that the keystone db is available on all the sites. Does anyone have experience with such a set-up? Or is there a better solution? | 10:36 |
*** wangqun has quit IRC | 10:36 | |
*** fhubik is now known as fhubik_brb | 10:38 | |
*** fhubik_brb is now known as fhubik | 10:41 | |
*** sudorandom has joined #openstack-keystone | 10:41 | |
*** cburgess has quit IRC | 10:41 | |
*** cburgess has joined #openstack-keystone | 10:43 | |
*** johnthetubaguy has quit IRC | 10:43 | |
*** sudorandom has quit IRC | 10:46 | |
*** johnthetubaguy has joined #openstack-keystone | 10:49 | |
*** sudorandom has joined #openstack-keystone | 10:50 | |
*** cburgess has quit IRC | 10:56 | |
*** cburgess has joined #openstack-keystone | 10:59 | |
*** lhcheng has joined #openstack-keystone | 11:01 | |
*** ChanServ sets mode: +v lhcheng | 11:01 | |
*** yangyapeng has quit IRC | 11:17 | |
*** EinstCrazy has quit IRC | 11:17 | |
*** topol has joined #openstack-keystone | 11:19 | |
*** ChanServ sets mode: +v topol | 11:19 | |
*** fhubik is now known as fhubik_brb | 11:21 | |
*** johnthetubaguy has quit IRC | 11:21 | |
*** johnthetubaguy has joined #openstack-keystone | 11:21 | |
*** lhcheng_ has joined #openstack-keystone | 11:24 | |
*** miyagishi_t has quit IRC | 11:26 | |
*** lhcheng has quit IRC | 11:27 | |
*** jed56 has quit IRC | 11:27 | |
*** jed56 has joined #openstack-keystone | 11:28 | |
*** fhubik_brb is now known as fhubik | 11:30 | |
*** EinstCrazy has joined #openstack-keystone | 11:43 | |
*** lhcheng_ has quit IRC | 11:44 | |
*** fhubik is now known as fhubik_brb | 11:44 | |
*** lhcheng has joined #openstack-keystone | 11:44 | |
*** ChanServ sets mode: +v lhcheng | 11:44 | |
openstackgerrit | henry-nash proposed openstack/keystone-specs: An alternative to domain roles using implied roles https://review.openstack.org/254139 | 11:44 |
*** btully has quit IRC | 11:46 | |
openstackgerrit | henry-nash proposed openstack/keystone-specs: An alternative to domain roles using implied roles https://review.openstack.org/254139 | 11:48 |
*** noqa_v_q1ovnie is now known as noqa_v_qoovnie | 11:48 | |
openstackgerrit | henry-nash proposed openstack/keystone-specs: An alternative to domain roles using implied roles https://review.openstack.org/254139 | 11:50 |
*** fhubik_brb is now known as fhubik | 11:52 | |
*** iurygregory has joined #openstack-keystone | 11:52 | |
*** alexus is now known as alex_xu | 11:57 | |
openstackgerrit | javeme proposed openstack/python-keystoneclient: encode the url parameters https://review.openstack.org/254154 | 12:07 |
*** dims has joined #openstack-keystone | 12:08 | |
openstackgerrit | henry-nash proposed openstack/keystone-specs: An alternative to domain roles using implied roles https://review.openstack.org/254139 | 12:09 |
*** raildo-afk is now known as raildo | 12:14 | |
*** links has quit IRC | 12:15 | |
*** flaper87 has quit IRC | 12:17 | |
*** flaper87 has joined #openstack-keystone | 12:17 | |
*** doug-fish has joined #openstack-keystone | 12:19 | |
*** chlong has joined #openstack-keystone | 12:30 | |
*** Nirupama has quit IRC | 12:32 | |
*** jaosorior has quit IRC | 12:36 | |
*** jaosorior has joined #openstack-keystone | 12:37 | |
*** jaosorior has quit IRC | 12:38 | |
*** jaosorior has joined #openstack-keystone | 12:38 | |
*** gordc has joined #openstack-keystone | 12:39 | |
*** Nirupama has joined #openstack-keystone | 12:46 | |
*** mylu has joined #openstack-keystone | 12:48 | |
*** jed56 has quit IRC | 12:52 | |
*** jed56 has joined #openstack-keystone | 12:52 | |
*** mylu has quit IRC | 12:55 | |
*** fhubik is now known as fhubik_brb | 12:56 | |
*** fhubik_brb is now known as fhubik | 12:58 | |
*** fhubik is now known as fhubik_brb | 12:58 | |
*** pauloewerton has joined #openstack-keystone | 12:58 | |
mordred | jamielennox: any chance you're still around? | 13:00 |
*** thiagop has joined #openstack-keystone | 13:01 | |
*** Nirupama has quit IRC | 13:01 | |
*** wanghua_ has joined #openstack-keystone | 13:05 | |
*** wanghua has quit IRC | 13:05 | |
*** wanghua_ is now known as wanghua | 13:05 | |
openstackgerrit | javeme proposed openstack/python-keystoneclient: remove the default arguments "[]" or "{}" https://review.openstack.org/254175 | 13:06 |
*** Nirupama has joined #openstack-keystone | 13:17 | |
*** jed56 has quit IRC | 13:25 | |
*** jed56 has joined #openstack-keystone | 13:26 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Create unit tests for endpoint policy SQL driver https://review.openstack.org/212006 | 13:31 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Fixes query.one() return usage in endpoint-policy https://review.openstack.org/208609 | 13:34 |
*** edmondsw has joined #openstack-keystone | 13:39 | |
*** Ephur has joined #openstack-keystone | 13:41 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Create unit tests for the policy backend https://review.openstack.org/212957 | 13:41 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Create unit tests for the policy SQL driver https://review.openstack.org/212957 | 13:43 |
*** boris-42_ has joined #openstack-keystone | 13:52 | |
*** lhcheng_ has joined #openstack-keystone | 13:59 | |
*** lhcheng has quit IRC | 14:00 | |
*** Nirupama has quit IRC | 14:01 | |
*** jerrygb has joined #openstack-keystone | 14:04 | |
notmorgan | ayoung: so found the source/fix of the Volume limit info. it's a really badly written additon to cinder that is largely unconfigurable. | 14:09 |
ayoung | notmorgan, YAHOOO! | 14:09 |
notmorgan | ayoung: it is missing a lot of the ca/cert etc options that are everywhere else | 14:09 |
notmorgan | ayoung: let me show you. | 14:09 |
ayoung | Lets see it | 14:10 |
notmorgan | ayoung: https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L177-L196 | 14:11 |
notmorgan | absolutely no way to pass the extra info. | 14:11 |
notmorgan | and i had to directly update the CA Bundle in requests to make this work, the env var to point at a new CA bundle was lost when spinning up eventlet stuff | 14:12 |
notmorgan | so.. yay? =/ | 14:12 |
notmorgan | and the previous version was just as bad. | 14:12 |
notmorgan | getting people to use a common session object that handles these options sanely will solve it. | 14:13 |
notmorgan | but basically this will *never* work with non-trusted certs/cas and TLS | 14:13 |
*** wanghua has quit IRC | 14:13 | |
*** dims has quit IRC | 14:16 | |
notmorgan | ayoung: also really really easy +2/+A https://review.openstack.org/#/c/253966/ | 14:16 |
*** hogepodge has quit IRC | 14:17 | |
ayoung | notmorgan, done | 14:17 |
lbragstad | samueldmq responded - https://review.openstack.org/#/c/253669/1/test-requirements.txt | 14:17 |
*** Ephur has quit IRC | 14:17 | |
ayoung | notmorgan, I saw the link when you posted it last night. I assume that the values there should be read out of the config file the same way as auth_token is done, right? | 14:18 |
*** breitz has joined #openstack-keystone | 14:18 | |
notmorgan | ayoung: ugh. merge conflict | 14:18 |
notmorgan | ayoung: yeah basically that code needs to be re-worked to use proper configs | 14:19 |
notmorgan | ayoung: and the full range of configs ca-bundle etc | 14:19 |
openstackgerrit | Morgan Fainberg proposed openstack/keystonemiddleware: Use keystoneauth for auth_token fixture https://review.openstack.org/253966 | 14:19 |
ayoung | notmorgan, this is the point in the discussion where I need to block out that voice in my head calling for proper dependency injection in python. Too many times we couple consumetion with creationg...and get stuck like this. | 14:20 |
notmorgan | ayoung: this isn't even dependency injection. because it wouldn't have solved this really. | 14:20 |
notmorgan | it *could* solve it | 14:21 |
ayoung | notmorgan, yes it is, but I am not going down that path today.... | 14:21 |
notmorgan | but it's not guaranteed if someone just goes off and does "oh do X" | 14:21 |
notmorgan | so that aside | 14:21 |
notmorgan | ... | 14:21 |
notmorgan | added this to the ever-growing list of "broken" | 14:21 |
openstackgerrit | henry-nash proposed openstack/keystone: Create new version of assignment driver interface https://review.openstack.org/242853 | 14:23 |
*** marekd has quit IRC | 14:23 | |
*** marekd has joined #openstack-keystone | 14:23 | |
*** ChanServ sets mode: +v marekd | 14:23 | |
xek | bknudson, lbragstad, dstanek, please tell me what you think https://review.openstack.org/#/c/245186/ (my last comment) | 14:25 |
openstackgerrit | henry-nash proposed openstack/keystone: Create V9 Role Driver https://review.openstack.org/247805 | 14:26 |
*** petertr7_away is now known as petertr7 | 14:28 | |
openstackgerrit | henry-nash proposed openstack/keystone: Use list_role_assignments to get projects/domains for user https://review.openstack.org/242513 | 14:29 |
*** navidp has quit IRC | 14:29 | |
*** navidp has joined #openstack-keystone | 14:30 | |
*** yasu has joined #openstack-keystone | 14:32 | |
*** dims has joined #openstack-keystone | 14:34 | |
*** yasu has quit IRC | 14:39 | |
*** lhcheng_ has quit IRC | 14:40 | |
*** raginbajin has quit IRC | 14:44 | |
*** fawadkhaliq has joined #openstack-keystone | 14:44 | |
*** raginbajin has joined #openstack-keystone | 14:46 | |
marekd | stevemar: can we reiterate on https://review.openstack.org/#/c/188534/ ? | 14:47 |
*** rderose has joined #openstack-keystone | 14:49 | |
*** topol has quit IRC | 14:50 | |
*** andrewbogott has quit IRC | 14:52 | |
*** ctina has joined #openstack-keystone | 15:02 | |
*** dims has quit IRC | 15:02 | |
notmorgan | stevemar: so... neutron now uses KSA instead of KSC internally | 15:03 |
notmorgan | yay! | 15:04 |
notmorgan | nova will be next | 15:04 |
samueldmq | lbragstad: looking | 15:07 |
*** diazjf has joined #openstack-keystone | 15:12 | |
*** btully has joined #openstack-keystone | 15:12 | |
*** davechen has joined #openstack-keystone | 15:13 | |
*** hogepodge has joined #openstack-keystone | 15:14 | |
*** rderose has quit IRC | 15:15 | |
*** spotz_zzz is now known as spotz | 15:15 | |
*** ctina has quit IRC | 15:16 | |
*** ctina has joined #openstack-keystone | 15:16 | |
*** rderose has joined #openstack-keystone | 15:16 | |
*** henrynash has quit IRC | 15:17 | |
*** davechen1 has joined #openstack-keystone | 15:19 | |
*** tonytan4ever has joined #openstack-keystone | 15:19 | |
*** ctina_ has joined #openstack-keystone | 15:19 | |
*** fhubik_brb is now known as fhubik | 15:20 | |
*** davechen has quit IRC | 15:22 | |
*** ctina has quit IRC | 15:22 | |
*** sigmavirus24_awa is now known as sigmavirus24 | 15:22 | |
*** navid_ has joined #openstack-keystone | 15:25 | |
*** navid_ has quit IRC | 15:25 | |
*** timcline has joined #openstack-keystone | 15:26 | |
lbragstad | xek reviewing it now | 15:30 |
lbragstad | xek timcline is going to try and give it a review too, i was having a discussion with him on it a couple weeks ago | 15:30 |
lbragstad | i think he'll be able to provide some good feedback, too | 15:31 |
xek | lbragstad, ok, thanks! | 15:31 |
*** mylu has joined #openstack-keystone | 15:32 | |
openstackgerrit | Ronald Bradford proposed openstack/keystone: Use oslo.log provided method for log levels https://review.openstack.org/254253 | 15:32 |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Add checks for token data creep using jsonschema https://review.openstack.org/254258 | 15:39 |
lbragstad | samueldmq ^ versus https://review.openstack.org/#/c/253669/1 | 15:39 |
lbragstad | cc: dstanek ^ | 15:39 |
samueldmq | lbragstad: nice, looking | 15:40 |
samueldmq | lbragstad: I'd go with jsonschema | 15:41 |
samueldmq | lbragstad: since it's something we already include as dependency, and the code doesnt' look bad at all :) | 15:41 |
samueldmq | lbragstad: let's see what dstanek thinks about it | 15:41 |
lbragstad | samueldmq yeah, i don't think jsonschema is as readable as voluptuous but... o well | 15:41 |
samueldmq | lbragstad: I agree with you on that point | 15:42 |
*** mylu has quit IRC | 15:43 | |
openstackgerrit | Tom Cocozzello proposed openstack/keystone: WIP List assignments with names https://review.openstack.org/249958 | 15:46 |
*** fhubik is now known as fhubik_brb | 15:47 | |
*** ntt has quit IRC | 15:49 | |
*** fhubik_brb is now known as fhubik | 15:49 | |
*** pgbridge has joined #openstack-keystone | 15:50 | |
dstanek | samueldmq: thinks about what? | 15:50 |
*** fawadkhaliq has quit IRC | 15:51 | |
lbragstad | dstanek https://review.openstack.org/254258 vs. https://review.openstack.org/253669 | 15:52 |
lbragstad | they are fixing the same bug - but with two different approaches | 15:52 |
samueldmq | dstanek: yeah ^ :) | 15:53 |
*** slberger has joined #openstack-keystone | 15:56 | |
*** petertr7 is now known as petertr7_away | 15:57 | |
*** lhcheng has joined #openstack-keystone | 15:59 | |
*** ChanServ sets mode: +v lhcheng | 15:59 | |
dstanek | lbragstad: i'd rather stick to the json schema since it's something we have to know already | 16:02 |
lbragstad | dstanek makes sense | 16:03 |
lbragstad | i'll abandon the voluptuous approach | 16:03 |
samueldmq | dstanek: I think the same :) | 16:03 |
lbragstad | and rewrite the other patches using jsonschema | 16:03 |
dstanek | lbragstad: it may make sense to make a new test class that explicitly validates scoped and unscoped tokens so that it's not just a side effect of other tests | 16:03 |
samueldmq | lbragstad: ++ | 16:03 |
*** fhubik has quit IRC | 16:04 | |
openstackgerrit | Fernando Diaz proposed openstack/keystone: WIP: Opt-out certain Keystone Notifications https://review.openstack.org/253780 | 16:06 |
*** petertr7_away is now known as petertr7 | 16:08 | |
*** davechen has joined #openstack-keystone | 16:08 | |
*** henrynash has joined #openstack-keystone | 16:09 | |
*** ChanServ sets mode: +v henrynash | 16:09 | |
*** davechen1 has quit IRC | 16:10 | |
*** fawadkhaliq has joined #openstack-keystone | 16:24 | |
*** EinstCrazy has quit IRC | 16:26 | |
*** aix has quit IRC | 16:28 | |
notmorgan | join #openstack-ceilometer | 16:29 |
notmorgan | ugh | 16:29 |
*** slberger1 has joined #openstack-keystone | 16:29 | |
*** slberger has quit IRC | 16:30 | |
samueldmq | notmorgan: hehe, weechat ? :-) | 16:31 |
notmorgan | yes | 16:31 |
*** r-daneel has joined #openstack-keystone | 16:34 | |
*** alex_xu has quit IRC | 16:35 | |
openstackgerrit | Merged openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/251640 | 16:38 |
*** davechen has quit IRC | 16:39 | |
*** mhickey has quit IRC | 16:39 | |
henrynash | stevemar, gyee, ayoung, topol: so have tried to represent what the alternative API (as suggested by Guang) for domain roles would look like: https://review.openstack.org/#/c/254139/ | 16:41 |
dstanek | notmorgan: so close | 16:41 |
notmorgan | dstanek: right? | 16:41 |
*** mylu has joined #openstack-keystone | 16:41 | |
*** mylu has quit IRC | 16:42 | |
*** Guest18099 is now known as redrobot | 16:43 | |
*** alex_xu has joined #openstack-keystone | 16:43 | |
ayoung | henrynash, thanks....I still do not like the name role-group. It does not make sense to me to say "assign the user to this role-group on this project" when " "assign the user to this role on this project" makes sense. THis is why, though, I was thinking that domain-specific roles was not as good a name as something like "namespaced roles" or "roles you don't see in the token" but I think what we have is as good as we | 16:44 |
ayoung | are going to get | 16:44 |
*** ctina_ has quit IRC | 16:44 | |
ayoung | I don't think adding a new top level concept like role-groups will be less confusing. You know my arguments. | 16:44 |
henrynash | ayoung: as yo know, I’m nor arguing strongly for https://review.openstack.org/#/c/254139/ - but thought the only way to compare was to just show what that API would look like | 16:45 |
*** davechen has joined #openstack-keystone | 16:45 | |
henrynash | ayoung: I prefer the current (merged) approach | 16:47 |
ayoung | henrynash, yep. | 16:47 |
ayoung | henrynash, I do wonder if we are going to find another way to namespace roles beyond domains | 16:48 |
ayoung | henrynash, I could see a namespacing that we want to make queryable at the application level | 16:48 |
ayoung | wordpress:editor and so on | 16:48 |
*** david-lyle has joined #openstack-keystone | 16:49 | |
henrynash | ayoung: yes, I know we have discussed this (by service type is kind of the obvious one)…I just didn’t want to bit thay one off quite yet! | 16:49 |
ayoung | ++ | 16:49 |
ayoung | henrynash, it might make the concpet of "reuse the name role" more palatable, though, if we can plot that out | 16:50 |
*** links has joined #openstack-keystone | 16:53 | |
ayoung | henrynash, then the story is that global roles are for openstack servuices and show up in tokens. All other namespaced roles are queried by namespace | 16:53 |
ayoung | can you think of a case where domain scoped roles would need to be queried? | 16:53 |
henrynash | ayoung: you mean list roles by domain_id or so you mean “list all roles that are domain specific for any domain”? | 16:54 |
ayoung | henrynash, "I mean "give me all roles for user U that have roles assigned that are defined in domain D" | 16:55 |
*** topol has joined #openstack-keystone | 16:55 | |
*** ChanServ sets mode: +v topol | 16:55 | |
dstanek | xek: i'm a little confused as to when you'd update the schema | 16:55 |
henrynash | ayoung: not sure I can parse that sentance | 16:55 |
ayoung | henrynash, 'lets say tyou have a domain HAL. There is a role HAL:distinguished_engineer. the henrynash user gets the role HAL:distinguished_engineer assigned. Can you think of a case where you would ned to tlak to some service or application that would need to knwo that directly? | 16:57 |
*** ctina_ has joined #openstack-keystone | 16:58 | |
ayoung | pseudo code : select all roles_assignemtnt where user = hentryname and role_assingmnet.role.domain_name = 'HAL'; | 16:58 |
ayoung | gah | 16:58 |
lbragstad | dstanek do you happen to have any numbers on last friday's bug activity? | 16:58 |
ayoung | pseudo code : select * from roles_assignments where user.name = henrynash and role_assignmnet.role.domain_name = 'HAL'; | 16:59 |
dstanek | lbragstad: not yet. wasn't all that great though. i did a lot of driving to meet up with my boss so i lost a bit of time | 16:59 |
lbragstad | dstanek ah, no worries. i was just curious | 16:59 |
xek | dstanek, right now, the schema is always upgraded before running the new code, I don't suggest changing this behavior | 16:59 |
lbragstad | xek dstanek I think that's something we need to determine. We need to lay out all the expectations before hand | 17:00 |
henrynash | ayoung: so we need that for crud amangement, but I think in terms of how it is used, i *think* it would always be processed implicitely (i.e. we are building a token, so expacnd out the domain specific roles)….I don’t think an endpoint/service woudl ever do that expanding explicitely | 17:00 |
*** ninag has joined #openstack-keystone | 17:00 | |
dstanek | xek: you actually do imply it when you talk about data migrations | 17:01 |
ayoung | henrynash, so...forget tokens. They are a dead end. Lets assume we get rid of them, and instead, ecverything queries Keystone directly to get role lists | 17:01 |
ayoung | so nova asks "give me the roles for user that relate to Nova" and so on | 17:01 |
dstanek | lbragstad: yes, that's why i'm a little woried about this spec as it's confusing topics | 17:01 |
ayoung | if we lived in the counterfactual world, would we ever need domain scope roles for something? | 17:01 |
dstanek | xek: how do operators currently upgrade. i would assume: 1. stop keystone instances; 2. upgrade schema; 3. upgrade code; 4. bring up instances (may be completely new instances with new code) | 17:08 |
*** davechen1 has joined #openstack-keystone | 17:09 | |
*** diazjf has quit IRC | 17:09 | |
xek | dstanek, I think the order of 2-3 is switched | 17:10 |
dstanek | xek: that's fine because it doesn't matter | 17:10 |
dstanek | so picking a prescribed set of steps will impact how we code for schema migrations | 17:11 |
xek | dstanek, because they run the migrations scripts of the new release, which migrate the schema to be compatible with the new release | 17:11 |
*** jistr has quit IRC | 17:11 | |
xek | dstanek, my change proposes, to not make incompatible changes, so the migration scripts would not break the old release, which could be still running | 17:11 |
*** davechen has quit IRC | 17:12 | |
dstanek | xek: i don't think that is true at all. we can in code make changes that are not backward compatible without making schema changes | 17:13 |
bknudson | there's going to be tests in place to ensure that doesn't happen. | 17:13 |
xek | dstanek, I agree, but this is still a step forward | 17:13 |
dstanek | for example, changing how we interpret data | 17:13 |
dstanek | xek: i'm not saying it's not just that we need to define the rules better in that spec | 17:13 |
xek | bknudson, dstanek, I want to work on grenade tests, to address other incompatibilities | 17:14 |
*** links has quit IRC | 17:14 | |
xek | but it's out of scope of that spec, which (I think) should only address the online schema migration problem | 17:14 |
xek | maybe together with data migration | 17:14 |
xek | but right now, there is no clear-cut solution for data migration | 17:15 |
lbragstad | cc timcline rderose | 17:15 |
xek | up to date, what I proposed, is realy just doing it case by case | 17:15 |
dstanek | xek: for example, are we allowing adds? | 17:15 |
marekd | stevemar: ping | 17:16 |
marekd | stevemar: https://review.openstack.org/#/c/188534/13/api/v3/identity-api-v3-os-ep-filter-ext.rst so for this patch, and renaming sp_group to service_provider_group (see comment on line 888), shall we also rename this part in the URL scheme? | 17:16 |
henrynash | dstanek: when you get a moment, could to take a look at the latest version of the new assignment driver: https://review.openstack.org/#/c/242853/26 | 17:16 |
xek | dstanek, the unit test would only disallow drops and alters, and those could still be added to the list of exceptions | 17:16 |
dstanek | henrynash: sure | 17:16 |
xek | dstanek, so adds are allowed | 17:17 |
henrynash | dstanek: thx | 17:17 |
lbragstad | xek dstanek what do we want this spec to solve? | 17:17 |
stevemar | marekd: looking now | 17:17 |
marekd | stevemar: thank you, boss | 17:17 |
lbragstad | zero downtime migrations? | 17:17 |
dstanek | xek: adds can introduce backward incompatibilities right? | 17:17 |
lbragstad | or rolling upgrades? | 17:17 |
xek | lbragstad, online schema migration, which is one of the pieces needed for rolling upgrades | 17:18 |
dstanek | lbragstad: i think we have more control over rolling upgrades | 17:18 |
stevemar | marekd: commented! | 17:18 |
marekd | stevemar: looking. | 17:18 |
stevemar | marekd: maybe we should aask the API working group | 17:18 |
lbragstad | dstanek so having more control, what exactly does that mean? | 17:18 |
marekd | stevemar: line 890 is 'service_providers', which is not sp_group nor service_providers_groups | 17:19 |
dstanek | lbragstad: there are operation on the datastore side that will case some issues like locking tables. i'd rather tackle the easier problem first since that gets us pretty far | 17:19 |
xek | dstanek, I don't think they can cause backward schema incompatibilities | 17:20 |
henrynash | remind me…is the midcycle in Austin or San Antonio….. | 17:20 |
lbragstad | henrynash Austin | 17:20 |
dstanek | xek: sure, add a new column that doesn't have a default | 17:20 |
henrynash | thx | 17:20 |
dstanek | xek: old code won't work | 17:20 |
henrynash | almost booked a flight to San Antonio out of habit! | 17:20 |
lbragstad | so, now we are assuming that we can't allow anything that has an ALTER table, or equivalent | 17:20 |
lbragstad | henrynash you could drive up with me! | 17:20 |
xek | dstanek, yes, it needs a default | 17:21 |
henrynash | always looking on ways to make my trave schedules longer :-) | 17:21 |
marekd | stevemar: ok, let me just change to service_provider_group and we will be consistent. | 17:21 |
dstanek | xek: adding a new foreign key (or maybe even just an index) could fail as well | 17:21 |
lbragstad | yeah, adding a column to a table is effectively an ALTER table statement, which will lock the table | 17:22 |
dstanek | xek: we need to provide some guidance as to what to look for and why we are doing this. to me the spec doesn't do that | 17:22 |
*** petertr7 is now known as petertr7_away | 17:22 | |
bknudson | whether the table lock causes a problem or not is going to depend on the size of the table | 17:22 |
lbragstad | bknudson ++ | 17:22 |
bknudson | and what the table is used for | 17:22 |
rderose | xek: I thihk you mentioned that this has been implemented in Nova, so you have a link to the patch by any chance? | 17:23 |
dstanek | bknudson: yep | 17:23 |
lbragstad | we will have to keep in mind (and we should anyway) the table that we are altering, the frequency of it's use by keystone, and how much data is in it. Which could vary greatly across deployments | 17:23 |
xek | rderose, it was a while ago https://github.com/openstack/nova/blob/stable/liberty/nova/tests/unit/db/test_migrations.py#L224-L225 | 17:24 |
bknudson | that fixture should be moved into oslo if it's useful across projects | 17:24 |
*** zz_john5223 is now known as john5223 | 17:25 | |
bknudson | oslotest or oslo.db | 17:25 |
stevemar | marekd: join -sdks | 17:25 |
dstanek | they've only implemented a check that allows exceptions right. they didn't directly tackle the issue yet did they? | 17:25 |
lbragstad | xek are we the only other project besides nova looking at a test like that? | 17:25 |
xek | lbragstad, I think cinder right now | 17:26 |
*** e0ne has quit IRC | 17:27 | |
dstanek | it may be a good opportunity to have all 3 groups talk through the problem | 17:27 |
xek | lbragstad, I think they also have a spec with an example scenario of migrating the data | 17:27 |
xek | lbragstad, http://git.openstack.org/cgit/openstack/cinder-specs/tree/specs/mitaka/online-schema-upgrades.rst | 17:28 |
dstanek | xek: is their goal 0-downtime migrations? | 17:28 |
xek | dstanek, yes | 17:28 |
dstanek | how are they tackling the locking issues? | 17:29 |
openstackgerrit | Tom Cocozzello proposed openstack/keystone: Improve code and comments in test_catalog https://review.openstack.org/248846 | 17:29 |
xek | dstanek, I don't know if they discussed them | 17:29 |
lbragstad | xek do you know who worked on it from cinder? | 17:30 |
xek | dulek, is the author of the spec | 17:30 |
dstanek | xek: do you have a link to their spec? | 17:30 |
xek | dstanek, last link above | 17:31 |
dulek | xek: I can chime in in a moment, meeting. | 17:31 |
dstanek | xek: that doesn't seem to be about 0-downtime does it? | 17:31 |
xek | dulek, told me, the main purpose of the spec was to demonstrate a scenario for 0-downtime upgrade | 17:32 |
*** petertr7_away is now known as petertr7 | 17:32 | |
dstanek | xek: it seem to just defer | 17:32 |
dulek | dstanek: It is totally. | 17:32 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Fixes query.one() return usage in endpoint-policy https://review.openstack.org/208609 | 17:32 |
dstanek | dulek: "All of these should be run when all the services are down." - when does that happen then? | 17:32 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Create unit tests for endpoint policy SQL driver https://review.openstack.org/212006 | 17:32 |
*** rderose has quit IRC | 17:33 | |
xek | dstanek, it's in the problem description section | 17:33 |
dstanek | dulek: how do you deal with the potential table locking on large tables? | 17:33 |
dstanek | xek: so it's saying that you can never do those? | 17:33 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Create unit tests for the policy SQL driver https://review.openstack.org/212957 | 17:34 |
openstackgerrit | Merged openstack/keystonemiddleware: Use keystoneauth for auth_token fixture https://review.openstack.org/253966 | 17:34 |
*** davechen1 is now known as davechen | 17:34 | |
xek | dstanek, I know that nova splits the data migration into smaller pieces before execution | 17:34 |
dstanek | xek: but it's not the migration part that worries me. if you add an index to a really big tables in may take a few seconds right? | 17:35 |
xek | dstanek, the scripts performing the migration can be run with different parameters to specify the chunk of data that is migrated | 17:35 |
samueldmq | mordred: ping - you around ? | 17:36 |
dstanek | xek: sure i've done incremental and on-demand migrations in the past. all of this seems to assume running 'alter ...' will always be 0 downtime | 17:36 |
samueldmq | mordred: about os-client-config | 17:36 |
mordred | I didn't do it | 17:37 |
xek | dstanek, I don't know if this is addressed in nova, dansmith is the person to ask | 17:37 |
dstanek | xek: i was worried that 'alter ...' could table lock on mysql and you were the one that proved me right :-) | 17:38 |
samueldmq | mordred: :-) just wanted to know if it was safe to assume e.g project_name is always defined, but looks like project_id is also an option | 17:38 |
mordred | samueldmq: yah - one of the two | 17:38 |
dstanek | xek: and maybe we're OK with 500s for a second or two, but again i'd want the spec to say we talked about it and that's what we decided | 17:39 |
mordred | samueldmq: are you just wanting to create a keystoneclient object from an occ cloud? | 17:39 |
samueldmq | mordred: kk so I will need to do if/elses | 17:39 |
samueldmq | mordred: yep | 17:39 |
mordred | samueldmq: client = cloud.get_legacy_client('identity', keystoneclient.Client) | 17:39 |
* dulek just ended a meeting, caching up with log. | 17:40 | |
mordred | samueldmq: scuse me - keystoneclient.client.Client | 17:40 |
xek | dstanek, I'm sure that after solving the problem of schema upgrades, other issues will pop up, we can mention some of them in the spec, but I don't know if the list will be complete | 17:40 |
samueldmq | mordred: oh wait, I have an object that is the return from openstack_config.get_one_cloud | 17:40 |
mordred | samueldmq: so ... client = os_client_config.OpenStackCloud().get_one_cloud(cloud='devstack').get_legacy_client('identity', keystoneclient.client.Client) | 17:40 |
mordred | yup | 17:41 |
samueldmq | mordred: so taht is a cloud that I can call get_legacy_client ? | 17:41 |
mordred | yup | 17:41 |
samueldmq | mordred: wtf ? | 17:41 |
mordred | well, it's a CloudConfig actually | 17:41 |
samueldmq | mordred: that's so easy :-) | 17:41 |
mordred | samueldmq: there is an even easier method you could use - but I need to cut a new occ release with it | 17:41 |
dstanek | xek: sure, but the spec talks about both rolling upgrades and 0-downtime and we need to be clear what we are solving and what we are deferring | 17:42 |
samueldmq | mordred: like give_me() and that's all ? :-) | 17:42 |
lbragstad | also, especially with keystone, we should be mindful of different levels of SLAs | 17:42 |
dulek | xek, dstanek: So in case of Nova they don't do any ALTERs that can lock the table. | 17:42 |
mordred | samueldmq: in the next release, you can just do "os_client_config.make_client('identity', cloud='devstack')" | 17:42 |
lbragstad | don't all ALTERs lock the table? | 17:43 |
samueldmq | mordred: great! | 17:43 |
samueldmq | mordred: can I specify the version of the client too ? | 17:43 |
dulek | lbragstad: Depends on the DB, but I believe not. | 17:43 |
dulek | dstanek: This is probably the best writeup on the matter: http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/ | 17:43 |
dstanek | dulek: i think we were reading the MySql docs about that last week and it implied that it did | 17:43 |
mordred | samueldmq: you can specify the version of the api, yes | 17:44 |
mordred | samueldmq: add identity_api_version='3' to the kwargs of get_one_cloud | 17:44 |
dulek | dstanek: http://dev.mysql.com/doc/refman/5.7/en/alter-table.html | 17:45 |
dulek | dstanek: "For some operations, an in-place ALTER TABLE is possible that does not require a temporary table:" | 17:45 |
samueldmq | mordred: alright, thanks! | 17:45 |
dulek | dstanek: And below you have (a rather short) list of ALTERs that I think doesn't lock (if "doesn't require a temp table" means basically the same). | 17:46 |
xek | dstanek, dulek, oh, so adding an index on innodb doesn't cause a lock? | 17:46 |
samueldmq | mordred: please let me know when when have a new release | 17:46 |
*** tonytan4ever has quit IRC | 17:46 | |
mordred | samueldmq: hopefully today | 17:46 |
dstanek | dulek: so adding columns isn't safe? | 17:46 |
dulek | xek: Check out my "if" in parentheses. ;) I'm not a DB geek, so I'm not sure. | 17:46 |
samueldmq | mordred: oh, so I will use the new syntax :) | 17:47 |
lbragstad | so, if adding new columns isn't safe, then we have to add new tables if we want new columns? | 17:47 |
dulek | dstanek: Ah, good point, I'm not sure here… | 17:47 |
dstanek | dulek: ready a little lower. it says they can't because the table needs rebuilt | 17:48 |
*** lhcheng_ has joined #openstack-keystone | 17:48 | |
*** diazjf has joined #openstack-keystone | 17:48 | |
dstanek | dulek: are deletes just never allowed anymore? | 17:49 |
lbragstad | that would be bad | 17:49 |
openstackgerrit | Marek Denis proposed openstack/keystone-specs: Expand endpoint filters to service providers https://review.openstack.org/188534 | 17:49 |
marekd | stevemar: notmorgan amakarov ^^ | 17:50 |
*** lhcheng has quit IRC | 17:51 | |
dulek | dstanek: Hm… Question is if (in case of MySQL) this exclusive lock to swap the table file representation is really a problem. Never thought of this with such details - I've just relied on what works for Nova. | 17:51 |
dstanek | actually the mysql docs are overly complicated. much of it depends on the version and they outcome of the change (like multi-column indexes) | 17:51 |
*** slberger1 has quit IRC | 17:51 | |
dstanek | dulek: so the issue to me is that it likely works fine except for a seconds or two of errors. in the worst case scenario there could be data corruption for a handful of records. | 17:52 |
*** fawadkhaliq has quit IRC | 17:52 | |
*** petertr7 is now known as petertr7_away | 17:52 | |
dulek | dstanek: Having an exclusive lock on a table will result in errors instead of clients just waiting? | 17:53 |
*** edmondsw has quit IRC | 17:53 | |
xek | dulek, dstanek, the doc says, that reads are still executable on the old table, only writes are waiting | 17:54 |
*** diazjf has quit IRC | 17:54 | |
dstanek | dulek: yes. so something kills the connection and retries. what would happen? probably an error saying the record already exists | 17:55 |
dstanek | since we keep saying we want operators to look at the specs i don't like that we are saying 0-downtime, when it's only guaranteed in certain situations. i'd rather say we are trying to get there and this is some of the work that's required | 17:56 |
lbragstad | ++ | 17:56 |
dstanek | not deleting would be terrible, but i "could" be convinced that it would be a good thing. no adds would be a non-starter | 17:57 |
openstackgerrit | Tom Cocozzello proposed openstack/keystone: Improve code and comments in test_catalog https://review.openstack.org/248846 | 17:57 |
dulek | dstanek: Nova and Cinder never considered no adds. | 17:57 |
lbragstad | dstanek I don't like that only because we'll end up with a polluted schema | 17:57 |
*** roxanaghe has joined #openstack-keystone | 17:58 | |
dstanek | lbragstad: we could in theory do a destructive migration every other release. not that i like that. | 17:58 |
lbragstad | dstanek we'd still have downtime, just not as often | 17:59 |
*** jistr has joined #openstack-keystone | 17:59 | |
dulek | lbragstad: Deleting a table can be done without downtime if it is unused. | 17:59 |
dulek | lbragstad: And I think deleting a column is the same as adding it. | 18:00 |
*** slberger has joined #openstack-keystone | 18:00 | |
dstanek | lbragstad: yep, that's my point. 0-downtime is an unobtainable goal, but something we should work towards | 18:00 |
*** shaleh has joined #openstack-keystone | 18:00 | |
dstanek | a bigger issue from what i understand in that clouds are more than one version back. why is that and how do we fix? | 18:01 |
lbragstad | yeah, that's interesting because we would have to advertise that we only support "close" to 0 downtime, from certain releases | 18:01 |
*** fawadkhaliq has joined #openstack-keystone | 18:02 | |
dulek | lbragstad: I don't think that's true. This model should work for all of them. | 18:02 |
dstanek | lbragstad: right. i see the rolling upgrades as a step in that direction | 18:02 |
dulek | dstanek: CERN for example always upgrade N+1. Nova also enforces that now. | 18:02 |
dstanek | dulek: we're not going to keep code around that understands every version of a schema forever | 18:02 |
*** timcline has quit IRC | 18:03 | |
dulek | dstanek: True. Just X-1. I mean - Nova enforces that you only upgrade X-1 to X. Never X-2 to X. | 18:04 |
lbragstad | right, that's what I meant | 18:04 |
lbragstad | we would have to move to a model like that | 18:04 |
*** dansmith has joined #openstack-keystone | 18:04 | |
dstanek | dulek: lbragstad: exactly. right now it doesn't matter for us | 18:05 |
xek | dstanek, apart from the table locking problem, what do we do with the data migrations? bknudson voiced some concerns about performance and security of data migration across releases | 18:05 |
lbragstad | xek will we have performance issues if we keep adding tables? | 18:06 |
xek | we would have to save data in two places if we want to stay fully compatible | 18:06 |
dulek | dstanek: If Nova enforces something, there's no point in not following that - everyone will try to upgrade Nova live. | 18:06 |
*** petertr7_away is now known as petertr7 | 18:07 | |
lbragstad | xek how is that going to impact referential integrity? Say we have to duplicate a table that has foreign keys against another? We would need to duplicate the foreign keys, right? | 18:08 |
dansmith | why are you duplicating tables so much? | 18:08 |
lbragstad | dansmith o/ | 18:09 |
xek | in the first release we would still read from the old place | 18:09 |
dansmith | creating a new table to handle some sort of upgrade should really only be necessary in extreme situations, right? | 18:09 |
dstanek | dulek: i'm not saying we (or they) are doing the wrong thing in the spec. just that it's vague and we have to be honest about the actual effect. if we find that what they are doing isn't what we want to do that's also fine. we should think for ourselves. | 18:09 |
xek | in the seccond release, we would enforce the new foreign key and drop the old one | 18:09 |
xek | *second | 18:09 |
lbragstad | dansmith we're trying to figure out how to get around something that locks a table (like alter statements) where we would incur some amount of downtime | 18:10 |
dansmith | lbragstad: alter table does not always lock the table, it depends on what's happening AFAIK | 18:10 |
dansmith | lbragstad: for example, you should be able to add a column with recent mysql and not lock the whole table | 18:10 |
dstanek | lbragstad: i don't even care if we work around it. just that we say that we are trying to be as 0-downtime as possible, but some releases won't be | 18:13 |
lbragstad | dstanek I'd agree with that | 18:13 |
dansmith | dstanek: yeah, I think that some releases will have to have a note that "we had to do a thing, which means migration 123 will lock the foo table while altering, so plan accordingly" | 18:13 |
dansmith | dstanek: being able to apply the migrations separate from the code means that you can apply some but not all, plan a window for just that one, roll past it, etc | 18:14 |
dstanek | dansmith: in our review i said that we can't always make the guarantee | 18:14 |
dstanek | dolphm: http://paste.openstack.org/show/481065/ | 18:14 |
dansmith | dstanek: but if we have to apply all migrations and roll code at the same time, you have to have downtime for whatever the sum total is, which is less desirable | 18:14 |
dstanek | dansmith: totally agree | 18:14 |
dstanek | dansmith: that's why i want to focus on rolling upgrades and having keystone N+1 understand the schema from N | 18:15 |
dansmith | dstanek: well, that's the opposite of what we're doing.. feels harder that way to me | 18:15 |
dstanek | dansmith: all code can be updated and work fine and the schema can be updated and migrated after. so different releases may have different downtime requirements | 18:16 |
dansmith | dstanek: because you may have APIs that take new arguments that you literally can't store because you don't have the new spot opened up | 18:16 |
*** dims has joined #openstack-keystone | 18:16 | |
dansmith | dstanek: if you expand the schema first, before you roll code, you're never exposing things to the users that they can't do but don't know why | 18:16 |
lbragstad | dansmith so you always guarantee the api layer is updated first before rolling out schema changes | 18:17 |
dansmith | lbragstad: I'm not sure who "you" is in that statement | 18:18 |
*** RichardRaseley has joined #openstack-keystone | 18:18 | |
dstanek | dansmith: i was thinking that we'd support the older API version until the schema was updated | 18:18 |
dansmith | lbragstad: you can build controls into the api to let you disable things that are not possible yet | 18:18 |
lbragstad | dansmith as an operator | 18:18 |
dstanek | dansmith: i'd be fine with the expand/contract idea behind migrations | 18:18 |
dansmith | dstanek: yeah, if your API workers always know what the current schema is | 18:18 |
dansmith | dstanek: for us, we have a lot of moving parts that would all need to know what the current version is, and a host of features or behaviors that would have to gate on that | 18:19 |
dstanek | dansmith: that's not too hard of a problem. we solved that at my old job. | 18:19 |
dansmith | dstanek: no, it's doable for sure | 18:19 |
dansmith | dstanek: it's just higher potential for mistakes, IMHO | 18:19 |
dstanek | keystone isn't nearly as complicated | 18:19 |
dansmith | dstanek: everyone submitting code has to account for it, whereas if you assume that your code will have had the schema updated first, then you don't have to worry about it | 18:20 |
dansmith | dstanek: that is surely true, so maybe that makes sense for keystone | 18:20 |
dansmith | dstanek: it'll be unfortunate to have two components approach it in opposite ways, but c'est la vie | 18:20 |
dstanek | dansmith: for the record i'm not against the plan nova has i want to make sure the keystone spec clearly explains what is going to happen and not have a blanket 0-downtime statement | 18:21 |
dansmith | dstanek: yep, not arguing.. what you're saying makes sense of course | 18:21 |
dstanek | dansmith: when do you plan on doing the locking operations like deleting a column? | 18:21 |
dansmith | dstanek: I'm not sure deleting a column is locking necessarily, but we delete columns after they've been removed from the model | 18:22 |
dansmith | dstanek: the other thing to consider here is how sqla works | 18:22 |
xek | dstanek, ++ I think it's settled that we remove the "blanket 0-downtime statement" | 18:22 |
dansmith | dstanek: sqla will select all columns by name every time | 18:22 |
dansmith | dstanek: which means you will have to either have two models for every change edge, and use the right one when querying based on schema version | 18:23 |
dansmith | dstanek: or you need to explicitly exclude a column from being loaded when you query if you know it's not present yet | 18:23 |
dstanek | dansmith: is that your blog post on danplanet.com? | 18:23 |
dansmith | dstanek: otherwise sqla will generate "SELECT old1,old2,new FROM TABLE.." when new is not a column yet | 18:23 |
dansmith | dstanek: is what in there? | 18:23 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/python-keystoneclient: WIP: Implements base classes for functional tests https://review.openstack.org/253971 | 18:23 |
samueldmq | mordred: something like this ^ | 18:24 |
lbragstad | dstanek is this the one you're talking about - http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/ | 18:24 |
dstanek | lbragstad: dansmith: yes, that's been very helpful in understanding the specs | 18:24 |
*** e0ne has joined #openstack-keystone | 18:24 | |
dansmith | dstanek: oh you said "is that" mine.. yes... | 18:25 |
*** henrynash has quit IRC | 18:25 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/python-keystoneclient: WIP: Implements base classes for functional tests https://review.openstack.org/253971 | 18:26 |
dstanek | dansmith: so assuming that deletes do alter the schema so that it requires a lock. what happens? | 18:28 |
mordred | samueldmq: yes. very sclose | 18:28 |
*** davechen1 has joined #openstack-keystone | 18:28 | |
*** EinstCrazy has joined #openstack-keystone | 18:28 | |
*** browne has joined #openstack-keystone | 18:28 | |
dansmith | dstanek: once the operator is past the point where they can drop the column at any time without the code noticing, they can then do that one thing during a window where they know the table will be locked | 18:28 |
dansmith | dstanek: without having to roll any other code at the same time, or without having to delay turning things back on because they have to run multiple migrations at the same time | 18:29 |
dansmith | dstanek: before this, ops would have to roll code and migrations at the same time, which means once they embarked on the process, they had to complete all migrations before they could bring up new code, and had lost the ability to run the old code, | 18:29 |
dansmith | making it completely monolithic | 18:30 |
*** davechen has quit IRC | 18:30 | |
dstanek | dansmith: ok, that makes sense. | 18:30 |
dstanek | dansmith: do you call out which RDBMSes have the required behaviors? | 18:31 |
dansmith | dstanek: no, we're not quite that organized, unfortunately :/ | 18:31 |
*** rderose has joined #openstack-keystone | 18:31 | |
xek | dstanek, I think postgres is the best fit, since you can rollback schema changes | 18:32 |
dstanek | dansmith: fair enough | 18:32 |
*** rderose has quit IRC | 18:32 | |
xek | dstanek, so in case your table get's locked and the service goes down, you can rollback the schema alteration | 18:32 |
xek | dstanek, and repeat it under different conditions | 18:32 |
samueldmq | mordred: I thought it was client because of what keystonecient receives in tis contructor https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/client.py#L32 | 18:32 |
dstanek | xek: that could be, but we don't control what an operator has so it would be nice to say which versions are know to have near 0 downtime upgrades | 18:33 |
samueldmq | mordred: I thought it was 'version' vs 'identity_api_version' | 18:33 |
dansmith | dstanek: xek it's mostly a question of "which mysql version are you running" as it has improved a lot just in recent 5.x releases | 18:33 |
mordred | samueldmq: occ processes versions and does the right thing under the covers - so you need to tell it identity_api_version | 18:33 |
*** EinstCrazy has quit IRC | 18:34 | |
*** timcline has joined #openstack-keystone | 18:34 | |
samueldmq | mordred: ++ I should hae trusted from the first time you told me :) | 18:35 |
mordred | :) | 18:35 |
*** tonytan4ever has joined #openstack-keystone | 18:36 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/python-keystoneclient: WIP: Implements base classes for functional tests https://review.openstack.org/253971 | 18:37 |
lbragstad | dansmith quick question on your post, specific to migrating the data live. The code is updated to understand both the old schema and the new schema, and is smart enough to figure out what to do with different cases of flavors.memory_mb and flavors.foobars | 18:37 |
dansmith | lbragstad: well, it's updated to know about the new schema. It's moving things because of something higher than schema.. requirements or something | 18:38 |
lbragstad | dansmith ok. | 18:39 |
dansmith | lbragstad: I just want to call out the difference between actually being tolerant of two different (and incompatible) schemas, and just being tolerant of one newer one, where we desire things to be in a different place | 18:39 |
*** edmondsw has joined #openstack-keystone | 18:39 | |
lbragstad | dansmith the case where upgrading releases immediately wouldn't necessarily ensure all data was converted, right? | 18:41 |
lbragstad | or there would have to be some time minimum amount of time in between upgrades. | 18:42 |
*** spandhe has joined #openstack-keystone | 18:42 | |
dansmith | lbragstad: I'm not sure I understand what you're asking.. maybe I distracted us with the schema terminology nit... | 18:42 |
dansmith | there is no minimum time between upgrades.. there is a maximum time, of course. | 18:43 |
*** timcline has quit IRC | 18:43 | |
lbragstad | dansmith sorry, I'm probably not explaining it that well. If we rely on the fact that the code does the data migration (from one type to another for example). Then do we need to ensure that level of code is running for a minimal amount of time to ensure it's touched/migrated every entity that we care about. | 18:44 |
dansmith | lbragstad: ah, I see so, there are two things we do here | 18:45 |
dansmith | the first is we provide a thing that lets the operator push the lazy migrations manuall | 18:45 |
dansmith | so, there is a nova-manage subcommand that says "do N flavor migrations right now please" | 18:45 |
dansmith | which will pick the first N unconverted things, and just load/save them to push the migration | 18:46 |
lbragstad | ah | 18:46 |
dansmith | they can do that in parallel to normal operations in small batches to slowly convert things over time | 18:46 |
*** flwang1 has quit IRC | 18:46 | |
dansmith | when it starts returning zero candidates, they're done | 18:46 |
dansmith | then, when we're looking to make sure they have completed this work, | 18:46 |
dansmith | we land a migration that does nothing other than count the number of unconverted things, and fail if it's nonzero | 18:47 |
bknudson | does nova allow doing the "contract" schema changes during the current release? or does it have to wait until the next release? | 18:47 |
dansmith | we land that first for the next release so that they can't get any further than that first step if they haven't completed their homework | 18:47 |
dansmith | bknudson: right now we wait a release, yeah, because of the sqla problem basically | 18:47 |
dansmith | well, it's not a problem, it's just a reality | 18:48 |
bknudson | ok, would be nice for anybody tracking master | 18:48 |
lbragstad | dansmith interesting, so an operator will know if they can drop a table based on if they can migrate to a given version. | 18:48 |
bknudson | but I don't know how you'd accomplish it... maybe version every table | 18:48 |
dansmith | lbragstad: well, what we do is we land the drop after we land the barrier migration | 18:48 |
dansmith | so they can't get to the drop if they have anything still in their database that is unconverted | 18:48 |
lbragstad | dansmith so it's seemless | 18:48 |
dansmith | yeah, so they don't really notice any difference | 18:49 |
lbragstad | cool | 18:49 |
lbragstad | that makes sense | 18:49 |
dansmith | in the case of a larger thing like a TEXT field, simply NULLing it out when you convert it saves the space | 18:49 |
*** timcline has joined #openstack-keystone | 18:49 | |
dansmith | and for something smaller, like an integer there isn't much waste to be had by waiting for the drop | 18:49 |
dansmith | for a long string or something there could be, | 18:49 |
dansmith | but most people seem to like the idea of less downtime in exchange for carrying more bytes for a short period of time | 18:50 |
bknudson | if you have to support old releases for an entire release then you can't NULL out the field | 18:50 |
dansmith | well, true, you guys can't | 18:50 |
dansmith | we can | 18:50 |
lbragstad | dansmith and that can be approached case-by-case depending on the migration | 18:50 |
dansmith | because we have conductor, which knows that older nodes need things to look like they're expecting | 18:50 |
dansmith | lbragstad: yes | 18:50 |
dansmith | so conductor and objects here provide us insulation from this | 18:50 |
bknudson | unless somehow keystone was told to ignore the field in the new code | 18:51 |
dansmith | the database can move and change, but we have a versioned interface with older nodes so we can "put things back" when we hand them the result of a query | 18:51 |
bknudson | config option or checking the schema version | 18:51 |
dansmith | which means we can null things out when we're done | 18:51 |
dansmith | if you have no such gatekeeper, then you will have to be careful | 18:51 |
dansmith | bknudson: the other thing you need to think about with no gatekeeper, | 18:51 |
dansmith | is that if your migration process moves things from one column to the other, but doesn't null out the old one, | 18:52 |
dansmith | an older node with direct access will continue using/modifying the old value, | 18:52 |
dansmith | but newer nodes will not keep converting that older data | 18:52 |
bknudson | this is one of the major concerns with the spec is having more things that might go wrong. when things go wrong in keystone it's likely a cve | 18:52 |
dansmith | so either you need to always keep both in sync and handle that on newer nodes, or you need something else to account for that | 18:52 |
bknudson | dansmith: do you think there's adequate testing for nova on-line upgrade? does grenade test it? | 18:53 |
xek | dansmith, yes in the spec I proposed a scenario which I think is bullet-proof, but it spans 4 releases, like the one dulek proposed | 18:53 |
openstackgerrit | Sean Perry proposed openstack/keystone: Clean up new_credential_ref usage and surrounding code https://review.openstack.org/246713 | 18:54 |
dansmith | bknudson: we could always do more, but nova's coverage is pretty good, and since we use conductor to insulate older nodes from this complexity, we're in a better spot than you will be | 18:54 |
dansmith | bknudson: so we have a job that starts up nova with two nodes.. two computes, one of which also runs the control services | 18:55 |
dansmith | bknudson: then we upgrade the master node while leaving the old one running the old code, and then make sure it passes tempest in that configuration where one compute node is still on old code | 18:55 |
dansmith | bknudson: we've had that for like three cycles now | 18:55 |
bknudson | maybe we could take advantage of that | 18:55 |
bknudson | run 2 keystones | 18:55 |
dansmith | bknudson: it catches a _lot_ of things | 18:55 |
dansmith | bknudson: yep | 18:56 |
bknudson | xek: is that the kind of testing you were planning on updating? | 18:57 |
xek | bknudson, yes, I think multi-node grenade can achieve this | 18:57 |
dansmith | neutron is working on similar things right now in this area of testing | 18:58 |
bknudson | seems like it would be kind of random but better than nothing. | 18:58 |
xek | dansmith, I heard it was already added as a non-voting job | 18:58 |
bknudson | since tests would just send requests to one or the other | 18:58 |
dansmith | bknudson: you will want to make sure that you have some amount of distribution.. sdague recently merged something for us that makes sure we started instances on both computes successfully | 18:59 |
xek | bknudson, I think you can direct the client to connect only with the old or new version, so they are fully tested | 18:59 |
lbragstad | so splitting requests between the two nodes | 18:59 |
dansmith | bknudson: but randomly catching things in the start is a lot better than "meh we can't verify this in the gate at all" | 18:59 |
xek | bknudson, also, some data should be generated, to test live migration | 18:59 |
dansmith | xek: no, the complicated ones come from accessing and modifying one entity on both versions | 18:59 |
dansmith | xek: i.e. create on new, modify on old, read on new, make sure nobody has corrupted the state | 19:00 |
bknudson | alright, I thought this would be hard to test and setup but if we've got something we can pretty easily update then I feel better about it | 19:00 |
xek | dansmith, ok, but then someone can just say "recheck" and the test could pass... | 19:00 |
bknudson | we've had the issue in the past where we're not testing some pretty important features in gate | 19:01 |
*** aginwala has joined #openstack-keystone | 19:01 | |
dansmith | xek: indeed, so getting to something predictable would be good, which is my point | 19:01 |
bknudson | for example, we still don't have gate testing for federation | 19:01 |
openstackgerrit | Priti Desai proposed openstack/keystone: Fix for GET project by project admin https://review.openstack.org/248892 | 19:02 |
bknudson | dansmith: have operators reported bugs in the live upgrade code? just wondering if it's been a lot of maintenance | 19:02 |
xek | bknudson, I'll add creating the grenade test to the work items on the spec | 19:03 |
bknudson | bugs in database migrations are a pain. | 19:03 |
dansmith | bknudson: no it's perfect | 19:03 |
dansmith | bknudson: also, I have this bridge for sale | 19:03 |
bknudson | maybe I could find an example of a backported fix in nova? | 19:04 |
dansmith | bknudson: we've had a couple things come up that I had to fix real quick, often around data that is in a real database but that we didn't anticipate or something | 19:04 |
dansmith | bknudson: it has been largely successful I think | 19:04 |
*** sigmavirus24 is now known as sigmavirus24_awa | 19:04 | |
dansmith | bknudson: there are also a class of people not leveraging it yet because they have external factors, like neutron which limits their ability (or where they think it does) | 19:04 |
*** sigmavirus24_awa is now known as sigmavirus24 | 19:05 | |
bknudson | I didn't see any where the migration had to be fixed... probably because it's handled in the object layer | 19:10 |
*** agireud has joined #openstack-keystone | 19:14 | |
dansmith | bknudson: we've never had to fix a schema migration, that I know of | 19:15 |
dansmith | bknudson: this approach makes schema migrations mostly trivial, which is quite nice | 19:15 |
raildo | stevemar: ping, do you know if there is anything more to do to deprecate API v2.0? I saw that the related bugs on ironic are in code review, what could be a stumbling block but I believe it will not be anymore. | 19:17 |
lbragstad | dstanek bknudson xek so, based on everything just discussed. do we feel comfortable with the direction? | 19:19 |
bknudson | I'm fine with it. | 19:19 |
bknudson | I think we'll need to do it to support our deployments | 19:19 |
xek | ok, I'm modifying the spec to take into account all comments + adding grenade to the work items + removing the 0-downtime statements | 19:20 |
lbragstad | xek in addition to the keystone-manage subcommands | 19:21 |
dstanek | i was always fine with it, just not how we documented it | 19:21 |
dstanek | xek: ++ awesome thx | 19:21 |
bknudson | is it actually grenade that's the test? or something else? | 19:21 |
*** davechen has joined #openstack-keystone | 19:21 | |
*** davechen1 has quit IRC | 19:21 | |
lbragstad | dansmith that's for taking the time to clarify this | 19:22 |
lbragstad | and field questions | 19:22 |
xek | bknudson, grenade can check the upgrade process and then leave some nodes running with the old version | 19:22 |
dansmith | lbragstad: no problem | 19:22 |
xek | (or one node in case of this test) | 19:23 |
xek | bknudson, and then run tempest on both | 19:24 |
*** jistr has quit IRC | 19:26 | |
openstackgerrit | Sean Perry proposed openstack/keystone: Use new_policy_ref consistently https://review.openstack.org/247257 | 19:27 |
mfisch | clayton: lbragstad can talk now | 19:27 |
lbragstad | mfisch ok | 19:27 |
mfisch | basically clayton found that keystone fails to start if the fernet keys are not writable | 19:27 |
clayton | hey | 19:27 |
mfisch | which makes sense for keystone-manage but not keystone itself | 19:28 |
mfisch | we found it when he was dockerizing | 19:28 |
lbragstad | hmmm | 19:28 |
lbragstad | let me see if I can recreate | 19:28 |
mfisch | in validate_key_respository() | 19:28 |
mfisch | which I assume they both use | 19:28 |
clayton | yes, they do | 19:28 |
mfisch | we dont use keystone-manage to roll keys so dont care if it is unhappy but want keystone to run | 19:29 |
mfisch | with least perms | 19:29 |
clayton | https://github.com/openstack/keystone/search?utf8=✓&q=validate_key_repository | 19:29 |
clayton | specifically this line doesn't make sense when loading the fernet repo for running keystone - https://github.com/openstack/keystone/blob/3d89038bd64fb940567dfac78d2d0df5a5e23e7e/keystone/token/providers/fernet/utils.py#L35 | 19:30 |
clayton | and that function is called by load_keys | 19:30 |
*** diazjf has joined #openstack-keystone | 19:30 | |
bknudson | I like the check mark in the URL! | 19:31 |
mfisch | thought we'd bring it up here and avoid a bikeshed review | 19:31 |
clayton | hah, I didn't notice | 19:31 |
bknudson | we should use that rather than true / false | 19:31 |
openstackgerrit | Sean Perry proposed openstack/keystone: Use assertDictEqual instead of assertEqualPolicies https://review.openstack.org/251482 | 19:31 |
shaleh | lbragstad: I rebased ^^ for you | 19:32 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/python-keystoneclient: Implements base classes for functional tests https://review.openstack.org/253971 | 19:32 |
*** lhcheng_ has quit IRC | 19:34 | |
*** ctina_ has quit IRC | 19:40 | |
lbragstad | shaleh thanks! | 19:41 |
*** aginwala has quit IRC | 19:44 | |
*** diazjf has quit IRC | 19:45 | |
*** e0ne has quit IRC | 19:45 | |
lbragstad | clayton mfisch so; this is what i get | 19:46 |
lbragstad | clayton mfisch i changed the permissions on my keys to be 400 - so read only. I restarted keystone, and I was able to get fernet tokens using https://gist.github.com/dolph/02c6d37f49596b3f4298#file-bootstrap-py | 19:47 |
lbragstad | clayton mfisch are you recreating differently? | 19:47 |
clayton | lbragstad I believe it's checking the permissions on the directory the keys are in, not the keys themselves. | 19:47 |
lbragstad | clayton ok, let me reproduce with that | 19:47 |
*** aginwala has joined #openstack-keystone | 19:48 | |
lbragstad | clayton http://cdn.pasteraw.com/nng0up76dgy5b3naw0hw4bdabdkin84 | 19:48 |
lbragstad | clayton same thing you experienced? | 19:49 |
clayton | yeap, exactly. | 19:49 |
lbragstad | clayton ok, so keystone-manage should care about that, obviously because it has to be able to write keys to the directory | 19:50 |
lbragstad | but we could probably work in a flag for that | 19:50 |
*** flwang1 has joined #openstack-keystone | 19:50 | |
lbragstad | clayton do you guys have a new bug open? | 19:50 |
clayton | nod, that was my thought, but I could probably think of 4-5 different ways to do it, which probably meant I wouldn't do it the way someone else wanted :) | 19:50 |
clayton | I think mfisch wanted to run it past you first | 19:50 |
*** pumaranikar has joined #openstack-keystone | 19:51 | |
lbragstad | clayton sounds good, feel free to create a bug, or i can do it | 19:52 |
*** tqtran_ has joined #openstack-keystone | 19:52 | |
*** fawadkhaliq has quit IRC | 19:54 | |
*** davechen1 has joined #openstack-keystone | 19:55 | |
*** jasonsb has quit IRC | 19:55 | |
*** fangxu has joined #openstack-keystone | 19:56 | |
*** diazjf has joined #openstack-keystone | 19:56 | |
ayoung | samueldmq, check with stevemar on the extensions part of https://review.openstack.org/#/c/253587/ to se if the docs l;ocations should change for extensions | 19:56 |
ayoung | if he says its good, I'm ok with the patch | 19:56 |
*** davechen has quit IRC | 19:56 | |
samueldmq | stevemar: ^ :) | 19:57 |
*** ninag has quit IRC | 19:58 | |
*** ninag has joined #openstack-keystone | 19:58 | |
*** e0ne has joined #openstack-keystone | 19:59 | |
openstackgerrit | Tom Cocozzello proposed openstack/keystone: Improve comments in test_catalog https://review.openstack.org/248846 | 20:02 |
stevemar | looking | 20:02 |
*** e0ne has quit IRC | 20:02 | |
*** ninag has quit IRC | 20:03 | |
*** woodster_ has joined #openstack-keystone | 20:05 | |
stevemar | samueldmq: ayoung 1 small issue | 20:06 |
samueldmq | tjcocozz: actually you didn't address this ? https://review.openstack.org/#/c/248846/5..6/keystone/tests/unit/test_catalog.py | 20:07 |
*** lhcheng has joined #openstack-keystone | 20:07 | |
*** ChanServ sets mode: +v lhcheng | 20:07 | |
samueldmq | stevemar: sure, share it with us | 20:07 |
* tjcocozz looking now | 20:07 | |
stevemar | samueldmq: oh i put it in the review | 20:07 |
samueldmq | stevemar: sure thanks sir! | 20:08 |
tjcocozz | samueldmq, I think forgot to press save on that doc. :-/ uploading the right one now. | 20:11 |
openstackgerrit | Tom Cocozzello proposed openstack/keystone: Improve comments in test_catalog https://review.openstack.org/248846 | 20:11 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Update extensions links https://review.openstack.org/253587 | 20:13 |
notmorgan | jamielennox: you happen to be around? | 20:14 |
samueldmq | stevemar: ayoung: done ^ | 20:14 |
notmorgan | jamielennox: because i could use a little help | 20:14 |
samueldmq | tjcocozz: sure sir :) | 20:14 |
notmorgan | jamielennox: on some KSA things | 20:14 |
stevemar | notmorgan: what ksa things? | 20:16 |
tjcocozz | samueldmq, haha or maybe I'm just a noob. | 20:16 |
samueldmq | tjcocozz: nah, you and git just need to get along (a day) - copied from shaleh :) | 20:17 |
notmorgan | stevemar: https://review.openstack.org/#/c/253793/ resolving how to handle the tests here https://review.openstack.org/#/c/253793/10/nova/tests/unit/network/test_neutronv2.py | 20:17 |
stevemar | notmorgan: i saw that over the weekend | 20:18 |
stevemar | neat tuff | 20:18 |
stevemar | stuff | 20:18 |
notmorgan | samueldmq: i have everything except the comparison of self.assertEqual(token_value, context_client.httpclient.auth.token) and the subsequent line (3908 and 3909) | 20:18 |
notmorgan | stevemar: , not samueldmq | 20:18 |
stevemar | you and mordred are tackling all the projects | 20:18 |
mordred | yah | 20:18 |
notmorgan | stevemar: but trying to figure out how to compare endpoint and token properly is giving me a headache | 20:18 |
notmorgan | stevemar: yah, after nova gonna hit cinder and glance | 20:19 |
stevemar | notmorgan: clients too? | 20:19 |
notmorgan | yah mordred is working on that | 20:19 |
stevemar | you cats are crazy | 20:19 |
mordred | I've got clients on my list | 20:19 |
notmorgan | he is going OCC things | 20:19 |
*** e0ne has joined #openstack-keystone | 20:19 | |
*** e0ne has quit IRC | 20:19 | |
mordred | stevemar: cross project FTW baby | 20:19 |
notmorgan | mordred: ++ | 20:19 |
*** e0ne has joined #openstack-keystone | 20:19 | |
notmorgan | and sdague is helping to tackle the glance-uses-catalog stuff in nova | 20:19 |
stevemar | i saw ++ | 20:20 |
notmorgan | if all goes well we'll have a large chunk of this done in a couple weeks | 20:20 |
*** e0ne has quit IRC | 20:20 | |
notmorgan | and i need to run an idea by jamielennox too. | 20:20 |
notmorgan | stevemar: we might need another KSA release soon. | 20:21 |
notmorgan | stevemar: just as a heads up | 20:22 |
stevemar | notmorgan: coolio | 20:22 |
notmorgan | *might* | 20:22 |
*** petertr7 is now known as petertr7_away | 20:22 | |
*** EinstCrazy has joined #openstack-keystone | 20:22 | |
*** EinstCrazy has quit IRC | 20:27 | |
*** petertr7_away is now known as petertr7 | 20:29 | |
dolphm | lbragstad: mfisch: clayton: did a bug / code review come of your conversation earlier? looking at the code, the W_OK check only needs to be checked for keystone-manage, so i'd like to see callers that care passing require_write=True or something to that method, and have that bit conditionally checked | 20:30 |
lbragstad | dolphm creating one now | 20:30 |
*** aginwala has quit IRC | 20:33 | |
*** henrynash has joined #openstack-keystone | 20:34 | |
*** ChanServ sets mode: +v henrynash | 20:34 | |
lbragstad | dolphm clayton mfisch https://bugs.launchpad.net/keystone/+bug/1523664 | 20:34 |
openstack | Launchpad bug 1523664 in OpenStack Identity (keystone) "Unable to get token when fernet key repository isn't writeable" [Undecided,New] | 20:34 |
*** jaosorior has quit IRC | 20:36 | |
*** jaosorior has joined #openstack-keystone | 20:37 | |
*** jasonsb has joined #openstack-keystone | 20:37 | |
*** timcline has quit IRC | 20:39 | |
*** timcline has joined #openstack-keystone | 20:40 | |
*** aginwala has joined #openstack-keystone | 20:41 | |
*** jaosorior has quit IRC | 20:41 | |
notmorgan | stevemar: i mean... i know how to fix it... but i think if i change those things i might be changing a behavior someone is expecting? | 20:43 |
*** jaosorior has joined #openstack-keystone | 20:43 | |
*** ninag has joined #openstack-keystone | 20:45 | |
*** ninag has quit IRC | 20:45 | |
*** jaosorior has quit IRC | 20:45 | |
*** ninag has joined #openstack-keystone | 20:45 | |
*** diazjf has quit IRC | 20:46 | |
openstackgerrit | Grzegorz Grasza (xek) proposed openstack/keystone-specs: Online schema migration https://review.openstack.org/245186 | 20:50 |
xek | lbragstad, bknudson, dstanek ^ | 20:52 |
xek | good night | 20:52 |
bknudson | sleep tight, xek | 20:53 |
*** rderose has joined #openstack-keystone | 20:54 | |
*** mhickey has joined #openstack-keystone | 20:54 | |
stevemar | xek: thanks for the multiple iterations | 20:55 |
stevemar | ayoung: there are some comments in https://review.openstack.org/#/c/240719/ that should be addressed for internal clean up | 20:56 |
stevemar | cc samueldmq ^ if you're looking for more things to do :P | 20:56 |
*** aginwala has quit IRC | 20:57 | |
ayoung | stevemar, "does this have an impact on fernet tokens?" Yes.. all token formats | 20:58 |
samueldmq | stevemar: what ? doing! | 20:59 |
*** miyagishi_t has joined #openstack-keystone | 20:59 | |
ayoung | samueldmq, stevemar is asking you to clean up my messes | 21:00 |
* ayoung working on implied roles | 21:00 | |
samueldmq | ayoung: that's okay :) | 21:01 |
davechen1 | stevemar, ayoung, samueldmq: all your comments make sense, but this one is intentional iirc - "self.assertTrue(token['is_admin_project'])" | 21:01 |
davechen1 | and it was per the request from the early review, just not inclue this one, samueldmq :) | 21:02 |
samueldmq | davechen1: okay, I got it, is that to assert that its type is boolean right ? | 21:04 |
*** davechen has joined #openstack-keystone | 21:04 | |
stevemar | davechen1: what's the point of keeping that assertion in that form? | 21:04 |
davechen | stevemar: explicitly assert that the value is bool. | 21:04 |
stevemar | davechen1: hmm, assertTrue doesn't do that? | 21:05 |
stevemar | lemme see | 21:05 |
ayoung | davechen, if I try to add a role to the database on a table that has foreign key constraints, and the constraints are not met by the insert, what exception would I expect? | 21:05 |
openstackgerrit | Sean Perry proposed openstack/keystone: Use assertDictEqual instead of assertEqualPolicies https://review.openstack.org/251482 | 21:05 |
stevemar | davechen1: meh, i guess | 21:06 |
stevemar | Note that this is equivalent to bool(expr) is True | 21:06 |
stevemar | https://docs.python.org/2/library/unittest.html | 21:06 |
bknudson | it does bool() which is different | 21:06 |
*** davechen1 has quit IRC | 21:06 | |
davechen | ayoung: so, it should raise exeption? | 21:06 |
stevemar | someone will eventually come in with a clean up "switch all assertEqual(True, X) with assertTrue" in 6 months and we'll merge that | 21:06 |
*** jasonsb has quit IRC | 21:07 | |
davechen | ayoung: but it's not the role not found exception I think. | 21:07 |
ayoung | davechen, heh . it *should* | 21:07 |
bknudson | hopefully reviewers wouldn't accept that | 21:07 |
ayoung | davechen, nah, I need to translate it to that | 21:07 |
stevemar | bknudson: maybe if there's a comment in the code to indicate otherwise ;) | 21:07 |
davechen | ayoung: cool, that will be more clearly. | 21:07 |
ayoung | its going to be some SQL exception...I was thinkg the @sql.handle_)conflicts ould cover it, but its the wrong exception | 21:07 |
stevemar | samueldmq: or davechen: can you add a comment to the assertion? saying we want to explicitly test for booleans | 21:07 |
samueldmq | stevemar: done | 21:08 |
*** pauloewerton has quit IRC | 21:08 | |
*** harlowja has quit IRC | 21:08 | |
davechen | stevmar, bknudson: breton point hit me for the patch I bandoned, i have a good memory on that, right? :) | 21:08 |
*** harlowja has joined #openstack-keystone | 21:08 | |
ayoung | davechen, class DBConstraintError(DBError): I think: https://github.com/openstack/oslo.db/blob/master/oslo_db/exception.py#L90 | 21:08 |
davechen | ayoung: agreed, transilate it anyway. | 21:09 |
ayoung | DBReferenceError | 21:10 |
ayoung | davechen, I plan on it... | 21:10 |
ayoung | https://github.com/openstack/oslo.db/blob/master/oslo_db/exception.py#L107 davechen I think it is this one, actually | 21:10 |
davechen | stevemar: i am not helpful for the cleanup, buried in the classes. :( | 21:10 |
*** jasonsb has joined #openstack-keystone | 21:11 | |
davechen | ayoung: but it's from oslo, we need the exception that more understandable. | 21:11 |
ayoung | davechen, yeah...I was actually just being lazy and figured you knew this off the top of your head, but I did the research now | 21:12 |
*** petertr7 is now known as petertr7_away | 21:14 | |
*** petertr7_away is now known as petertr7 | 21:16 | |
davechen | stevemar: check this out - https://review.openstack.org/#/c/162570/2/keystone/tests/unit/test_backend.py, this is why assertls is better. | 21:17 |
davechen | and acutally, the patch that was merged is not fully correct though. | 21:17 |
davechen | we need revert the change from this one - https://review.openstack.org/#/c/240762/ | 21:18 |
*** bradjones has quit IRC | 21:20 | |
*** bradjones has joined #openstack-keystone | 21:22 | |
*** bradjones has quit IRC | 21:22 | |
*** bradjones has joined #openstack-keystone | 21:22 | |
openstackgerrit | Brad Topol proposed openstack/keystone: Deprecate ldap Role https://review.openstack.org/252669 | 21:24 |
*** mhickey has quit IRC | 21:26 | |
*** aginwala has joined #openstack-keystone | 21:26 | |
*** mhickey has joined #openstack-keystone | 21:27 | |
*** mhickey has quit IRC | 21:28 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Cleans up code for `is_admin` in tokens https://review.openstack.org/254391 | 21:30 |
*** rderose has quit IRC | 21:30 | |
samueldmq | stevemar: ayoung: davechen: ^^ | 21:30 |
jamielennox | notmorgan: i'm here for like 10 minutes, then i'll be back in an hour or so | 21:31 |
notmorgan | jamielennox: no worries i think i've solved it | 21:32 |
notmorgan | jamielennox: but sec.. | 21:32 |
*** mhickey has joined #openstack-keystone | 21:33 | |
bknudson | I tried running keystone with uwsgi and got an error | 21:34 |
bknudson | http://paste.openstack.org/show/481085/ | 21:35 |
*** alejandrito has joined #openstack-keystone | 21:36 | |
bknudson | maybe I need to add SCRIPT_NAME to /etc/nginx/uwsgi_params | 21:36 |
bknudson | http://uwsgi-docs.readthedocs.org/en/latest/Nginx.html#hosting-multiple-apps-in-the-same-process-aka-managing-script-name-and-path-info | 21:38 |
*** jasonsb has quit IRC | 21:39 | |
*** jasonsb has joined #openstack-keystone | 21:40 | |
*** aginwala has quit IRC | 21:40 | |
clayton | bknudson I'm running it under uwsgi, but without nginx, with uwsgi in http mode | 21:40 |
bknudson | clayton: that's too easy | 21:41 |
clayton | you can play on hard if you prefer :) | 21:41 |
notmorgan | bknudson: i've run keystone under uwsgi w/ the uwsgi-socket | 21:41 |
notmorgan | bknudson: what error? | 21:41 |
bknudson | notmorgan: there's no SCRIPT_NAME defined | 21:41 |
bknudson | So now I'm looking in uwsgi_params to see if I can set it to something | 21:42 |
* notmorgan might have tacked something in to fix that | 21:42 | |
bknudson | I don't know why uwsgi is so much better than http | 21:43 |
*** rderose has joined #openstack-keystone | 21:44 | |
dstanek | bknudson: that's in the uwsgi docs - i've had to do that in the past | 21:48 |
dstanek | bknudson: you have issues i can dig out what i had to do | 21:49 |
dstanek | bknudson: the benefit to uwsgi is that you don't need apache. if you want apache the mod_wsgi is probably the way to go | 21:50 |
bknudson | why is the uwsgi protocol better than http? I can run python uwsgi with --http or --socket | 21:51 |
clayton | bknudson: some people seem to be nervous about exposing uwsgi directly | 21:51 |
bknudson | you don't expose it directly, you use http proxy | 21:51 |
bknudson | I can do http proxy or I can do uwsgi proxy | 21:51 |
clayton | ah, I see what you're saying | 21:52 |
clayton | the uwsgi people say it's faster. I doubt it matters for keystone | 21:52 |
bknudson | keystone has much bigger performance problems | 21:52 |
clayton | that was my take yes | 21:52 |
clayton | we're running it in http mode behind haproxy in http mode | 21:52 |
clayton | or will be at last | 21:53 |
clayton | s/last/least/ | 21:53 |
bknudson | https://www.digitalocean.com/community/tutorials/how-to-set-up-uwsgi-and-nginx-to-serve-python-apps-on-ubuntu-14-04 "This is a faster protocol than HTTP and will perform better." | 21:53 |
bknudson | I don't believe it, but whatever | 21:54 |
dstanek | bknudson: clayton: yes, faster, but more for things that have the C10K type problems | 21:55 |
bknudson | if http is so bad then improve http, don't go making a whole new protocol | 21:56 |
bknudson | dstanek: I still haven't figured out what to set script_name to. | 21:56 |
dstanek | bknudson: in our case you can probably get away with setting it to the same value as path_info | 21:59 |
bknudson | maybe I should make it easier on myself and use :5000 and :35357 rather than /identity and /identity_admin. | 22:00 |
clayton | that seems pretty reasonable. | 22:00 |
dstanek | bknudson: in one config i am using this 'fastcgi_param SCRIPT_NAME $fastcgi_script_name;' | 22:01 |
*** rderose has quit IRC | 22:01 | |
dstanek | will you be satisfied taking the easy way out? | 22:02 |
*** gildub has joined #openstack-keystone | 22:02 | |
bknudson | I'm never satisfied doing things the easy way | 22:02 |
bknudson | the uwsgi server keeps saying it's doing "GET /identity" but I need nginx to turn GET /identity to GET / | 22:03 |
*** ninag has quit IRC | 22:04 | |
*** davechen1 has joined #openstack-keystone | 22:05 | |
*** davechen has quit IRC | 22:06 | |
*** aginwala has joined #openstack-keystone | 22:08 | |
*** henrynash has quit IRC | 22:11 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Cleans up code for `is_admin` in tokens https://review.openstack.org/254391 | 22:12 |
samueldmq | lhcheng: ^ | 22:12 |
*** aginwala has quit IRC | 22:15 | |
*** e0ne has joined #openstack-keystone | 22:15 | |
*** mhickey has quit IRC | 22:18 | |
*** aginwala has joined #openstack-keystone | 22:21 | |
*** davechen1 has left #openstack-keystone | 22:23 | |
*** petertr7 is now known as petertr7_away | 22:23 | |
samueldmq | stevemar: responded inline to your comment in the cleanup change | 22:25 |
bknudson | I got nginx working listening on 35357 and 5000... not sure what the deal is with SCRIPT_NAME since if I set it to anything it was always /identity (even if I set it to some other string) | 22:29 |
openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Cleans up code for `is_admin` in tokens https://review.openstack.org/254391 | 22:30 |
*** aginwala has quit IRC | 22:34 | |
*** topol has quit IRC | 22:40 | |
*** davechen has joined #openstack-keystone | 22:40 | |
kfox1111 | if I have a self signed cert on a K2K idp, how do I load that into shib on the SP? | 22:44 |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Add checks for domain scoped data creep https://review.openstack.org/253671 | 22:51 |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Add checks for project scoped data creep to tests https://review.openstack.org/253670 | 22:51 |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Reuse project scoped token check for trusts https://review.openstack.org/253672 | 22:56 |
*** aginwala has joined #openstack-keystone | 22:58 | |
*** gildub has quit IRC | 22:58 | |
*** gyee has joined #openstack-keystone | 23:01 | |
*** ChanServ sets mode: +v gyee | 23:01 | |
*** lhcheng_ has joined #openstack-keystone | 23:01 | |
*** timcline has quit IRC | 23:04 | |
*** lhcheng has quit IRC | 23:04 | |
*** e0ne has quit IRC | 23:04 | |
stevemar | bknudson: looks like we need to doc it :P | 23:05 |
*** spotz is now known as spotz_zzz | 23:06 | |
openstackgerrit | Priti Desai proposed openstack/keystone: Adding role assignment lists unit tests https://review.openstack.org/254436 | 23:10 |
openstackgerrit | ayoung proposed openstack/keystone: Implied Roles https://review.openstack.org/242614 | 23:17 |
openstackgerrit | ayoung proposed openstack/keystone: Create V9 Role Driver https://review.openstack.org/247805 | 23:17 |
openstackgerrit | ayoung proposed openstack/keystone: Create new version of assignment driver interface https://review.openstack.org/242853 | 23:17 |
ayoung | GAH what part of "NO REBASE" | 23:17 |
ayoung | fucking hell | 23:17 |
*** jamielennox is now known as jamielennox|away | 23:18 | |
openstackgerrit | ayoung proposed openstack/keystone: Create new version of assignment driver interface https://review.openstack.org/242853 | 23:22 |
*** davechen has left #openstack-keystone | 23:22 | |
*** boris-42_ has quit IRC | 23:23 | |
*** pumaranikar has quit IRC | 23:23 | |
openstackgerrit | ayoung proposed openstack/keystone: Use list_role_assignments to get projects/domains for user https://review.openstack.org/242513 | 23:23 |
openstackgerrit | ayoung proposed openstack/keystone: Create V9 Role Driver https://review.openstack.org/247805 | 23:25 |
ayoung | WTF is with --no-rebase being ignored! | 23:25 |
*** slberger has left #openstack-keystone | 23:25 | |
openstackgerrit | Jorge Munoz proposed openstack/keystone: Reduce revoke events for disabled domains and projects. https://review.openstack.org/253273 | 23:27 |
*** alex_xu has quit IRC | 23:29 | |
*** alex_xu has joined #openstack-keystone | 23:31 | |
*** lhcheng_ has quit IRC | 23:34 | |
openstackgerrit | ayoung proposed openstack/keystone: Implied Roles https://review.openstack.org/242614 | 23:34 |
ayoung | whew | 23:34 |
*** aginwala has quit IRC | 23:40 | |
openstackgerrit | Jorge Munoz proposed openstack/keystone: Reduce revoke events for disabled domains and projects. https://review.openstack.org/253273 | 23:41 |
*** aginwala has joined #openstack-keystone | 23:41 | |
*** tonytan_brb has joined #openstack-keystone | 23:51 | |
*** boris-42_ has joined #openstack-keystone | 23:53 | |
*** tonytan_brb has quit IRC | 23:54 | |
*** tonytan4ever has quit IRC | 23:55 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/254444 | 23:57 |
*** sigmavirus24 is now known as sigmavirus24_awa | 23:57 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/254445 | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!