Monday, 2015-12-07

notmorgannot opposed to the opt having the info encoded in it that this is something you may want to prompt for00:00
mordredme either00:00
notmorgani think that is reasonable00:00
notmorganit's the actual prompting i don't want00:00
notmorganin ksa00:00
jamielennoxso the way we're pushing atm this would become OCC's job00:01
jamielennoxbecause OSC is pushing that way00:01
mordredjamielennox: 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 together00:01
jamielennoxsure, but if password is unfilled then it would be OCC that has to prompt so it can be the one version00:02
jamielennoxi was picking through OCC the other day, i didn'trealize you actually updated the cloud dict if values were missing00:02
mordredI 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
notmorganOCC has real user-facing interactions though00:03
notmorganso that wouldn't be the worst place.. but likely the consumer of OCC (or the gcloud init thing) would prompt00:04
mordredocc _does_ instantiate from ksa to verify that the auth arguments are valid so that it can give an error00:04
mordredmaybe OCC is the thing that you'd pass a prompt callback to00:04
notmorganmordred: i could see that00:04
mordredand 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 collection00:04
mordredso, like, right before it asks ksa to validate the auth params00:05
mordredit checks the list from ksa, sees if any are marked as prompt - and if they are and are missing, it tries calling the prompt callback00:05
mordred(we could also put the prompt callback code _in_ occ)00:06
mordredbecause osc and nova client both might want to choose to enable prompting00:06
mordred(and, in fact, both do)00:06
mordredso you could say get_one_cloud(prompt_callback=occ.prompt_callback) or something00:06
mordredoh - yea00:09
mordredthis will actually be reasonably clean/easy00:09
mordredin _validate_auth00:09
mordredwe already have a loop over plugin options00:09
mordredwould be SUPER easy to call a callback if one is required and missing and labeled prompt_for_value00:10
jamielennoxyep, 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 plugin00:10
jamielennoxso it's doing that loop anyway00:10
*** chlong has quit IRC00:13
*** jerrygb has quit IRC00:15
mordredjamielennox: something like this: https://review.openstack.org/25396900:15
mordrednotmorgan: ^^00:15
mordredNOT TESTED AT ALL - that's just tossed up for discussion00:15
notmorganmordred: very much like that00:16
notmorgan_VERY_ much just like that00:16
jamielennoxmordred: would you bother doing the getpass check?00:16
jamielennoxthat would seem to be osc's job if it's available00:17
mordredjamielennox: what do you mena?00:17
jamielennoxgrr, see if we didn't actually re-populate the config['auth'] dict there that's exactly what's in ksa00:18
mordredI 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 dict00:18
jamielennoxmordred: 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 callback00:18
mordredjamielennox: OH!!!00:19
mordredjamielennox: yeah - I totally get what you mean00:19
mordredyeah - I like that00:19
mordredjamielennox: https://review.openstack.org/253969 updated with that in mind00:19
jamielennoxalso as a nit i'd call it auth_prompt_callback as you're not doing it for everything00:20
mordredwell, I like your thing better00:20
mordredcall the callback on everything00:20
mordredand let the callback have smarts00:20
jamielennoxit's still auth_ unless you start prompting for like OS_IMAGE_API_VERSION00:20
mordredoh - nod00:21
mordreddone00:21
*** mylu_ has quit IRC00:21
jamielennoxyea, that seems simple enough00:22
jamielennoxi wonder if that solves deans' auth_config_hook00:22
*** mylu has joined #openstack-keystone00:22
mordredyou konw - maybe in addition to the p_opt we should pass the plugin loader too00:22
mordredbecause in addition to password - one might want an oauth "trigger a browser window open" sort of thing00:22
jamielennoxi can see OSC needing that00:22
mordredlet's add it, why not00:23
*** gildub has joined #openstack-keystone00:24
notmorganmordred: i kindof like that00:24
notmorganjamielennox: OSC may not need it00:24
notmorganbut other consumers might find it useful00:24
notmorgan... also if i get my way and i get everyone to deploy openstack as <api>.<cloud>/<service>00:24
jamielennoxi can see special casing00:24
notmorganoauth becomes much more interesting00:24
mordredcan you use abc on non-class functions? :)00:25
mordredI feel bad I can't put in a data type in the doc string00:25
jamielennoxif isinstance(loader, password) and opt.name == 'xxx':00:25
*** dims has quit IRC00:25
mordred++00:25
mordredwould be a simple way forward for the password case00:25
*** dims has joined #openstack-keystone00:26
jamielennoxin 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 things00:26
mordredjamielennox: ++00:27
*** mylu has quit IRC00:27
*** chlong has joined #openstack-keystone00:27
jamielennoxi still think we'll want it for like saml plugins in future, but i'm not too worried about that for now00:27
mordredjamielennox: yup. I think special casing will get us down the road00:27
mordredjamielennox: 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-keystone00:28
jamielennoxif we're not doing the opt.getpass thing in ksa then i'd leave it00:28
jamielennoxoh, novaclient...00:29
jamielennoxbah00:29
jamielennoxif 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 OSC00:29
mordredwell, 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
jamielennoxmordred: actually have you seen https://review.openstack.org/#/c/243348/00:30
mordredyah - I tink that's awesome00:31
mordredI'm moving novaclient and friends to occ/ksa as a stepping stone to making that transition easier for people00:31
jamielennoxso 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 move00:32
jamielennoxs/real impact/direct impact00:32
jamielennoxalso i've no idea what you need to do to get a +A there00:32
mordredbecause 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 something00:32
mordredI tink ttx eventually does something00:32
*** dims has quit IRC00:35
openstackgerritSamuel de Medeiros Queiroz proposed openstack/python-keystoneclient: Initialize /v2_0 and /v3 functional tests dirs  https://review.openstack.org/25397000:35
openstackgerritSamuel de Medeiros Queiroz proposed openstack/python-keystoneclient: WIP: Implements base class for functional tests  https://review.openstack.org/25397100:36
samueldmqjamielennox: mordred: ^this is the very very beginning of improving functional tests on the client, as I see them00:36
samueldmqwould be glad to get an initial couple of eyes on them00:37
samueldmqI am basically importing keystoneclient (expecting it's getting the one installed by devstack in its env), instantiating the client, and doing some testing00:37
samueldmq(for now just creating a user)00:38
openstackgerritBrad Topol proposed openstack/keystone: Deprecate ldap Role  https://review.openstack.org/25266900:38
jamielennoxsamueldmq: i'm not sure how you recieve credentials for functional tests, i think it's the standard OS_ variables00:38
jamielennoxso you'd want to do the plugin probably via load_from_argparse_arguments00:38
jamielennoxi don't know how you test auth that way..00:39
notmorganayoung: api.tempusfrangit.org/dashboard00:39
jamielennoxoh - ksc, we don't need to test auth00:39
notmorganayoung: it mostly works [don't boot instances]00:39
samueldmqjamielennox: ++00:39
mordredthere's actually an oslotest fixture for getting creds00:39
notmorganayoung: but the dashboard is all there.00:39
jamielennoxmordred: oh? i bet that's doing it wrong :)00:40
samueldmqjamielennox: what is that ? load_from_argparse_arguments00:40
mordredjamielennox: I wrote it :)00:40
samueldmqjamielennox: is it the way OS_ variables are provided ?00:40
mordredjamielennox: one sec - getting link00:40
mordredno - don't use those00:40
samueldmqmordred: kk00:40
mordreduse the clouds.yaml we write - it has both admin and non-admin users defined00:40
jamielennoxsamueldmq: 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 argv00:40
mordredone sec - getting link for example of usage00:40
* notmorgan uses all the OS_<variables> just cause mordred said dont (*pre-emptive duck of wet cat*)00:41
jamielennoxheh, whoops00:41
*** topol has quit IRC00:42
mordredoh - piddle00:42
samueldmqjamielennox: so when calling the functional tests via tox, one could provide the arguments via that command? like:00:42
mordredthis is not using the fixture:00:42
mordredhttp://git.openstack.org/cgit/openstack/python-glanceclient/tree/glanceclient/tests/functional/base.py00:42
mordredsamueldmq: ^^00:42
samueldmqtox -e functioanl user=a password=b and so on ?00:43
samueldmqjamielennox:  ^00:43
samueldmqor if not, we would get from env00:43
samueldmqmordred: looking00:43
jamielennoxsamueldmq: it was designed for CLI like --os-auth-type, i wouldn't suggest passing them through tox00:43
mordredhttp://git.openstack.org/cgit/openstack/oslotest/tree/oslotest/functional.py00:44
mordredis the thing in oslotest00:44
samueldmqjamielennox: so that doesnt' apply to that work on functional tests ?00:44
jamielennoxmordred: all that work and glanceclient then rips the creds['username'] out to do functional tests :(00:44
mordredlooks like nothing is usin git yet :00:44
samueldmqjamielennox: like the creds can't be passed for running the functional tests that way00:44
mordredjamielennox: well - it was a start00:44
mordrednovaclient: http://git.openstack.org/cgit/openstack/python-novaclient/tree/novaclient/tests/functional/base.py00:45
jamielennoxsamueldmq: i know some of the other clients used to look for the OS_ environment variables directly00:45
* mordred is slowly working on migrating all of those clients, fwiw00:45
samueldmqjamielennox: would that be acceptable for us to start ?00:45
mordredplease no00:45
mordredplease use the clouds.yaml file00:45
samueldmqmordred: :-)00:45
jamielennoxsamueldmq: yea, use the oslotest hook mordred is suggesting00:45
jamielennoxmordred: ksc -> ksa you mean?00:46
samueldmqmordred: and that's what that os_client_config do ?00:46
mordredit'll make you happier00:46
mordredsamueldmq: yah00:46
jamielennoxswift is the only one i'm aware of that doesn't do either00:46
mordredjamielennox: so many things- ksc -> ksa , functional tests using clouds.yaml00:46
mordredclient utils using clouds.yaml/occ - servers using ksa00:46
mordredTOO MANY TASKS!!!00:46
samueldmqcool, where can I learn about clouds.yaml ?00:47
jamielennoxmordred: i've heard you have people that work for you that know this stuff00:47
samueldmqI need to start there, then look at the existing examples00:47
mordred(although jamielennox did you see https://review.openstack.org/#/c/253783/ ) ?00:47
mordredsamueldmq: http://docs.openstack.org/developer/os-client-config/00:47
mordredsamueldmq: devstack writes a clouds.yaml to /etc/openstack that defines too clouds "devstack" and "devstack-admin"00:48
mordredthe "devstack" cloud is the unprivileged user, the devstack-admin cloud is the admin user00:48
samueldmqhmm, that's very very interesting actually, thanks for the link mordred00:48
mordredsamueldmq: woot!00:48
mordredjamielennox: hah. you make it sound like I could get the people who work for me to do what I told them to :)00:49
samueldmqmordred: 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 understands00:49
jamielennoxoh - nice00:49
samueldmqjamielennox: mordred: gotta sleep now, talk to you tomorrow00:52
samueldmqg'night00:52
*** miyagishi_t has joined #openstack-keystone00:53
mordrednight samueldmq !00:55
openstackgerritMerged openstack/keystoneauth: Add BetaMax Fixture  https://review.openstack.org/25047600:56
*** chlong has quit IRC01:01
ayoungnotmorgan, I'm in01:04
*** EinstCrazy has joined #openstack-keystone01:04
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Don't like deprecated opts in sample config  https://review.openstack.org/25397201:04
notmorganayoung: i am chasing down an issue with "cannot get volume information"01:05
ayoungnotmorgan, "Error: Unable to retrieve volume limit information"  We've seen that before.  Looks at the config01:05
notmorganyeah01:05
ayoungfor nova and for cinder...there is a two way set up there that needs t o be done.01:05
ayoungI have a link in roppowam..one sec01:05
notmorgan2015-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:certificate01:05
notmorganverify failed01:05
notmorgansomething somewhere is having SSL issues01:05
ayoungnotmorgan, https://github.com/admiyo/rippowam/blob/master/roles/packstack/tasks/serviceauth.yml01:06
notmorganyeah this is something in the cinder log01:06
ayoungnotmorgan, the requests issue?01:06
notmorganso...01:06
notmorganyeah this is requests01:06
ayoungcinder needs to call back to nova01:06
notmorganbut i don't know where/how i can say "insecure"01:06
notmorganyeah01:06
ayoungyou need to configure a second section in cinder.conf01:07
notmorganso, something is busted... i *think* i know what it is though01:07
ayounghttps://github.com/admiyo/rippowam/blob/master/roles/packstack/tasks/serviceauth.yml#L1601:07
notmorganrigth01:07
ayoungwhen cinder calls nova, it uses different auth info for some reason01:07
ayoung same thing is an issue with neutron to nova for the callback "port's connected"01:07
notmorgani have that configured i just don't know where to say "insecure"01:08
ayoungjamielennox, ^^ question for you01:08
notmorganit's having issues hitting the letsencrypt TLS endpoint01:08
notmorganapi. is useing a *real* SSL cert from letsencrypt01:08
ayoungnotmorgan, what if you add the letsencryp generated CA to the requests bundle?01:09
ayoungwould that be a better way to go?01:09
notmorganrequests doesn't use system CA01:09
notmorgan=/01:09
notmorganit's kindof a point of ... i'm annoyed with requests01:10
notmorganover01:10
notmorganthey role their own ca bundle.01:10
ayoungin that section you can try01:10
ayoungverify=false01:10
notmorganwhich config section?01:10
notmorganoh hah in the code01:11
notmorganyes01:11
notmorgani'm trying to do it with config first01:11
jamielennoxayoung: sorry what01:23
notmorganjamielennox: trying to figure out how to get cinder to do verify=False when it's talking to keystone to look up project info01:23
jamielennoxinsecure=True in conf from memory01:24
ayoungjamielennox, 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 another01:24
ayoungthanks01:24
ayoungjamielennox, you know how to add to the requests bundler?01:24
notmorganjamielennox: it's Volume limit data?01:24
notmorganayoung: certifi package01:24
jamielennoxayoung: 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 week01:24
notmorganayoung: it's ultimately doable but me01:24
notmorganh01:24
ayounga whole Rabbit, maybe?01:25
ayoungjamielennox, but, not really.01:25
notmorganugh...01:25
jamielennoxayoung: yea, but i have all this WIP stuff around how to change policy enforcement01:25
ayoungjust the start of an etherpad on how to do URL based auth01:25
ayoungjamielennox, just keep on it, then01:26
notmorganjamielennox, ayoung: yep not configuable01:26
notmorganhttp://paste.openstack.org/show/480974/01:26
notmorganjoy01:26
* notmorgan sighs.01:26
jamielennoxayoung: nah - it's fine, i agree that the keys in policy make no senes01:26
jamielennoxalso i love that it's "first quack at ..."01:27
notmorganreally this is why requests irritates me.01:27
notmorganuse.the.system.ca.info01:27
notmorganseriously01:27
jamielennoxnotmorgan: define your own in env01:27
jamielennoxor use the system package01:27
notmorganjamielennox: requests uses certifi01:27
notmorganit doesn't use the linux system CAs01:28
jamielennoxi know01:28
notmorganit's stupid.01:28
jamielennoxbut all the system packages fix that01:28
notmorganand i don't *want* to use the system packages when i'm hacking on things01:28
notmorgani am using VENVs for a reason01:28
jamielennoxnotmorgan: https://github.com/kennethreitz/requests/blob/master/requests/sessions.py#L62401:28
jamielennoxset REQUESTS_CA_BUNDLE in env01:28
notmorganagain01:28
notmorganhorrible01:28
notmorganit shouldn't be needed like that01:29
notmorganthis is a stupid choice on requests side01:29
jamielennoxnotmorgan: agreed01:29
notmorganthey should default to let us use the system CA01:29
jamielennoxso there was a thread about this on the ML a while ago01:29
jamielennoxthat maybe ksa should default this above requests01:29
notmorganprobably01:30
notmorganor we should fork requests and stop vendoring urllib3 and do system ca things01:30
notmorganfor openstack01:30
jamielennoxnotmorgan: hoewver i don't want to deal with all the different system cas either01:30
notmorganjamielennox: so for linux there are very few places01:30
jamielennoxif i wrote ksa again i'd use urllib3 directly01:31
jamielennoxbut01:31
notmorganjamielennox: we *could* do that .01:31
notmorgani mean, the interfaces would look very similar even if we used urllib301:31
jamielennoxif you're doing this via ansible just set cacert wherever you're doing insecure =01:31
notmorganno, this is a hand-configured openstack cloud01:32
jamielennoxthere's a couple of places we export requests stuff directly01:32
*** jed56 has quit IRC01:32
notmorganbecause nothing works with sub-mounted urls01:32
*** jed56 has joined #openstack-keystone01:32
notmorganjamielennox: http://paste.openstack.org/show/480971/01:32
jamielennoxayoung: so that's not that big a proposal01:32
jamielennoxwhat would happen if the keys changed though01:32
jamielennoxlike user_id is just a key for substitution01:33
notmorganjamielennox: anyway......01:33
* notmorgan grumbles01:34
ayoungjamielennox, in the policy-by-url approach?01:34
ayounghmmm01:34
ayoungjamielennox, not sure what you mean there?01:35
*** wangqun has joined #openstack-keystone01:36
stevemaro/01:43
notmorganjamielennox: setting that env var doesn't work well01:44
notmorganbecause eventlet etc01:45
notmorganits...01:45
notmorganfrustrating... i can fix it but gah.01:45
notmorganthis is terrible01:45
*** ayoung has quit IRC02:02
*** navidp has joined #openstack-keystone02:05
*** navidp has quit IRC02:07
*** navidp has joined #openstack-keystone02:07
*** navidp has quit IRC02:12
*** diegows has joined #openstack-keystone02:27
jamielennoxnotmorgan: why does eventlet change the env var?02:32
*** navidp has joined #openstack-keystone02:35
*** navidp has quit IRC02:35
mordrednotmorgan, jamielennox: I updated that patch again, this time with a copy of the novaclient prompting function added in02:36
mordredhttps://review.openstack.org/#/c/253969/02:36
notmorganjamielennox: it's because it spins up separate processes and it loses envs02:36
*** chlong has joined #openstack-keystone02:36
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Don't list deprecated opts in sample config  https://review.openstack.org/25397202:37
notmorganjamielennox: 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
notmorganjamielennox: i don't... think we have a fixture way to handle that02:37
jamielennoxnotmorgan: i'm not sure what you mean02:37
*** jamielennox has left #openstack-keystone02:37
*** jamielennox has joined #openstack-keystone02:37
*** ChanServ sets mode: +v jamielennox02:37
notmorganjamielennox: CONF is global02:37
notmorganjamielennox: registering opts is a one-time thing02:38
notmorganksc.auth/ksa will not de-register the options in tests for example02:38
notmorgani'm wondering if it matters.02:38
* notmorgan thinks not...02:38
jamielennoxnotmorgan: mostly for tests we want to use the conf fixture to isolate that sort of thing anyway02:39
jamielennoxwhether projects do that or not...02:39
jamielennoxthis is how we ended up with that horrible hack in auth_token middleware as well02:40
notmorganyeah02:40
*** navid_ has left #openstack-keystone02:40
notmorganok i'll do something here...02:40
mordrednotmorgan: updated02:41
*** navid_ has joined #openstack-keystone02:41
jamielennoxmordred: why would i want verify?02:42
jamielennoxalso, i don't really mind but i think the abc is overkill, i know notmorgan asked for that02:43
*** links has joined #openstack-keystone02:45
*** navid_ has quit IRC02:46
*** mylu has quit IRC02:47
mordredjamielennox: I was basically doing that to make a way to commuicate the type expected in the doc string02:49
mordredjamielennox: I also agree- it's a bit heavy02:49
*** yangyapeng has joined #openstack-keystone02:49
*** diegows has quit IRC02:50
mordredjamielennox: for verify - that's mainly there just cause I ported in the code from novaclient and that's what they do02:52
jamielennoxstevemar: you back/03:23
*** btully has joined #openstack-keystone03:46
*** mylu has joined #openstack-keystone03:56
*** btully has quit IRC03:56
*** flwang1 has quit IRC04:00
*** amakarov has quit IRC04:02
*** dims has joined #openstack-keystone04:03
*** wanghua has quit IRC04:03
*** ayoung has joined #openstack-keystone04:09
*** ChanServ sets mode: +v ayoung04:09
openstackgerritJamie Lennox proposed openstack/keystoneauth: Extract SAML fixtures into templates  https://review.openstack.org/25399904:16
openstackgerritStanislaw Pitucha proposed openstack/keystone: Fix multiline strings with missing spaces  https://review.openstack.org/25400004:17
stevemarjamielennox aye aye04:22
jamielennoxstevemar: how was the break?04:22
openstackgerritJamie Lennox proposed openstack/keystoneauth: Extract SAML fixtures into templates  https://review.openstack.org/25399904:26
openstackgerritJamie Lennox proposed openstack/keystoneauth: Get versioned url for K2K auth  https://review.openstack.org/25168604:30
openstackgerritJamie Lennox proposed openstack/keystoneauth: Cleanups to K2K plugin  https://review.openstack.org/25168704:30
*** dims has quit IRC04:34
*** btully has joined #openstack-keystone05:03
*** chlong has quit IRC05:05
stevemarjamielennox: just took thursday/friday off, i spent most of thursday trying to find internet access so i could confirm m-1 was released05:14
stevemaramong other things related to release05:14
stevemarglad to see it went through fine though05:14
stevemari have a lot of stuff and things to do tomorrow, but i'll save that for tomorrow05:15
stevemari went through all my email today, looks like nothing too crazy happened, aside from a ksa point release05:15
jamielennoxstevemar: yea, i didn't expect to see you around at all05:15
jamielennoxsave it for the week05:16
*** chlong has joined #openstack-keystone05:22
stevemarjamielennox: yeah, i'll go through the specs monday morning, i think henry and gyee have some issues with domain roles05:24
*** dims has joined #openstack-keystone05:24
*** Nirupama has joined #openstack-keystone05:26
*** mylu has quit IRC05:32
*** mylu has joined #openstack-keystone05:34
*** dims has quit IRC05:46
*** roxanaghe has joined #openstack-keystone05:59
*** mylu has quit IRC05:59
*** mylu has joined #openstack-keystone05:59
*** navidp has joined #openstack-keystone06:14
*** dims has joined #openstack-keystone06:32
*** boris-42_ has quit IRC06:33
*** jaosorior has joined #openstack-keystone06:39
*** dims has quit IRC06:45
*** openstackgerrit_ has joined #openstack-keystone06:51
*** dims has joined #openstack-keystone06:52
*** roxanaghe has quit IRC06:55
*** josecastroleon has joined #openstack-keystone07:02
*** mylu has quit IRC07:03
openstackgerritMerged openstack/keystoneauth: Get versioned url for K2K auth  https://review.openstack.org/25168607:05
*** wanghua has joined #openstack-keystone07:22
*** chlong has quit IRC07:29
*** gildub has quit IRC07:32
*** btully has quit IRC07:43
*** amakarov has joined #openstack-keystone07:52
*** henrynash has joined #openstack-keystone07:56
*** ChanServ sets mode: +v henrynash07:56
openstackgerritChangBo Guo(gcb) proposed openstack/oslo.policy: Don't generate doc from test  https://review.openstack.org/25406108:12
*** ntt has joined #openstack-keystone08:18
*** e0ne has joined #openstack-keystone08:31
*** fhubik has joined #openstack-keystone08:39
*** e0ne has quit IRC08:55
*** mkoderer has quit IRC08:59
*** mkoderer has joined #openstack-keystone09:00
*** e0ne has joined #openstack-keystone09:00
*** e0ne has quit IRC09:03
*** fhubik is now known as fhubik_brb09:07
*** fhubik_brb is now known as fhubik09:08
openstackgerritOpenStack Proposal Bot proposed openstack/keystoneauth: Updated from global requirements  https://review.openstack.org/25408809:10
*** flwang1 has joined #openstack-keystone09:27
*** jistr has joined #openstack-keystone09:36
*** flwang1 has quit IRC09:42
*** btully has joined #openstack-keystone09:45
*** flwang1 has joined #openstack-keystone09:46
*** dims has quit IRC09:48
*** flwang1 has quit IRC09:50
*** mhickey has joined #openstack-keystone09:53
*** flwang1 has joined #openstack-keystone09:55
*** e0ne has joined #openstack-keystone09:56
*** aix has joined #openstack-keystone10:19
*** cburgess has quit IRC10:22
*** openstackgerrit_ has quit IRC10:23
*** cburgess has joined #openstack-keystone10:27
*** jistr has quit IRC10:29
*** jistr has joined #openstack-keystone10:30
*** ccard_ has joined #openstack-keystone10:30
openstackgerritMehdi Abaakouk (sileht) proposed openstack/keystonemiddleware: Keystonemiddleware shouldn't list options of other lib  https://review.openstack.org/25237310:31
*** cburgess has quit IRC10:31
*** sudorandom has quit IRC10:31
*** cburgess has joined #openstack-keystone10: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 to10: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 IRC10:36
*** fhubik is now known as fhubik_brb10:38
*** fhubik_brb is now known as fhubik10:41
*** sudorandom has joined #openstack-keystone10:41
*** cburgess has quit IRC10:41
*** cburgess has joined #openstack-keystone10:43
*** johnthetubaguy has quit IRC10:43
*** sudorandom has quit IRC10:46
*** johnthetubaguy has joined #openstack-keystone10:49
*** sudorandom has joined #openstack-keystone10:50
*** cburgess has quit IRC10:56
*** cburgess has joined #openstack-keystone10:59
*** lhcheng has joined #openstack-keystone11:01
*** ChanServ sets mode: +v lhcheng11:01
*** yangyapeng has quit IRC11:17
*** EinstCrazy has quit IRC11:17
*** topol has joined #openstack-keystone11:19
*** ChanServ sets mode: +v topol11:19
*** fhubik is now known as fhubik_brb11:21
*** johnthetubaguy has quit IRC11:21
*** johnthetubaguy has joined #openstack-keystone11:21
*** lhcheng_ has joined #openstack-keystone11:24
*** miyagishi_t has quit IRC11:26
*** lhcheng has quit IRC11:27
*** jed56 has quit IRC11:27
*** jed56 has joined #openstack-keystone11:28
*** fhubik_brb is now known as fhubik11:30
*** EinstCrazy has joined #openstack-keystone11:43
*** lhcheng_ has quit IRC11:44
*** fhubik is now known as fhubik_brb11:44
*** lhcheng has joined #openstack-keystone11:44
*** ChanServ sets mode: +v lhcheng11:44
openstackgerrithenry-nash proposed openstack/keystone-specs: An alternative to domain roles using implied roles  https://review.openstack.org/25413911:44
*** btully has quit IRC11:46
openstackgerrithenry-nash proposed openstack/keystone-specs: An alternative to domain roles using implied roles  https://review.openstack.org/25413911:48
*** noqa_v_q1ovnie is now known as noqa_v_qoovnie11:48
openstackgerrithenry-nash proposed openstack/keystone-specs: An alternative to domain roles using implied roles  https://review.openstack.org/25413911:50
*** fhubik_brb is now known as fhubik11:52
*** iurygregory has joined #openstack-keystone11:52
*** alexus is now known as alex_xu11:57
openstackgerritjaveme proposed openstack/python-keystoneclient: encode the url parameters  https://review.openstack.org/25415412:07
*** dims has joined #openstack-keystone12:08
openstackgerrithenry-nash proposed openstack/keystone-specs: An alternative to domain roles using implied roles  https://review.openstack.org/25413912:09
*** raildo-afk is now known as raildo12:14
*** links has quit IRC12:15
*** flaper87 has quit IRC12:17
*** flaper87 has joined #openstack-keystone12:17
*** doug-fish has joined #openstack-keystone12:19
*** chlong has joined #openstack-keystone12:30
*** Nirupama has quit IRC12:32
*** jaosorior has quit IRC12:36
*** jaosorior has joined #openstack-keystone12:37
*** jaosorior has quit IRC12:38
*** jaosorior has joined #openstack-keystone12:38
*** gordc has joined #openstack-keystone12:39
*** Nirupama has joined #openstack-keystone12:46
*** mylu has joined #openstack-keystone12:48
*** jed56 has quit IRC12:52
*** jed56 has joined #openstack-keystone12:52
*** mylu has quit IRC12:55
*** fhubik is now known as fhubik_brb12:56
*** fhubik_brb is now known as fhubik12:58
*** fhubik is now known as fhubik_brb12:58
*** pauloewerton has joined #openstack-keystone12:58
mordredjamielennox: any chance you're still around?13:00
*** thiagop has joined #openstack-keystone13:01
*** Nirupama has quit IRC13:01
*** wanghua_ has joined #openstack-keystone13:05
*** wanghua has quit IRC13:05
*** wanghua_ is now known as wanghua13:05
openstackgerritjaveme proposed openstack/python-keystoneclient: remove the default arguments "[]" or "{}"  https://review.openstack.org/25417513:06
*** Nirupama has joined #openstack-keystone13:17
*** jed56 has quit IRC13:25
*** jed56 has joined #openstack-keystone13:26
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Create unit tests for endpoint policy SQL driver  https://review.openstack.org/21200613:31
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Fixes query.one() return usage in endpoint-policy  https://review.openstack.org/20860913:34
*** edmondsw has joined #openstack-keystone13:39
*** Ephur has joined #openstack-keystone13:41
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Create unit tests for the policy backend  https://review.openstack.org/21295713:41
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Create unit tests for the policy SQL driver  https://review.openstack.org/21295713:43
*** boris-42_ has joined #openstack-keystone13:52
*** lhcheng_ has joined #openstack-keystone13:59
*** lhcheng has quit IRC14:00
*** Nirupama has quit IRC14:01
*** jerrygb has joined #openstack-keystone14:04
notmorganayoung: 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
ayoungnotmorgan, YAHOOO!14:09
notmorganayoung: it is missing a lot of the ca/cert etc options that are everywhere else14:09
notmorganayoung: let me show you.14:09
ayoungLets see it14:10
notmorganayoung: https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L177-L19614:11
notmorganabsolutely no way to pass the extra info.14:11
notmorganand 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 stuff14:12
notmorganso.. yay? =/14:12
notmorganand the previous version was just as bad.14:12
notmorgangetting people to use a common session object that handles these options sanely will solve it.14:13
notmorganbut basically this will *never* work with non-trusted certs/cas and TLS14:13
*** wanghua has quit IRC14:13
*** dims has quit IRC14:16
notmorganayoung: also really really easy +2/+A https://review.openstack.org/#/c/253966/14:16
*** hogepodge has quit IRC14:17
ayoungnotmorgan, done14:17
lbragstadsamueldmq responded - https://review.openstack.org/#/c/253669/1/test-requirements.txt14:17
*** Ephur has quit IRC14:17
ayoungnotmorgan, 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-keystone14:18
notmorganayoung: ugh. merge conflict14:18
notmorganayoung: yeah basically that code needs to be re-worked to use proper configs14:19
notmorganayoung: and the full range of configs ca-bundle etc14:19
openstackgerritMorgan Fainberg proposed openstack/keystonemiddleware: Use keystoneauth for auth_token fixture  https://review.openstack.org/25396614:19
ayoungnotmorgan, 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
notmorganayoung: this isn't even dependency injection. because it wouldn't have solved this really.14:20
notmorganit *could* solve it14:21
ayoungnotmorgan, yes it is, but I am not going down that path today....14:21
notmorganbut it's not guaranteed if someone just goes off and does "oh do X"14:21
notmorganso that aside14:21
notmorgan...14:21
notmorganadded this to the ever-growing list of "broken"14:21
openstackgerrithenry-nash proposed openstack/keystone: Create new version of assignment driver interface  https://review.openstack.org/24285314:23
*** marekd has quit IRC14:23
*** marekd has joined #openstack-keystone14:23
*** ChanServ sets mode: +v marekd14:23
xekbknudson, lbragstad, dstanek, please tell me what you think https://review.openstack.org/#/c/245186/ (my last comment)14:25
openstackgerrithenry-nash proposed openstack/keystone: Create V9 Role Driver  https://review.openstack.org/24780514:26
*** petertr7_away is now known as petertr714:28
openstackgerrithenry-nash proposed openstack/keystone: Use list_role_assignments to get projects/domains for user  https://review.openstack.org/24251314:29
*** navidp has quit IRC14:29
*** navidp has joined #openstack-keystone14:30
*** yasu has joined #openstack-keystone14:32
*** dims has joined #openstack-keystone14:34
*** yasu has quit IRC14:39
*** lhcheng_ has quit IRC14:40
*** raginbajin has quit IRC14:44
*** fawadkhaliq has joined #openstack-keystone14:44
*** raginbajin has joined #openstack-keystone14:46
marekdstevemar: can we reiterate on https://review.openstack.org/#/c/188534/ ?14:47
*** rderose has joined #openstack-keystone14:49
*** topol has quit IRC14:50
*** andrewbogott has quit IRC14:52
*** ctina has joined #openstack-keystone15:02
*** dims has quit IRC15:02
notmorganstevemar: so... neutron now uses KSA instead of KSC internally15:03
notmorganyay!15:04
notmorgannova will be next15:04
samueldmqlbragstad: looking15:07
*** diazjf has joined #openstack-keystone15:12
*** btully has joined #openstack-keystone15:12
*** davechen has joined #openstack-keystone15:13
*** hogepodge has joined #openstack-keystone15:14
*** rderose has quit IRC15:15
*** spotz_zzz is now known as spotz15:15
*** ctina has quit IRC15:16
*** ctina has joined #openstack-keystone15:16
*** rderose has joined #openstack-keystone15:16
*** henrynash has quit IRC15:17
*** davechen1 has joined #openstack-keystone15:19
*** tonytan4ever has joined #openstack-keystone15:19
*** ctina_ has joined #openstack-keystone15:19
*** fhubik_brb is now known as fhubik15:20
*** davechen has quit IRC15:22
*** ctina has quit IRC15:22
*** sigmavirus24_awa is now known as sigmavirus2415:22
*** navid_ has joined #openstack-keystone15:25
*** navid_ has quit IRC15:25
*** timcline has joined #openstack-keystone15:26
lbragstadxek reviewing it now15:30
lbragstadxek timcline is going to try and give it a review too, i was having a discussion with him on it a couple weeks ago15:30
lbragstadi think he'll be able to provide some good feedback, too15:31
xeklbragstad, ok, thanks!15:31
*** mylu has joined #openstack-keystone15:32
openstackgerritRonald Bradford proposed openstack/keystone: Use oslo.log provided method for log levels  https://review.openstack.org/25425315:32
openstackgerritLance Bragstad proposed openstack/keystone: Add checks for token data creep using jsonschema  https://review.openstack.org/25425815:39
lbragstadsamueldmq ^ versus https://review.openstack.org/#/c/253669/115:39
lbragstadcc: dstanek ^15:39
samueldmqlbragstad: nice, looking15:40
samueldmqlbragstad: I'd go with jsonschema15:41
samueldmqlbragstad: since it's something we already include as dependency, and the code doesnt' look bad at all :)15:41
samueldmqlbragstad: let's see what dstanek thinks about it15:41
lbragstadsamueldmq yeah, i don't think jsonschema is as readable as voluptuous but... o well15:41
samueldmqlbragstad: I agree with you on that point15:42
*** mylu has quit IRC15:43
openstackgerritTom Cocozzello proposed openstack/keystone: WIP List assignments with names  https://review.openstack.org/24995815:46
*** fhubik is now known as fhubik_brb15:47
*** ntt has quit IRC15:49
*** fhubik_brb is now known as fhubik15:49
*** pgbridge has joined #openstack-keystone15:50
dstaneksamueldmq: thinks about what?15:50
*** fawadkhaliq has quit IRC15:51
lbragstaddstanek https://review.openstack.org/254258 vs. https://review.openstack.org/25366915:52
lbragstadthey are fixing the same bug - but with two different approaches15:52
samueldmqdstanek: yeah ^ :)15:53
*** slberger has joined #openstack-keystone15:56
*** petertr7 is now known as petertr7_away15:57
*** lhcheng has joined #openstack-keystone15:59
*** ChanServ sets mode: +v lhcheng15:59
dstaneklbragstad: i'd rather stick to the json schema since it's something we have to know already16:02
lbragstaddstanek makes sense16:03
lbragstadi'll abandon the voluptuous approach16:03
samueldmqdstanek: I think the same :)16:03
lbragstadand rewrite the other patches using jsonschema16:03
dstaneklbragstad: 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 tests16:03
samueldmqlbragstad: ++16:03
*** fhubik has quit IRC16:04
openstackgerritFernando Diaz proposed openstack/keystone: WIP: Opt-out certain Keystone Notifications  https://review.openstack.org/25378016:06
*** petertr7_away is now known as petertr716:08
*** davechen has joined #openstack-keystone16:08
*** henrynash has joined #openstack-keystone16:09
*** ChanServ sets mode: +v henrynash16:09
*** davechen1 has quit IRC16:10
*** fawadkhaliq has joined #openstack-keystone16:24
*** EinstCrazy has quit IRC16:26
*** aix has quit IRC16:28
notmorganjoin #openstack-ceilometer16:29
notmorganugh16:29
*** slberger1 has joined #openstack-keystone16:29
*** slberger has quit IRC16:30
samueldmqnotmorgan: hehe, weechat ? :-)16:31
notmorganyes16:31
*** r-daneel has joined #openstack-keystone16:34
*** alex_xu has quit IRC16:35
openstackgerritMerged openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/25164016:38
*** davechen has quit IRC16:39
*** mhickey has quit IRC16:39
henrynashstevemar, 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
dstaneknotmorgan: so close16:41
notmorgandstanek: right?16:41
*** mylu has joined #openstack-keystone16:41
*** mylu has quit IRC16:42
*** Guest18099 is now known as redrobot16:43
*** alex_xu has joined #openstack-keystone16:43
ayounghenrynash, 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 we16:44
ayoungare going to get16:44
*** ctina_ has quit IRC16:44
ayoungI don't think adding a new top level concept like role-groups will be less confusing.  You know my arguments.16:44
henrynashayoung: 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 like16:45
*** davechen has joined #openstack-keystone16:45
henrynashayoung: I prefer the current (merged) approach16:47
ayounghenrynash, yep.16:47
ayounghenrynash, I do wonder if we are going to find another way to namespace roles beyond domains16:48
ayounghenrynash, I could see a namespacing that we want to make queryable at the application level16:48
ayoungwordpress:editor and so on16:48
*** david-lyle has joined #openstack-keystone16:49
henrynashayoung: 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
ayounghenrynash, it might make the concpet of "reuse the name role" more palatable, though, if we can plot that out16:50
*** links has joined #openstack-keystone16:53
ayounghenrynash, then the story is that global roles are for openstack servuices and show up in tokens. All other namespaced roles are queried by namespace16:53
ayoungcan you think of a case where domain scoped roles would need to be queried?16:53
henrynashayoung: you mean list roles by domain_id or so you mean “list all roles that are domain specific for any domain”?16:54
ayounghenrynash, "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-keystone16:55
*** ChanServ sets mode: +v topol16:55
dstanekxek: i'm a little confused as to when you'd update the schema16:55
henrynashayoung: not sure I can parse that sentance16:55
ayounghenrynash, '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-keystone16:58
ayoungpseudo code :  select all roles_assignemtnt where user = hentryname and role_assingmnet.role.domain_name = 'HAL';16:58
ayounggah16:58
lbragstaddstanek do you happen to have any numbers on last friday's bug activity?16:58
ayoungpseudo code :  select * from roles_assignments where user.name = henrynash and role_assignmnet.role.domain_name = 'HAL';16:59
dstaneklbragstad: 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 time16:59
lbragstaddstanek ah, no worries. i was just curious16:59
xekdstanek, right now, the schema is always upgraded before running the new code, I don't suggest changing this behavior16:59
lbragstadxek dstanek I think that's something we need to determine. We need to lay out all the expectations before hand17:00
henrynashayoung: 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 explicitely17:00
*** ninag has joined #openstack-keystone17:00
dstanekxek: you actually do imply it when you talk about data migrations17:01
ayounghenrynash, so...forget tokens.  They are a dead end.  Lets assume we get rid of them, and instead, ecverything queries Keystone directly to get role lists17:01
ayoungso nova asks "give me the roles for user that relate to Nova" and so on17:01
dstaneklbragstad: yes, that's why i'm a little woried about this spec as it's confusing topics17:01
ayoungif we lived in the counterfactual world, would we ever need domain scope roles for something?17:01
dstanekxek: 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-keystone17:09
*** diazjf has quit IRC17:09
xekdstanek, I think the order of 2-3 is switched17:10
dstanekxek: that's fine because it doesn't matter17:10
dstanekso picking a prescribed set of steps will impact how we code for schema migrations17:11
xekdstanek, because they run the migrations scripts of the new release, which migrate the schema to be compatible with the new release17:11
*** jistr has quit IRC17:11
xekdstanek, my change proposes, to not make incompatible changes, so the migration scripts would not break the old release, which could be still running17:11
*** davechen has quit IRC17:12
dstanekxek: i don't think that is true at all. we can in code make changes that are not backward compatible without making schema changes17:13
bknudsonthere's going to be tests in place to ensure that doesn't happen.17:13
xekdstanek, I agree, but this is still a step forward17:13
dstanekfor example, changing how we interpret data17:13
dstanekxek: i'm not saying it's not just that we need to define the rules better in that spec17:13
xekbknudson, dstanek, I want to work on grenade tests, to address other incompatibilities17:14
*** links has quit IRC17:14
xekbut it's out of scope of that spec, which (I think) should only address the online schema migration problem17:14
xekmaybe together with data migration17:14
xekbut right now, there is no clear-cut solution for data migration17:15
lbragstadcc timcline rderose17:15
xekup to date, what I proposed, is realy just doing it case by case17:15
dstanekxek: for example, are we allowing adds?17:15
marekdstevemar: ping17:16
marekdstevemar: 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
henrynashdstanek: 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/2617:16
xekdstanek, the unit test would only disallow drops and alters, and those could still be added to the list of exceptions17:16
dstanekhenrynash: sure17:16
xekdstanek, so adds are allowed17:17
henrynashdstanek: thx17:17
lbragstadxek dstanek what do we want this spec to solve?17:17
stevemarmarekd: looking now17:17
marekdstevemar: thank you, boss17:17
lbragstadzero downtime migrations?17:17
dstanekxek: adds can introduce backward incompatibilities right?17:17
lbragstador rolling upgrades?17:17
xeklbragstad, online schema migration, which is one of the pieces needed for rolling upgrades17:18
dstaneklbragstad: i think we have more control over rolling upgrades17:18
stevemarmarekd: commented!17:18
marekdstevemar: looking.17:18
stevemarmarekd: maybe we should aask the API working group17:18
lbragstaddstanek so having more control, what exactly does that mean?17:18
marekdstevemar: line 890 is 'service_providers', which is not sp_group nor service_providers_groups17:19
dstaneklbragstad: 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 far17:19
xekdstanek, I don't think they can cause backward schema incompatibilities17:20
henrynashremind me…is the midcycle in Austin or San Antonio…..17:20
lbragstadhenrynash Austin17:20
dstanekxek: sure, add a new column that doesn't have a default17:20
henrynashthx17:20
dstanekxek: old code won't work17:20
henrynashalmost booked a flight to San Antonio out of habit!17:20
lbragstadso, now we are assuming that we can't allow anything that has an ALTER table, or equivalent17:20
lbragstadhenrynash you could drive up with me!17:20
xekdstanek, yes, it needs a default17:21
henrynashalways looking on ways to make my trave schedules longer :-)17:21
marekdstevemar: ok, let me just change to service_provider_group and we will be consistent.17:21
dstanekxek: adding a new foreign key (or maybe even just an index) could fail as well17:21
lbragstadyeah, adding a column to a table is effectively an ALTER table statement, which will lock the table17:22
dstanekxek: 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 that17:22
*** petertr7 is now known as petertr7_away17:22
bknudsonwhether the table lock causes a problem or not is going to depend on the size of the table17:22
lbragstadbknudson ++17:22
bknudsonand what the table is used for17:22
rderosexek: I thihk you mentioned that this has been implemented in Nova, so you have a link to the patch by any chance?17:23
dstanekbknudson: yep17:23
lbragstadwe 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 deployments17:23
xekrderose, it was a while ago https://github.com/openstack/nova/blob/stable/liberty/nova/tests/unit/db/test_migrations.py#L224-L22517:24
bknudsonthat fixture should be moved into oslo if it's useful across projects17:24
*** zz_john5223 is now known as john522317:25
bknudsonoslotest or oslo.db17:25
stevemarmarekd: join -sdks17:25
dstanekthey've only implemented a check that allows exceptions right. they didn't directly tackle the issue yet did they?17:25
lbragstadxek are we the only other project besides nova looking at a test like that?17:25
xeklbragstad, I think cinder right now17:26
*** e0ne has quit IRC17:27
dstanekit may be a good opportunity to have all 3 groups talk through the problem17:27
xeklbragstad, I think they also have a spec with an example scenario of migrating the data17:27
xeklbragstad, http://git.openstack.org/cgit/openstack/cinder-specs/tree/specs/mitaka/online-schema-upgrades.rst17:28
dstanekxek: is their goal 0-downtime migrations?17:28
xekdstanek, yes17:28
dstanekhow are they tackling the locking issues?17:29
openstackgerritTom Cocozzello proposed openstack/keystone: Improve code and comments in test_catalog  https://review.openstack.org/24884617:29
xekdstanek, I don't know if they discussed them17:29
lbragstadxek  do you know who worked on it from cinder?17:30
xekdulek, is the author of the spec17:30
dstanekxek: do you have a link to their spec?17:30
xekdstanek, last link above17:31
dulekxek: I can chime in in a moment, meeting.17:31
dstanekxek: that doesn't seem to be about 0-downtime does it?17:31
xekdulek, told me, the main purpose of the spec was to demonstrate a scenario for 0-downtime upgrade17:32
*** petertr7_away is now known as petertr717:32
dstanekxek: it seem to just defer17:32
dulekdstanek: It is totally.17:32
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Fixes query.one() return usage in endpoint-policy  https://review.openstack.org/20860917:32
dstanekdulek: "All of these should be run when all the services are down." - when does that happen then?17:32
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Create unit tests for endpoint policy SQL driver  https://review.openstack.org/21200617:32
*** rderose has quit IRC17:33
xekdstanek, it's in the problem description section17:33
dstanekdulek: how do you deal with the potential table locking on large tables?17:33
dstanekxek: so it's saying that you can never do those?17:33
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Create unit tests for the policy SQL driver  https://review.openstack.org/21295717:34
openstackgerritMerged openstack/keystonemiddleware: Use keystoneauth for auth_token fixture  https://review.openstack.org/25396617:34
*** davechen1 is now known as davechen17:34
xekdstanek, I know that nova splits the data migration into smaller pieces before execution17:34
dstanekxek: 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
xekdstanek, the scripts performing the migration can be run with different parameters to specify the chunk of data that is migrated17:35
samueldmqmordred: ping - you around ?17:36
dstanekxek: sure i've done incremental and on-demand migrations in the past. all of this seems to assume running 'alter ...' will always be 0 downtime17:36
samueldmqmordred: about os-client-config17:36
mordredI didn't do it17:37
xekdstanek, I don't know if this is addressed in nova, dansmith is the person to ask17:37
dstanekxek: i was worried that 'alter ...' could table lock on mysql and you were the one that proved me right :-)17:38
samueldmqmordred: :-) 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 option17:38
mordredsamueldmq: yah - one of the two17:38
dstanekxek: 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 decided17:39
mordredsamueldmq: are you just wanting to create a keystoneclient object from an occ cloud?17:39
samueldmqmordred: kk so I will need to do if/elses17:39
samueldmqmordred: yep17:39
mordredsamueldmq: client = cloud.get_legacy_client('identity', keystoneclient.Client)17:39
* dulek just ended a meeting, caching up with log.17:40
mordredsamueldmq: scuse me - keystoneclient.client.Client17:40
xekdstanek, 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 complete17:40
samueldmqmordred: oh wait, I have an object that is the return from openstack_config.get_one_cloud17:40
mordredsamueldmq: so ... client = os_client_config.OpenStackCloud().get_one_cloud(cloud='devstack').get_legacy_client('identity', keystoneclient.client.Client)17:40
mordredyup17:41
samueldmqmordred: so taht is a cloud that I can call get_legacy_client ?17:41
mordredyup17:41
samueldmqmordred: wtf ?17:41
mordredwell, it's a CloudConfig actually17:41
samueldmqmordred: that's so easy :-)17:41
mordredsamueldmq: there is an even easier method you could use - but I need to cut a new occ release with it17:41
dstanekxek: 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 deferring17:42
samueldmqmordred: like give_me() and that's all ? :-)17:42
lbragstadalso, especially with keystone, we should be mindful of different levels of SLAs17:42
dulekxek, dstanek: So in case of Nova they don't do any ALTERs that can lock the table.17:42
mordredsamueldmq: in the next release, you can just do "os_client_config.make_client('identity', cloud='devstack')"17:42
lbragstaddon't all ALTERs lock the table?17:43
samueldmqmordred: great!17:43
samueldmqmordred: can I specify the version of the client too ?17:43
duleklbragstad: Depends on the DB, but I believe not.17:43
dulekdstanek: This is probably the best writeup on the matter: http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/17:43
dstanekdulek: i think we were reading the MySql docs about that last week and it implied that it did17:43
mordredsamueldmq: you can specify the version of the api, yes17:44
mordredsamueldmq: add identity_api_version='3' to the kwargs of get_one_cloud17:44
dulekdstanek: http://dev.mysql.com/doc/refman/5.7/en/alter-table.html17:45
dulekdstanek: "For some operations, an in-place ALTER TABLE is possible that does not require a temporary table:"17:45
samueldmqmordred: alright, thanks!17:45
dulekdstanek: 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
xekdstanek, dulek, oh, so adding an index on innodb doesn't cause a lock?17:46
samueldmqmordred: please let me know when when have a new release17:46
*** tonytan4ever has quit IRC17:46
mordredsamueldmq: hopefully today17:46
dstanekdulek: so adding columns isn't safe?17:46
dulekxek: Check out my "if" in parentheses. ;) I'm not a DB geek, so I'm not sure.17:46
samueldmqmordred: oh, so I will use the new syntax :)17:47
lbragstadso, if adding new columns isn't safe, then we have to add new tables if we want new columns?17:47
dulekdstanek: Ah, good point, I'm not sure here…17:47
dstanekdulek: ready a little lower. it says they can't because the table needs rebuilt17:48
*** lhcheng_ has joined #openstack-keystone17:48
*** diazjf has joined #openstack-keystone17:48
dstanekdulek: are deletes just never allowed anymore?17:49
lbragstadthat would be bad17:49
openstackgerritMarek Denis proposed openstack/keystone-specs: Expand endpoint filters to service providers  https://review.openstack.org/18853417:49
marekdstevemar: notmorgan amakarov ^^17:50
*** lhcheng has quit IRC17:51
dulekdstanek: 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
dstanekactually 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 IRC17:51
dstanekdulek: 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 IRC17:52
*** petertr7 is now known as petertr7_away17:52
dulekdstanek: Having an exclusive lock on a table will result in errors instead of clients just waiting?17:53
*** edmondsw has quit IRC17:53
xekdulek, dstanek, the doc says, that reads are still executable on the old table, only writes are waiting17:54
*** diazjf has quit IRC17:54
dstanekdulek: yes. so something kills the connection and retries. what would happen? probably an error saying the record already exists17:55
dstaneksince 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 required17:56
lbragstad++17:56
dstaneknot deleting would be terrible, but i "could" be convinced that it would be a good thing. no adds would be a non-starter17:57
openstackgerritTom Cocozzello proposed openstack/keystone: Improve code and comments in test_catalog  https://review.openstack.org/24884617:57
dulekdstanek: Nova and Cinder never considered no adds.17:57
lbragstaddstanek I don't like that only because we'll end up with a polluted schema17:57
*** roxanaghe has joined #openstack-keystone17:58
dstaneklbragstad: we could in theory do a destructive migration every other release. not that i like that.17:58
lbragstaddstanek we'd still have downtime, just not as often17:59
*** jistr has joined #openstack-keystone17:59
duleklbragstad: Deleting a table can be done without downtime if it is unused.17:59
duleklbragstad: And I think deleting a column is the same as adding it.18:00
*** slberger has joined #openstack-keystone18:00
dstaneklbragstad: yep, that's my point. 0-downtime is an unobtainable goal, but something we should work towards18:00
*** shaleh has joined #openstack-keystone18:00
dstaneka 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
lbragstadyeah, that's interesting because we would have to advertise that we only support "close" to 0 downtime, from certain releases18:01
*** fawadkhaliq has joined #openstack-keystone18:02
duleklbragstad: I don't think that's true. This model should work for all of them.18:02
dstaneklbragstad: right. i see the rolling upgrades as a step in that direction18:02
dulekdstanek: CERN for example always upgrade N+1. Nova also enforces that now.18:02
dstanekdulek: we're not going to keep code around that understands every version of a schema forever18:02
*** timcline has quit IRC18:03
dulekdstanek: True. Just X-1. I mean - Nova enforces that you only upgrade X-1 to X. Never X-2 to X.18:04
lbragstadright, that's what I meant18:04
lbragstadwe would have to move to a model like that18:04
*** dansmith has joined #openstack-keystone18:04
dstanekdulek: lbragstad: exactly. right now it doesn't matter for us18:05
xekdstanek, 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 releases18:05
lbragstadxek will we have performance issues if we keep adding tables?18:06
xekwe would have to save data in two places if we want to stay fully compatible18:06
dulekdstanek: 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 petertr718:07
lbragstadxek 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
dansmithwhy are you duplicating tables so much?18:08
lbragstaddansmith o/18:09
xekin the first release we would still read from the old place18:09
dansmithcreating a new table to handle some sort of upgrade should really only be necessary in extreme situations, right?18:09
dstanekdulek: 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
xekin the seccond release, we would enforce the new foreign key and drop the old one18:09
xek*second18:09
lbragstaddansmith 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 downtime18:10
dansmithlbragstad: alter table does not always lock the table, it depends on what's happening AFAIK18:10
dansmithlbragstad: for example, you should be able to add a column with recent mysql and not lock the whole table18:10
dstaneklbragstad: 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 be18:13
lbragstaddstanek I'd agree with that18:13
dansmithdstanek: 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
dansmithdstanek: 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, etc18:14
dstanekdansmith: in our review i said that we can't always make the guarantee18:14
dstanekdolphm: http://paste.openstack.org/show/481065/18:14
dansmithdstanek: 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 desirable18:14
dstanekdansmith: totally agree18:14
dstanekdansmith: that's why i want to focus on rolling upgrades and having keystone N+1 understand the schema from N18:15
dansmithdstanek: well, that's the opposite of what we're doing.. feels harder that way to me18:15
dstanekdansmith: all code can be updated and work fine and the schema can be updated and migrated after. so different releases may have different downtime requirements18:16
dansmithdstanek: because you may have APIs that take new arguments that you literally can't store because you don't have the new spot opened up18:16
*** dims has joined #openstack-keystone18:16
dansmithdstanek: 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 why18:16
lbragstaddansmith so you always guarantee the api layer is updated first before rolling out schema changes18:17
dansmithlbragstad: I'm not sure who "you" is in that statement18:18
*** RichardRaseley has joined #openstack-keystone18:18
dstanekdansmith: i was thinking that we'd support the older API version until the schema was updated18:18
dansmithlbragstad: you can build controls into the api to let you disable things that are not possible yet18:18
lbragstaddansmith as an operator18:18
dstanekdansmith: i'd be fine with the expand/contract idea behind migrations18:18
dansmithdstanek: yeah, if your API workers always know what the current schema is18:18
dansmithdstanek: 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 that18:19
dstanekdansmith: that's not too hard of a problem. we solved that at my old job.18:19
dansmithdstanek: no, it's doable for sure18:19
dansmithdstanek: it's just higher potential for mistakes, IMHO18:19
dstanekkeystone isn't nearly as complicated18:19
dansmithdstanek: 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 it18:20
dansmithdstanek: that is surely true, so maybe that makes sense for keystone18:20
dansmithdstanek: it'll be unfortunate to have two components approach it in opposite ways, but c'est la vie18:20
dstanekdansmith: 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 statement18:21
dansmithdstanek: yep, not arguing.. what you're saying makes sense of course18:21
dstanekdansmith: when do you plan on doing the locking operations like deleting a column?18:21
dansmithdstanek: I'm not sure deleting a column is locking necessarily, but we delete columns after they've been removed from the model18:22
dansmithdstanek: the other thing to consider here is how sqla works18:22
xekdstanek, ++ I think it's settled that we remove the "blanket 0-downtime statement"18:22
dansmithdstanek: sqla will select all columns by name every time18:22
dansmithdstanek: which means you will have to either have two models for every change edge, and use the right one when querying based on schema version18:23
dansmithdstanek: or you need to explicitly exclude a column from being loaded when you query if you know it's not present yet18:23
dstanekdansmith: is that your blog post on danplanet.com?18:23
dansmithdstanek: otherwise sqla will generate "SELECT old1,old2,new FROM TABLE.." when new is not a column yet18:23
dansmithdstanek: is what in there?18:23
openstackgerritSamuel de Medeiros Queiroz proposed openstack/python-keystoneclient: WIP: Implements base classes for functional tests  https://review.openstack.org/25397118:23
samueldmqmordred: something like this ^18:24
lbragstaddstanek is this the one you're talking about - http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/18:24
dstaneklbragstad: dansmith: yes, that's been very helpful in understanding the specs18:24
*** e0ne has joined #openstack-keystone18:24
dansmithdstanek: oh you said "is that" mine.. yes...18:25
*** henrynash has quit IRC18:25
openstackgerritSamuel de Medeiros Queiroz proposed openstack/python-keystoneclient: WIP: Implements base classes for functional tests  https://review.openstack.org/25397118:26
dstanekdansmith: so assuming that deletes do alter the schema so that it requires a lock. what happens?18:28
mordredsamueldmq: yes. very sclose18:28
*** davechen1 has joined #openstack-keystone18:28
*** EinstCrazy has joined #openstack-keystone18:28
*** browne has joined #openstack-keystone18:28
dansmithdstanek: 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 locked18:28
dansmithdstanek: 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 time18:29
dansmithdstanek: 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
dansmithmaking it completely monolithic18:30
*** davechen has quit IRC18:30
dstanekdansmith: ok, that makes sense.18:30
dstanekdansmith: do you call out which RDBMSes have the required behaviors?18:31
dansmithdstanek: no, we're not quite that organized, unfortunately :/18:31
*** rderose has joined #openstack-keystone18:31
xekdstanek, I think postgres is the best fit, since you can rollback schema changes18:32
dstanekdansmith: fair enough18:32
*** rderose has quit IRC18:32
xekdstanek, so in case your table get's locked and the service goes down, you can rollback the schema alteration18:32
xekdstanek, and repeat it under different conditions18:32
samueldmqmordred: I thought it was client because of what keystonecient receives in tis contructor https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/client.py#L3218:32
dstanekxek: 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 upgrades18:33
samueldmqmordred: I thought it was 'version' vs 'identity_api_version'18:33
dansmithdstanek: xek it's mostly a question of "which mysql version are you running" as it has improved a lot just in recent 5.x releases18:33
mordredsamueldmq: occ processes versions and does the right thing under the covers - so you need to tell it identity_api_version18:33
*** EinstCrazy has quit IRC18:34
*** timcline has joined #openstack-keystone18:34
samueldmqmordred: ++ I should hae trusted from the first time you told me :)18:35
mordred:)18:35
*** tonytan4ever has joined #openstack-keystone18:36
openstackgerritSamuel de Medeiros Queiroz proposed openstack/python-keystoneclient: WIP: Implements base classes for functional tests  https://review.openstack.org/25397118:37
lbragstaddansmith 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.foobars18:37
dansmithlbragstad: well, it's updated to know about the new schema. It's moving things because of something higher than schema.. requirements or something18:38
lbragstaddansmith ok.18:39
dansmithlbragstad: 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 place18:39
*** edmondsw has joined #openstack-keystone18:39
lbragstaddansmith the case where upgrading releases immediately wouldn't necessarily ensure all data was converted, right?18:41
lbragstador there would have to be some time minimum amount of time in between upgrades.18:42
*** spandhe has joined #openstack-keystone18:42
dansmithlbragstad: I'm not sure I understand what you're asking.. maybe I distracted us with the schema terminology nit...18:42
dansmiththere is no minimum time between upgrades.. there is a maximum time, of course.18:43
*** timcline has quit IRC18:43
lbragstaddansmith 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
dansmithlbragstad: ah, I see so, there are two things we do here18:45
dansmiththe first is we provide a thing that lets the operator push the lazy migrations manuall18:45
dansmithso, there is a nova-manage subcommand that says "do N flavor migrations right now please"18:45
dansmithwhich will pick the first N unconverted things, and just load/save them to push the migration18:46
lbragstadah18:46
dansmiththey can do that in parallel to normal operations in small batches to slowly convert things over time18:46
*** flwang1 has quit IRC18:46
dansmithwhen it starts returning zero candidates, they're done18:46
dansmiththen, when we're looking to make sure they have completed this work,18:46
dansmithwe land a migration that does nothing other than count the number of unconverted things, and fail if it's nonzero18:47
bknudsondoes nova allow doing the "contract" schema changes during the current release? or does it have to wait until the next release?18:47
dansmithwe 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 homework18:47
dansmithbknudson: right now we wait a release, yeah, because of the sqla problem basically18:47
dansmithwell, it's not a problem, it's just a reality18:48
bknudsonok, would be nice for anybody tracking master18:48
lbragstaddansmith interesting, so an operator will know if they can drop a table based on if they can migrate to a given version.18:48
bknudsonbut I don't know how you'd accomplish it... maybe version every table18:48
dansmithlbragstad: well, what we do is we land the drop after we land the barrier migration18:48
dansmithso they can't get to the drop if they have anything still in their database that is unconverted18:48
lbragstaddansmith so it's seemless18:48
dansmithyeah, so they don't really notice any difference18:49
lbragstadcool18:49
lbragstadthat makes sense18:49
dansmithin the case of a larger thing like a TEXT field, simply NULLing it out when you convert it saves the space18:49
*** timcline has joined #openstack-keystone18:49
dansmithand for something smaller, like an integer there isn't much waste to be had by waiting for the drop18:49
dansmithfor a long string or something there could be,18:49
dansmithbut most people seem to like the idea of less downtime in exchange for carrying more bytes for a short period of time18:50
bknudsonif you have to support old releases for an entire release then you can't NULL out the field18:50
dansmithwell, true, you guys can't18:50
dansmithwe can18:50
lbragstaddansmith and that can be approached case-by-case depending on the migration18:50
dansmithbecause we have conductor, which knows that older nodes need things to look like they're expecting18:50
dansmithlbragstad: yes18:50
dansmithso conductor and objects here provide us insulation from this18:50
bknudsonunless somehow keystone was told to ignore the field in the new code18:51
dansmiththe 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 query18:51
bknudsonconfig option or checking the schema version18:51
dansmithwhich means we can null things out when we're done18:51
dansmithif you have no such gatekeeper, then you will have to be careful18:51
dansmithbknudson: the other thing you need to think about with no gatekeeper,18:51
dansmithis that if your migration process moves things from one column to the other, but doesn't null out the old one,18:52
dansmithan older node with direct access will continue using/modifying the old value,18:52
dansmithbut newer nodes will not keep converting that older data18:52
bknudsonthis 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 cve18:52
dansmithso either you need to always keep both in sync and handle that on newer nodes, or you need something else to account for that18:52
bknudsondansmith: do you think there's adequate testing for nova on-line upgrade? does grenade test it?18:53
xekdansmith, yes in the spec I proposed a scenario which I think is bullet-proof, but it spans 4 releases, like the one dulek proposed18:53
openstackgerritSean Perry proposed openstack/keystone: Clean up new_credential_ref usage and surrounding code  https://review.openstack.org/24671318:54
dansmithbknudson: 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 be18:54
dansmithbknudson: so we have a job that starts up nova with two nodes.. two computes, one of which also runs the control services18:55
dansmithbknudson: 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 code18:55
dansmithbknudson: we've had that for like three cycles now18:55
bknudsonmaybe we could take advantage of that18:55
bknudsonrun 2 keystones18:55
dansmithbknudson: it catches a _lot_ of things18:55
dansmithbknudson: yep18:56
bknudsonxek: is that the kind of testing you were planning on updating?18:57
xekbknudson, yes, I think multi-node grenade can achieve this18:57
dansmithneutron is working on similar things right now in this area of testing18:58
bknudsonseems like it would be kind of random but better than nothing.18:58
xekdansmith, I heard it was already added as a non-voting job18:58
bknudsonsince tests would just send requests to one or the other18:58
dansmithbknudson: 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 successfully18:59
xekbknudson, I think you can direct the client to connect only with the old or new version, so they are fully tested18:59
lbragstadso splitting requests between the two nodes18:59
dansmithbknudson: 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
xekbknudson, also, some data should be generated, to test live migration18:59
dansmithxek: no, the complicated ones come from accessing and modifying one entity on both versions18:59
dansmithxek: i.e. create on new, modify on old, read on new, make sure nobody has corrupted the state19:00
bknudsonalright, 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 it19:00
xekdansmith, ok, but then someone can just say "recheck" and the test could pass...19:00
bknudsonwe've had the issue in the past where we're not testing some pretty important features in gate19:01
*** aginwala has joined #openstack-keystone19:01
dansmithxek: indeed, so getting to something predictable would be good, which is my point19:01
bknudsonfor example, we still don't have gate testing for federation19:01
openstackgerritPriti Desai proposed openstack/keystone: Fix for GET project by project admin  https://review.openstack.org/24889219:02
bknudsondansmith: have operators reported bugs in the live upgrade code? just wondering if it's been a lot of maintenance19:02
xekbknudson, I'll add creating the grenade test to the work items on the spec19:03
bknudsonbugs in database migrations are a pain.19:03
dansmithbknudson: no it's perfect19:03
dansmithbknudson: also, I have this bridge for sale19:03
bknudsonmaybe I could find an example of a backported fix in nova?19:04
dansmithbknudson: 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 something19:04
dansmithbknudson: it has been largely successful I think19:04
*** sigmavirus24 is now known as sigmavirus24_awa19:04
dansmithbknudson: 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 sigmavirus2419:05
bknudsonI didn't see any where the migration had to be fixed... probably because it's handled in the object layer19:10
*** agireud has joined #openstack-keystone19:14
dansmithbknudson: we've never had to fix a schema migration, that I know of19:15
dansmithbknudson: this approach makes schema migrations mostly trivial, which is quite nice19:15
raildostevemar: 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
lbragstaddstanek bknudson xek so, based on everything just discussed. do we feel comfortable with the direction?19:19
bknudsonI'm fine with it.19:19
bknudsonI think we'll need to do it to support our deployments19:19
xekok, I'm modifying the spec to take into account all comments + adding grenade to the work items + removing the 0-downtime statements19:20
lbragstadxek in addition to the keystone-manage subcommands19:21
dstaneki was always fine with it, just not how we documented it19:21
dstanekxek: ++ awesome thx19:21
bknudsonis it actually grenade that's the test? or something else?19:21
*** davechen has joined #openstack-keystone19:21
*** davechen1 has quit IRC19:21
lbragstaddansmith that's for taking the time to clarify this19:22
lbragstadand field questions19:22
xekbknudson, grenade can check the upgrade process and then leave some nodes running with the old version19:22
dansmithlbragstad: no problem19:22
xek(or one node in case of this test)19:23
xekbknudson, and then run tempest on both19:24
*** jistr has quit IRC19:26
openstackgerritSean Perry proposed openstack/keystone: Use new_policy_ref consistently  https://review.openstack.org/24725719:27
mfischclayton: lbragstad can talk now19:27
lbragstadmfisch ok19:27
mfischbasically clayton found that keystone fails to start if the fernet keys are not writable19:27
claytonhey19:27
mfischwhich makes sense for keystone-manage but not keystone itself19:28
mfischwe found it when he was dockerizing19:28
lbragstadhmmm19:28
lbragstadlet me see if I can recreate19:28
mfischin  validate_key_respository()19:28
mfischwhich I assume they both use19:28
claytonyes, they do19:28
mfischwe dont use keystone-manage to roll keys so dont care if it is unhappy but want keystone to run19:29
mfischwith least perms19:29
claytonhttps://github.com/openstack/keystone/search?utf8=✓&q=validate_key_repository19:29
claytonspecifically 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#L3519:30
claytonand that function is called by load_keys19:30
*** diazjf has joined #openstack-keystone19:30
bknudsonI like the check mark in the URL!19:31
mfischthought we'd bring it up here and avoid a bikeshed review19:31
claytonhah, I didn't notice19:31
bknudsonwe should use that rather than true / false19:31
openstackgerritSean Perry proposed openstack/keystone: Use assertDictEqual instead of assertEqualPolicies  https://review.openstack.org/25148219:31
shalehlbragstad: I rebased ^^ for you19:32
openstackgerritSamuel de Medeiros Queiroz proposed openstack/python-keystoneclient: Implements base classes for functional tests  https://review.openstack.org/25397119:32
*** lhcheng_ has quit IRC19:34
*** ctina_ has quit IRC19:40
lbragstadshaleh thanks!19:41
*** aginwala has quit IRC19:44
*** diazjf has quit IRC19:45
*** e0ne has quit IRC19:45
lbragstadclayton mfisch so; this is what i get19:46
lbragstadclayton 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-py19:47
lbragstadclayton mfisch are you recreating differently?19:47
claytonlbragstad I believe it's checking the permissions on the directory the keys are in, not the keys themselves.19:47
lbragstadclayton ok, let me reproduce with that19:47
*** aginwala has joined #openstack-keystone19:48
lbragstadclayton http://cdn.pasteraw.com/nng0up76dgy5b3naw0hw4bdabdkin8419:48
lbragstadclayton same thing you experienced?19:49
claytonyeap, exactly.19:49
lbragstadclayton ok, so keystone-manage should care about that, obviously because it has to be able to write keys to the directory19:50
lbragstadbut we could probably work in a flag for that19:50
*** flwang1 has joined #openstack-keystone19:50
lbragstadclayton do you guys have a new bug open?19:50
claytonnod, 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
claytonI think mfisch wanted to run it past you first19:50
*** pumaranikar has joined #openstack-keystone19:51
lbragstadclayton sounds good, feel free to create a bug, or i can do it19:52
*** tqtran_ has joined #openstack-keystone19:52
*** fawadkhaliq has quit IRC19:54
*** davechen1 has joined #openstack-keystone19:55
*** jasonsb has quit IRC19:55
*** fangxu has joined #openstack-keystone19:56
*** diazjf has joined #openstack-keystone19:56
ayoungsamueldmq, check with stevemar on the extensions part of https://review.openstack.org/#/c/253587/  to se if the docs l;ocations should change for extensions19:56
ayoungif he says its good, I'm ok with the patch19:56
*** davechen has quit IRC19:56
samueldmqstevemar: ^ :)19:57
*** ninag has quit IRC19:58
*** ninag has joined #openstack-keystone19:58
*** e0ne has joined #openstack-keystone19:59
openstackgerritTom Cocozzello proposed openstack/keystone: Improve comments in test_catalog  https://review.openstack.org/24884620:02
stevemarlooking20:02
*** e0ne has quit IRC20:02
*** ninag has quit IRC20:03
*** woodster_ has joined #openstack-keystone20:05
stevemarsamueldmq: ayoung 1 small issue20:06
samueldmqtjcocozz: actually you didn't address this ? https://review.openstack.org/#/c/248846/5..6/keystone/tests/unit/test_catalog.py20:07
*** lhcheng has joined #openstack-keystone20:07
*** ChanServ sets mode: +v lhcheng20:07
samueldmqstevemar: sure, share it with us20:07
* tjcocozz looking now20:07
stevemarsamueldmq: oh i put it in the review20:07
samueldmqstevemar: sure thanks sir!20:08
tjcocozzsamueldmq, I think forgot to press save on that doc.  :-/ uploading the right one now.20:11
openstackgerritTom Cocozzello proposed openstack/keystone: Improve comments in test_catalog  https://review.openstack.org/24884620:11
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Update extensions links  https://review.openstack.org/25358720:13
notmorganjamielennox: you happen to be around?20:14
samueldmqstevemar: ayoung: done ^20:14
notmorganjamielennox: because i could use a little help20:14
samueldmqtjcocozz: sure sir :)20:14
notmorganjamielennox: on some KSA things20:14
stevemarnotmorgan: what ksa things?20:16
tjcocozzsamueldmq, haha or maybe I'm just a noob.20:16
samueldmqtjcocozz: nah, you and git just need to get along (a day) - copied from shaleh :)20:17
notmorganstevemar: 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.py20:17
stevemarnotmorgan: i saw that over the weekend20:18
stevemarneat tuff20:18
stevemarstuff20:18
notmorgansamueldmq: 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
notmorganstevemar: , not samueldmq20:18
stevemaryou and mordred are tackling all the projects20:18
mordredyah20:18
notmorganstevemar: but trying to figure out how to compare endpoint and token properly is giving me a headache20:18
notmorganstevemar: yah, after nova gonna hit cinder and glance20:19
stevemarnotmorgan: clients too?20:19
notmorganyah mordred is working on that20:19
stevemaryou cats are crazy20:19
mordredI've got clients on my list20:19
notmorganhe is going OCC things20:19
*** e0ne has joined #openstack-keystone20:19
*** e0ne has quit IRC20:19
mordredstevemar: cross project FTW baby20:19
notmorganmordred: ++20:19
*** e0ne has joined #openstack-keystone20:19
notmorganand sdague is helping to tackle the glance-uses-catalog stuff in nova20:19
stevemari saw ++20:20
notmorganif all goes well we'll have a large chunk of this done in a couple weeks20:20
*** e0ne has quit IRC20:20
notmorganand i need to run an idea by jamielennox too.20:20
notmorganstevemar: we might need another KSA release soon.20:21
notmorganstevemar: just as a heads up20:22
stevemarnotmorgan: coolio20:22
notmorgan*might*20:22
*** petertr7 is now known as petertr7_away20:22
*** EinstCrazy has joined #openstack-keystone20:22
*** EinstCrazy has quit IRC20:27
*** petertr7_away is now known as petertr720:29
dolphmlbragstad: 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 checked20:30
lbragstaddolphm creating one now20:30
*** aginwala has quit IRC20:33
*** henrynash has joined #openstack-keystone20:34
*** ChanServ sets mode: +v henrynash20:34
lbragstaddolphm clayton mfisch https://bugs.launchpad.net/keystone/+bug/152366420:34
openstackLaunchpad bug 1523664 in OpenStack Identity (keystone) "Unable to get token when fernet key repository isn't writeable" [Undecided,New]20:34
*** jaosorior has quit IRC20:36
*** jaosorior has joined #openstack-keystone20:37
*** jasonsb has joined #openstack-keystone20:37
*** timcline has quit IRC20:39
*** timcline has joined #openstack-keystone20:40
*** aginwala has joined #openstack-keystone20:41
*** jaosorior has quit IRC20:41
notmorganstevemar: 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-keystone20:43
*** ninag has joined #openstack-keystone20:45
*** ninag has quit IRC20:45
*** jaosorior has quit IRC20:45
*** ninag has joined #openstack-keystone20:45
*** diazjf has quit IRC20:46
openstackgerritGrzegorz Grasza (xek) proposed openstack/keystone-specs: Online schema migration  https://review.openstack.org/24518620:50
xeklbragstad, bknudson, dstanek ^20:52
xekgood night20:52
bknudsonsleep tight, xek20:53
*** rderose has joined #openstack-keystone20:54
*** mhickey has joined #openstack-keystone20:54
stevemarxek: thanks for the multiple iterations20:55
stevemarayoung: there are some comments in https://review.openstack.org/#/c/240719/ that should be addressed for internal clean up20:56
stevemarcc samueldmq ^ if you're looking for more things to do :P20:56
*** aginwala has quit IRC20:57
ayoungstevemar, "does this have an impact on fernet tokens?"  Yes.. all token formats20:58
samueldmqstevemar: what ? doing!20:59
*** miyagishi_t has joined #openstack-keystone20:59
ayoungsamueldmq, stevemar is asking you to clean up my messes21:00
* ayoung working on implied roles21:00
samueldmqayoung: that's okay :)21:01
davechen1stevemar,  ayoung, samueldmq: all your comments make sense, but this one is intentional iirc -  "self.assertTrue(token['is_admin_project'])"21:01
davechen1and it was per the request from the early review, just not inclue this one, samueldmq :)21:02
samueldmqdavechen1: okay, I got it, is that to assert that its type is boolean right ?21:04
*** davechen has joined #openstack-keystone21:04
stevemardavechen1: what's the point of keeping that assertion in that form?21:04
davechenstevemar: explicitly assert that the value is bool.21:04
stevemardavechen1: hmm, assertTrue doesn't do that?21:05
stevemarlemme see21:05
ayoungdavechen, 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
openstackgerritSean Perry proposed openstack/keystone: Use assertDictEqual instead of assertEqualPolicies  https://review.openstack.org/25148221:05
stevemardavechen1: meh, i guess21:06
stevemarNote that this is equivalent to bool(expr) is True21:06
stevemarhttps://docs.python.org/2/library/unittest.html21:06
bknudsonit does bool() which is different21:06
*** davechen1 has quit IRC21:06
davechenayoung: so, it should raise exeption?21:06
stevemarsomeone will eventually come in with a clean up "switch all assertEqual(True, X) with assertTrue" in 6 months and we'll merge that21:06
*** jasonsb has quit IRC21:07
davechenayoung: but it's not the role not found exception I think.21:07
ayoungdavechen, heh  .  it *should*21:07
bknudsonhopefully reviewers wouldn't accept that21:07
ayoungdavechen, nah, I need to translate it to that21:07
stevemarbknudson: maybe if there's a comment in the code to indicate otherwise ;)21:07
davechenayoung: cool, that will be more clearly.21:07
ayoungits going to be some SQL exception...I was thinkg the @sql.handle_)conflicts ould cover it, but its the wrong exception21:07
stevemarsamueldmq: or davechen: can you add a comment to the assertion? saying we want to explicitly test for booleans21:07
samueldmqstevemar: done21:08
*** pauloewerton has quit IRC21:08
*** harlowja has quit IRC21:08
davechenstevmar, bknudson: breton point hit me for the patch I bandoned, i have a good memory on that, right? :)21:08
*** harlowja has joined #openstack-keystone21:08
ayoungdavechen, class DBConstraintError(DBError):  I think: https://github.com/openstack/oslo.db/blob/master/oslo_db/exception.py#L9021:08
davechenayoung: agreed, transilate it anyway.21:09
ayoungDBReferenceError21:10
ayoungdavechen, I plan on it...21:10
ayounghttps://github.com/openstack/oslo.db/blob/master/oslo_db/exception.py#L107  davechen I think it is this one, actually21:10
davechenstevemar: i am not helpful for the cleanup, buried in the classes. :(21:10
*** jasonsb has joined #openstack-keystone21:11
davechenayoung: but it's from oslo, we need the exception that more understandable.21:11
ayoungdavechen, yeah...I was actually just being lazy and figured you knew this off the top of your head, but I did the research now21:12
*** petertr7 is now known as petertr7_away21:14
*** petertr7_away is now known as petertr721:16
davechenstevemar: check this out - https://review.openstack.org/#/c/162570/2/keystone/tests/unit/test_backend.py, this is why assertls is better.21:17
davechenand acutally, the patch that was merged is not fully correct though.21:17
davechenwe need revert the change from this one - https://review.openstack.org/#/c/240762/21:18
*** bradjones has quit IRC21:20
*** bradjones has joined #openstack-keystone21:22
*** bradjones has quit IRC21:22
*** bradjones has joined #openstack-keystone21:22
openstackgerritBrad Topol proposed openstack/keystone: Deprecate ldap Role  https://review.openstack.org/25266921:24
*** mhickey has quit IRC21:26
*** aginwala has joined #openstack-keystone21:26
*** mhickey has joined #openstack-keystone21:27
*** mhickey has quit IRC21:28
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Cleans up code for `is_admin` in tokens  https://review.openstack.org/25439121:30
*** rderose has quit IRC21:30
samueldmqstevemar: ayoung: davechen: ^^21:30
jamielennoxnotmorgan: i'm here for like 10 minutes, then i'll be back in an hour or so21:31
notmorganjamielennox: no worries i think i've solved it21:32
notmorganjamielennox: but sec..21:32
*** mhickey has joined #openstack-keystone21:33
bknudsonI tried running keystone with uwsgi and got an error21:34
bknudsonhttp://paste.openstack.org/show/481085/21:35
*** alejandrito has joined #openstack-keystone21:36
bknudsonmaybe I need to add SCRIPT_NAME to /etc/nginx/uwsgi_params21:36
bknudsonhttp://uwsgi-docs.readthedocs.org/en/latest/Nginx.html#hosting-multiple-apps-in-the-same-process-aka-managing-script-name-and-path-info21:38
*** jasonsb has quit IRC21:39
*** jasonsb has joined #openstack-keystone21:40
*** aginwala has quit IRC21:40
claytonbknudson I'm running it under uwsgi, but without nginx, with uwsgi in http mode21:40
bknudsonclayton: that's too easy21:41
claytonyou can play on hard if you prefer :)21:41
notmorganbknudson: i've run keystone under uwsgi w/ the uwsgi-socket21:41
notmorganbknudson: what error?21:41
bknudsonnotmorgan: there's no SCRIPT_NAME defined21:41
bknudsonSo now I'm looking in uwsgi_params to see if I can set it to something21:42
* notmorgan might have tacked something in to fix that21:42
bknudsonI don't know why uwsgi is so much better than http21:43
*** rderose has joined #openstack-keystone21:44
dstanekbknudson: that's in the uwsgi docs - i've had to do that in the past21:48
dstanekbknudson: you have issues i can dig out what i had to do21:49
dstanekbknudson: the benefit to uwsgi is that you don't need apache. if you want apache the mod_wsgi is probably the way to go21:50
bknudsonwhy is the uwsgi protocol better than http? I can run python uwsgi with --http or --socket21:51
claytonbknudson: some people seem to be nervous about exposing uwsgi directly21:51
bknudsonyou don't expose it directly, you use http proxy21:51
bknudsonI can do http proxy or I can do uwsgi proxy21:51
claytonah, I see what you're saying21:52
claytonthe uwsgi people say it's faster.  I doubt it matters for keystone21:52
bknudsonkeystone has much bigger performance problems21:52
claytonthat was my take yes21:52
claytonwe're running it in http mode behind haproxy in http mode21:52
claytonor will be at last21:53
claytons/last/least/21:53
bknudsonhttps://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
bknudsonI don't believe it, but whatever21:54
dstanekbknudson: clayton: yes, faster, but more for things that have the C10K type problems21:55
bknudsonif http is so bad then improve http, don't go making a whole new protocol21:56
bknudsondstanek: I still haven't figured out what to set script_name to.21:56
dstanekbknudson: in our case you can probably get away with setting it to the same value as path_info21:59
bknudsonmaybe I should make it easier on myself and use :5000 and :35357 rather than /identity and /identity_admin.22:00
claytonthat seems pretty reasonable.22:00
dstanekbknudson: in one config i am using this 'fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;'22:01
*** rderose has quit IRC22:01
dstanekwill you be satisfied taking the easy way out?22:02
*** gildub has joined #openstack-keystone22:02
bknudsonI'm never satisfied doing things the easy way22:02
bknudsonthe uwsgi server keeps saying it's doing "GET /identity" but I need nginx to turn GET /identity to GET /22:03
*** ninag has quit IRC22:04
*** davechen1 has joined #openstack-keystone22:05
*** davechen has quit IRC22:06
*** aginwala has joined #openstack-keystone22:08
*** henrynash has quit IRC22:11
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Cleans up code for `is_admin` in tokens  https://review.openstack.org/25439122:12
samueldmqlhcheng: ^22:12
*** aginwala has quit IRC22:15
*** e0ne has joined #openstack-keystone22:15
*** mhickey has quit IRC22:18
*** aginwala has joined #openstack-keystone22:21
*** davechen1 has left #openstack-keystone22:23
*** petertr7 is now known as petertr7_away22:23
samueldmqstevemar: responded inline to your comment in the cleanup change22:25
bknudsonI 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
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Cleans up code for `is_admin` in tokens  https://review.openstack.org/25439122:30
*** aginwala has quit IRC22:34
*** topol has quit IRC22:40
*** davechen has joined #openstack-keystone22:40
kfox1111if I have a self signed cert on a K2K idp, how do I load that into shib on the SP?22:44
openstackgerritLance Bragstad proposed openstack/keystone: Add checks for domain scoped data creep  https://review.openstack.org/25367122:51
openstackgerritLance Bragstad proposed openstack/keystone: Add checks for project scoped data creep to tests  https://review.openstack.org/25367022:51
openstackgerritLance Bragstad proposed openstack/keystone: Reuse project scoped token check for trusts  https://review.openstack.org/25367222:56
*** aginwala has joined #openstack-keystone22:58
*** gildub has quit IRC22:58
*** gyee has joined #openstack-keystone23:01
*** ChanServ sets mode: +v gyee23:01
*** lhcheng_ has joined #openstack-keystone23:01
*** timcline has quit IRC23:04
*** lhcheng has quit IRC23:04
*** e0ne has quit IRC23:04
stevemarbknudson: looks like we need to doc it :P23:05
*** spotz is now known as spotz_zzz23:06
openstackgerritPriti Desai proposed openstack/keystone: Adding role assignment lists unit tests  https://review.openstack.org/25443623:10
openstackgerritayoung proposed openstack/keystone: Implied Roles  https://review.openstack.org/24261423:17
openstackgerritayoung proposed openstack/keystone: Create V9 Role Driver  https://review.openstack.org/24780523:17
openstackgerritayoung proposed openstack/keystone: Create new version of assignment driver interface  https://review.openstack.org/24285323:17
ayoungGAH what part of "NO REBASE"23:17
ayoungfucking hell23:17
*** jamielennox is now known as jamielennox|away23:18
openstackgerritayoung proposed openstack/keystone: Create new version of assignment driver interface  https://review.openstack.org/24285323:22
*** davechen has left #openstack-keystone23:22
*** boris-42_ has quit IRC23:23
*** pumaranikar has quit IRC23:23
openstackgerritayoung proposed openstack/keystone: Use list_role_assignments to get projects/domains for user  https://review.openstack.org/24251323:23
openstackgerritayoung proposed openstack/keystone: Create V9 Role Driver  https://review.openstack.org/24780523:25
ayoungWTF is with --no-rebase being ignored!23:25
*** slberger has left #openstack-keystone23:25
openstackgerritJorge Munoz proposed openstack/keystone: Reduce revoke events for disabled domains and projects.  https://review.openstack.org/25327323:27
*** alex_xu has quit IRC23:29
*** alex_xu has joined #openstack-keystone23:31
*** lhcheng_ has quit IRC23:34
openstackgerritayoung proposed openstack/keystone: Implied Roles  https://review.openstack.org/24261423:34
ayoungwhew23:34
*** aginwala has quit IRC23:40
openstackgerritJorge Munoz proposed openstack/keystone: Reduce revoke events for disabled domains and projects.  https://review.openstack.org/25327323:41
*** aginwala has joined #openstack-keystone23:41
*** tonytan_brb has joined #openstack-keystone23:51
*** boris-42_ has joined #openstack-keystone23:53
*** tonytan_brb has quit IRC23:54
*** tonytan4ever has quit IRC23:55
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/25444423:57
*** sigmavirus24 is now known as sigmavirus24_awa23:57
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/25444523:57

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