*** e0ne_ has quit IRC | 00:00 | |
notmorgan | jamielennox: let me know when/if you want to talk betamax more | 00:01 |
---|---|---|
*** lhcheng has quit IRC | 00:03 | |
*** richm has quit IRC | 00:08 | |
*** tsymanczyk has joined #openstack-keystone | 00:09 | |
*** tsymanczyk is now known as Guest48317 | 00:09 | |
shaleh | notmorgan: crickey!! I just followed that canon lens link. They are ripping you off when they fail to include the pack mule for that price. | 00:12 |
notmorgan | shaleh: hah, it's quite the lens. i mean... estimation is 20-100 in existence (closer to 20) | 00:13 |
shaleh | notmorgan: at 2 a year for 12 years, yeah 20 is close to accurate | 00:14 |
shaleh | the f5.6 is a little disappointing | 00:15 |
shaleh | Lease for as low as $6,102 / month | 00:15 |
*** jerrygb has joined #openstack-keystone | 00:16 | |
*** EinstCrazy has joined #openstack-keystone | 00:16 | |
*** btully has quit IRC | 00:17 | |
*** EinstCrazy has quit IRC | 00:17 | |
*** EinstCrazy has joined #openstack-keystone | 00:18 | |
*** EinstCrazy has quit IRC | 00:22 | |
*** btully has joined #openstack-keystone | 00:24 | |
*** _zouyee has joined #openstack-keystone | 00:30 | |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/251639 | 00:35 |
jamielennox | lol - it's $600 just for the lens cap for that puppy | 00:36 |
*** roxanagh_ has joined #openstack-keystone | 00:37 | |
*** btully has quit IRC | 00:38 | |
gyee | helluva deal! :) | 00:40 |
*** roxanagh_ has quit IRC | 00:41 | |
*** markvoelker has quit IRC | 00:45 | |
jamielennox | notmorgan: i sent sigmavirus a message in -dev to have a look, ideally we could use betamax like requests-mock and mock out the entire requests adapter layer | 00:49 |
notmorgan | jamielennox: ++ | 00:50 |
notmorgan | jamielennox: i like it | 00:50 |
*** btully has joined #openstack-keystone | 00:51 | |
jamielennox | notmorgan: doesn't seem to be a public api today so if we have to support it in session i'm ok with that | 00:52 |
notmorgan | jamielennox: i think we will need to. | 00:54 |
*** shaleh has quit IRC | 00:54 | |
*** ctina_ has joined #openstack-keystone | 00:55 | |
*** ctina_ has quit IRC | 01:00 | |
*** EinstCrazy has joined #openstack-keystone | 01:01 | |
*** alex_xu has quit IRC | 01:09 | |
*** alex_xu has joined #openstack-keystone | 01:12 | |
*** topol has joined #openstack-keystone | 01:15 | |
*** ChanServ sets mode: +v topol | 01:15 | |
*** btully has quit IRC | 01:17 | |
*** topol has quit IRC | 01:20 | |
*** jasonsb has quit IRC | 01:23 | |
*** btully has joined #openstack-keystone | 01:23 | |
*** Guest48317 is now known as tsymanczyk | 01:26 | |
*** yangweiwei has joined #openstack-keystone | 01:30 | |
*** aginwala has quit IRC | 01:31 | |
*** topol has joined #openstack-keystone | 01:34 | |
*** ChanServ sets mode: +v topol | 01:34 | |
*** topol_ has joined #openstack-keystone | 01:35 | |
*** ChanServ sets mode: +v topol_ | 01:35 | |
*** btully has quit IRC | 01:37 | |
*** aginwala has joined #openstack-keystone | 01:37 | |
notmorgan | jamielennox: i was thinking maybe we should be looking to move KSA to be a traditional mount of the requests session object instead of a wrapper [with exception of the basic helper functions] | 01:38 |
notmorgan | jamielennox: might have been a convo i was having w/ mordred at somepoint. | 01:38 |
*** topol has quit IRC | 01:38 | |
jamielennox | notmorgan: i'm not following | 01:38 |
jamielennox | like make it an adapter? | 01:38 |
notmorgan | jamielennox:yeah a traditional requests adapter | 01:39 |
*** btully has joined #openstack-keystone | 01:39 | |
notmorgan | unless we were already doing that. but i think we weren't. | 01:39 |
jamielennox | notmorgan: no we're not doing that | 01:39 |
jamielennox | notmorgan: we could do some of it as an adapter, but i don't think we can do everything that way | 01:39 |
notmorgan | not everything | 01:40 |
*** topol_ has quit IRC | 01:40 | |
notmorgan | but we can move things that way | 01:40 |
jamielennox | so we would still need something that wraps session | 01:40 |
notmorgan | yeah, we would still need the helper... actually | 01:40 |
notmorgan | wait | 01:40 |
notmorgan | what if we created an adapter and instead of acting on the session we acted on the Auth object (mounted) into the session | 01:41 |
notmorgan | so instead of asking session.get_catalog, it's session.mount(adapter), and adapter.get_catalog? | 01:41 |
jamielennox | so there's a problem i've been thinking of but have never seen anyone have | 01:41 |
*** RA has joined #openstack-keystone | 01:42 | |
*** RA is now known as Guest79212 | 01:42 | |
jamielennox | because sessions and auths aren't strictly tied (you can share an auth between sessions) if it ever needed to reauthenticate it would use whatever session it was being used with at the time | 01:42 |
jamielennox | if this auth was in some way based on a SSL or other session setup that would fail | 01:43 |
notmorgan | yeh | 01:43 |
jamielennox | this is a problem for example if we are passing the user auth object down from auth_token middleware | 01:43 |
jamielennox | we would want to do reauth of the service user via the session defined in auth_token middleware not whatever the service defined | 01:44 |
jamielennox | so i've thought of how i would redesign this if i were to do it again | 01:44 |
notmorgan | so part of what we discussing earlier would eliminate that reauth | 01:44 |
jamielennox | and i think session is really a connection because it shouldn't be storing cookies | 01:44 |
jamielennox | or doing anything other than connection pooling | 01:45 |
notmorgan | because there shouldn't really need to be a reauth at the service level | 01:45 |
notmorgan | it was already authorized | 01:45 |
jamielennox | sure, but that's a bigger problem | 01:47 |
jamielennox | but so if i was doing it again it would be a connection object, wrapped with an auth object that you made requests through | 01:48 |
jamielennox | and the interfaces would be the same so clients wouldn't care if it was authed or not | 01:48 |
notmorgan | i think that was the premise behind the adapter | 01:48 |
jamielennox | but given the effort we've put into getting people onto this system i don't know if that's worth it | 01:48 |
jamielennox | there's a lot of stuff you loose at the adapter level | 01:49 |
notmorgan | sure. but for most of what we need it's there | 01:49 |
notmorgan | it's the helper functions that we lose | 01:49 |
notmorgan | and honestly, those are things we can work around | 01:49 |
*** jerrygb has quit IRC | 01:50 | |
jamielennox | well a big one we lose is redirects but we don't do that anyway | 01:50 |
notmorgan | since we don't do it ;) | 01:50 |
jamielennox | but a lot of the like get_endpoint stuff has to happen above that layer | 01:51 |
*** lhcheng has joined #openstack-keystone | 01:51 | |
*** ChanServ sets mode: +v lhcheng | 01:51 | |
notmorgan | anyway this can be shelved | 01:51 |
notmorgan | i think we need to focus on the stuff we were talking about earlier | 01:51 |
notmorgan | i think it's a massive improvement over what we have today [even just as a POC] | 01:52 |
jamielennox | yea, there's some stuff there we might be able to do, but i'm just not sure the wins are enough now | 01:52 |
notmorgan | i think the wins are there. mostly because we can drive the conversation in a good way | 01:53 |
jamielennox | we still haven't finished gettting people on board with the current design, we would need a really compelling reason to uproot that all for something new | 01:53 |
notmorgan | i see this as a preview to where we are headed | 01:53 |
notmorgan | the current design is a stepping stone, once everything is solidly on it, it'll be easier to make these kinds of adjustments | 01:54 |
notmorgan | esp. if KSM is handing down the auth to the services in a way they can consume.. then we just make KSM hand down a different KSA auth | 01:54 |
notmorgan | that is smart enough to do things the new way. but i think showing it can all work and the benefits (even if under the hood it's a bit ugly) will help drive the support we need to make it all happen | 01:55 |
*** jerrygb has joined #openstack-keystone | 01:55 | |
* notmorgan is going to continue working on the POC in either case. | 01:55 | |
jamielennox | the POC can be done with the current, but i hadn't considered doing ksa as an adapter | 01:55 |
jamielennox | it would simplify some stuff | 01:56 |
*** lhcheng has quit IRC | 01:56 | |
notmorgan | :) | 01:56 |
jamielennox | like how i was saying i don't want to use requests at all, adapter is beneath that point | 01:56 |
notmorgan | anyway... | 01:56 |
* notmorgan shrugs. | 01:57 | |
jamielennox | we could handle all the connection management stuff we need there, and if people want to use a requests.Session on top of that for cookie management they could do what they like | 01:57 |
*** btully has quit IRC | 01:57 | |
jamielennox | not something we can/should try and solve now | 01:57 |
notmorgan | def. | 01:57 |
stevemar | GDI, new pycadf broke keystone :( | 01:58 |
notmorgan | stevemar: hey, i said it was gonna break things! | 01:58 |
notmorgan | didn't i? | 01:59 |
stevemar | notmorgan: you did | 01:59 |
*** doug-fish has quit IRC | 01:59 | |
*** topol has joined #openstack-keystone | 01:59 | |
*** ChanServ sets mode: +v topol | 01:59 | |
*** doug-fish has joined #openstack-keystone | 01:59 | |
*** doug-fish has quit IRC | 01:59 | |
*** doug-fish has joined #openstack-keystone | 02:00 | |
*** topol has quit IRC | 02:04 | |
*** ctracey has quit IRC | 02:05 | |
*** ctracey has joined #openstack-keystone | 02:06 | |
stevemar | notmorgan: looks like its just cause the context we send over is bs | 02:08 |
ayoung | jamielennox, I know you are not really thinking about RDO anymore, but https://github.com/jistr/inlunch | 02:09 |
jamielennox | ayoung: what's instack? | 02:10 |
*** ctracey has left #openstack-keystone | 02:10 | |
jamielennox | ayoung: i was talking to cloudnull earlier and they are working on splitting out the ansible roles, given everything you should look at getting someone working on that | 02:12 |
jamielennox | the roles from openstack-ansible | 02:12 |
ayoung | jamielennox, heh,,,, | 02:13 |
jamielennox | they're very ubuntu focused | 02:13 |
ayoung | jamielennox, I still don't have a working manager deploy | 02:13 |
*** omkarjoshi has left #openstack-keystone | 02:13 | |
jamielennox | but they're already way more complete than the puppet scripts | 02:13 |
ayoung | instack is a way to set it up | 02:13 |
jamielennox | (at least for keystone) | 02:14 |
ayoung | sounds good. BUt, you know, inertia | 02:14 |
ayoung | I have a new Dell T1700 that is, in theory, powerful enough to run three big VMs undercloud, controller, compute... | 02:15 |
ayoung | and, wel;l...trying to find the right magik incantation to get it to install | 02:15 |
ayoung | and now I can't talk to repo.fedorapeople.org | 02:19 |
ayoung | gah...layers upon layers...its turtles all the way down | 02:19 |
*** fangxu has quit IRC | 02:30 | |
*** david-lyle has joined #openstack-keystone | 02:31 | |
*** doug-fish has quit IRC | 02:34 | |
*** doug-fish has joined #openstack-keystone | 02:34 | |
*** aginwala has quit IRC | 02:35 | |
*** topol has joined #openstack-keystone | 02:36 | |
*** ChanServ sets mode: +v topol | 02:36 | |
*** roxanagh_ has joined #openstack-keystone | 02:38 | |
*** doug-fish has quit IRC | 02:39 | |
*** aginwala has joined #openstack-keystone | 02:40 | |
*** topol has quit IRC | 02:41 | |
*** roxanagh_ has quit IRC | 02:44 | |
*** jasonsb has joined #openstack-keystone | 02:51 | |
bknudson | looks like keystone unit tests are busted. | 02:54 |
bknudson | I won't have time to look at it today... will look tomorrow. | 02:55 |
yangweiwei | The policy.json is common to each project, but if the project has its own policy rules, Can we? | 02:58 |
*** david-lyle has quit IRC | 03:00 | |
*** Guest79212 has quit IRC | 03:06 | |
*** topol has joined #openstack-keystone | 03:13 | |
*** ChanServ sets mode: +v topol | 03:13 | |
*** gyee has quit IRC | 03:16 | |
*** aginwala has quit IRC | 03:17 | |
*** topol has quit IRC | 03:18 | |
*** aginwala has joined #openstack-keystone | 03:20 | |
*** btully has joined #openstack-keystone | 03:25 | |
*** dims has quit IRC | 03:26 | |
stevemar | bknudson: it's cause of the new pycadf release | 03:30 |
stevemar | it now has more strict validation on "id" fields | 03:30 |
stevemar | which, in some tests, we were setting the user_id as the id, but in cause we test with a silly empty context, the user_id that we get was `None` | 03:32 |
stevemar | which is not a valid ID as far as pycadf is concerned | 03:32 |
*** jerrygb has quit IRC | 03:34 | |
*** jerrygb has joined #openstack-keystone | 03:34 | |
*** spandhe has quit IRC | 03:36 | |
*** jerrygb has quit IRC | 03:39 | |
*** roxanagh_ has joined #openstack-keystone | 03:40 | |
*** links has joined #openstack-keystone | 03:43 | |
*** aginwala has quit IRC | 03:44 | |
*** roxanagh_ has quit IRC | 03:44 | |
openstackgerrit | Shu Muto proposed openstack/python-keystoneclient: Delete python bytecode before every test run https://review.openstack.org/252169 | 03:53 |
*** topol has joined #openstack-keystone | 04:03 | |
*** ChanServ sets mode: +v topol | 04:03 | |
openstackgerrit | Steve Martinelli proposed openstack/pycadf: Revert "make generate_uuid return valid uuid" https://review.openstack.org/252175 | 04:06 |
*** topol has quit IRC | 04:08 | |
stevemar | bknudson: looked at the bug: https://bugs.launchpad.net/pycadf/+bug/1521844 | 04:14 |
openstack | Launchpad bug 1521844 in OpenStack Identity (keystone) "pycadf ID validation fails for multi-domain IDs" [Critical,Triaged] | 04:14 |
stevemar | notmorgan: dolphm others, if you're around, i could use some creative ideas :\ | 04:14 |
*** miyagishi_t has joined #openstack-keystone | 04:22 | |
jamielennox | stevemar: not much else we can do there, it's valid for keystone to return non-uuid user_ids | 04:30 |
*** jbell8 has joined #openstack-keystone | 04:31 | |
stevemar | i have sort of a solution | 04:32 |
*** david-lyle has joined #openstack-keystone | 04:44 | |
openstackgerrit | Steve Martinelli proposed openstack/keystone: Ensure pycadf initiator IDs are UUID https://review.openstack.org/252182 | 04:46 |
openstackgerrit | Steve Martinelli proposed openstack/pycadf: Revert "make generate_uuid return valid uuid" https://review.openstack.org/252175 | 04:46 |
stevemar | jamielennox: https://review.openstack.org/#/c/252182/ is my weak ass attempt at fixing it | 04:47 |
*** fawadkhaliq has joined #openstack-keystone | 04:48 | |
openstackgerrit | gordon chung proposed openstack/pycadf: relax id validation https://review.openstack.org/252183 | 04:48 |
stevemar | apparnently gordon also proposed a change | 04:50 |
*** aginwala has joined #openstack-keystone | 04:51 | |
*** topol has joined #openstack-keystone | 04:52 | |
*** ChanServ sets mode: +v topol | 04:52 | |
*** aginwala has quit IRC | 04:56 | |
*** topol has quit IRC | 04:57 | |
*** aginwala has joined #openstack-keystone | 04:59 | |
*** darrenc is now known as darrenc_afk | 05:10 | |
*** markvoelker has joined #openstack-keystone | 05:24 | |
*** fangxu has joined #openstack-keystone | 05:28 | |
*** aginwala has quit IRC | 05:29 | |
*** topol has joined #openstack-keystone | 05:29 | |
*** ChanServ sets mode: +v topol | 05:29 | |
*** darrenc_afk is now known as darrenc | 05:32 | |
*** topol has quit IRC | 05:33 | |
*** markvoelker has quit IRC | 05:41 | |
*** roxanagh_ has joined #openstack-keystone | 05:41 | |
*** links has quit IRC | 05:43 | |
*** btully has quit IRC | 05:46 | |
*** roxanagh_ has quit IRC | 05:47 | |
*** rcernin has joined #openstack-keystone | 05:52 | |
*** links has joined #openstack-keystone | 05:54 | |
*** btully has joined #openstack-keystone | 06:05 | |
*** topol has joined #openstack-keystone | 06:06 | |
*** ChanServ sets mode: +v topol | 06:06 | |
*** topol has quit IRC | 06:10 | |
*** gildub has quit IRC | 06:13 | |
*** harlowja has quit IRC | 06:16 | |
*** aginwala_ has joined #openstack-keystone | 06:18 | |
*** rcernin has quit IRC | 06:25 | |
*** topol has joined #openstack-keystone | 06:42 | |
*** ChanServ sets mode: +v topol | 06:42 | |
*** roxanagh_ has joined #openstack-keystone | 06:43 | |
*** spandhe has joined #openstack-keystone | 06:44 | |
*** spandhe has quit IRC | 06:46 | |
*** spandhe has joined #openstack-keystone | 06:47 | |
*** topol has quit IRC | 06:47 | |
*** roxanagh_ has quit IRC | 06:48 | |
*** aginwala_ has quit IRC | 06:49 | |
*** shaleh has joined #openstack-keystone | 06:50 | |
*** shaleh has quit IRC | 06:55 | |
*** spandhe_ has joined #openstack-keystone | 07:06 | |
*** spandhe has quit IRC | 07:08 | |
*** spandhe_ is now known as spandhe | 07:08 | |
*** rcernin has joined #openstack-keystone | 07:09 | |
*** woodster_ has quit IRC | 07:09 | |
*** akscram has quit IRC | 07:11 | |
*** akscram has joined #openstack-keystone | 07:13 | |
*** topol has joined #openstack-keystone | 07:19 | |
*** ChanServ sets mode: +v topol | 07:19 | |
*** jerrygb has joined #openstack-keystone | 07:21 | |
*** topol has quit IRC | 07:24 | |
*** jerrygb has quit IRC | 07:25 | |
*** aginwala has joined #openstack-keystone | 07:37 | |
*** Nirupama has joined #openstack-keystone | 07:37 | |
*** roxanagh_ has joined #openstack-keystone | 07:44 | |
*** topol has joined #openstack-keystone | 07:44 | |
*** ChanServ sets mode: +v topol | 07:44 | |
*** spandhe has quit IRC | 07:46 | |
*** topol has quit IRC | 07:49 | |
*** roxanagh_ has quit IRC | 07:49 | |
*** jaosorior has joined #openstack-keystone | 07:50 | |
*** topol has joined #openstack-keystone | 08:09 | |
*** ChanServ sets mode: +v topol | 08:09 | |
*** aginwala has quit IRC | 08:10 | |
*** aginwala has joined #openstack-keystone | 08:10 | |
*** topol has quit IRC | 08:13 | |
odyssey4me | ayoung FYI - OpenStack-Ansible is looking for contributors to assist implementing Fedora/etc support: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079732.html | 08:28 |
odyssey4me | cc jamielennox | 08:28 |
jamielennox | odyssey4me: less up my alley these days, however given redhat owns ansible that would definetly be something ayoung should take a look at/delegate | 08:29 |
*** fawadkhaliq has quit IRC | 08:30 | |
odyssey4me | that would be most useful - we need someone to lead the charge from a work management standpoint - we have several volunteers signed up, but no-one to lead the work yet | 08:32 |
odyssey4me | we're happy to help with orientation and such | 08:32 |
*** btully has quit IRC | 08:35 | |
*** fhubik has joined #openstack-keystone | 08:35 | |
*** aginwala has quit IRC | 08:40 | |
*** roxanagh_ has joined #openstack-keystone | 08:46 | |
*** fawadkhaliq has joined #openstack-keystone | 08:49 | |
*** roxanagh_ has quit IRC | 08:52 | |
*** btully has joined #openstack-keystone | 08:52 | |
*** lhcheng has joined #openstack-keystone | 08:54 | |
*** ChanServ sets mode: +v lhcheng | 08:54 | |
*** fangxu has quit IRC | 09:00 | |
*** btully has quit IRC | 09:06 | |
*** gus has quit IRC | 09:07 | |
*** gus has joined #openstack-keystone | 09:09 | |
*** topol has joined #openstack-keystone | 09:10 | |
*** ChanServ sets mode: +v topol | 09:10 | |
*** fhubik is now known as fhubik_brb | 09:14 | |
*** topol has quit IRC | 09:15 | |
*** yangweiwei has quit IRC | 09:15 | |
*** raginbajin has joined #openstack-keystone | 09:17 | |
*** aix has joined #openstack-keystone | 09:21 | |
*** tyagiprince has joined #openstack-keystone | 09:21 | |
tyagiprince | Hey people.. I am having problem in fetching users from active directory.. when I run the openstack user list command, it takes around 15 to 20 seconds to list the users.. whereas when I open the Users tab inside the identity panel, it takes around a minute or two.. | 09:22 |
tyagiprince | So What step should I take? I am thinking about changing the horizon code and fetch only the first 100 users and then on filtering the results through horizon, the user list should update itself in horizon and still show me the best 100 results matching the criteria.. | 09:23 |
*** mhickey has joined #openstack-keystone | 09:24 | |
*** fhubik_brb is now known as fhubik | 09:29 | |
*** henrynash has quit IRC | 09:31 | |
*** jbell8 has quit IRC | 09:34 | |
*** jbell8 has joined #openstack-keystone | 09:35 | |
*** henrynash has joined #openstack-keystone | 09:35 | |
*** ChanServ sets mode: +v henrynash | 09:35 | |
*** henrynash has quit IRC | 09:35 | |
*** hogepodge has quit IRC | 09:38 | |
*** jbell8 has quit IRC | 09:39 | |
*** hogepodge has joined #openstack-keystone | 09:41 | |
*** tomoiaga has joined #openstack-keystone | 09:41 | |
tomoiaga | I've been looking through the code but I can't find a way to delete project extra attributes. Is that possible ? Thank you! | 09:42 |
*** henrynash has joined #openstack-keystone | 09:43 | |
*** ChanServ sets mode: +v henrynash | 09:43 | |
*** henrynash has quit IRC | 09:44 | |
*** roxanagh_ has joined #openstack-keystone | 09:48 | |
*** jistr has joined #openstack-keystone | 09:50 | |
*** roxanagh_ has quit IRC | 09:53 | |
*** topol has joined #openstack-keystone | 10:00 | |
*** ChanServ sets mode: +v topol | 10:00 | |
*** e0ne has joined #openstack-keystone | 10:03 | |
*** topol has quit IRC | 10:04 | |
*** fhubik is now known as fhubik_brb | 10:06 | |
*** e0ne has quit IRC | 10:06 | |
*** e0ne_ has joined #openstack-keystone | 10:07 | |
*** e0ne_ has quit IRC | 10:09 | |
*** e0ne has joined #openstack-keystone | 10:09 | |
*** e0ne_ has joined #openstack-keystone | 10:14 | |
*** e0ne has quit IRC | 10:16 | |
*** fhubik_brb is now known as fhubik | 10:22 | |
*** lxsli has joined #openstack-keystone | 10:30 | |
lxsli | Good morning | 10:30 |
*** e0ne_ has quit IRC | 10:30 | |
lxsli | Can anyone give me any background on the transition from /v2/ endpoints to /v2.0/ please? | 10:30 |
*** Nirupama has quit IRC | 10:34 | |
*** fhubik is now known as fhubik_brb | 10:35 | |
samueldmq | lxsli: hi, I've never heard about /v2/ | 10:36 |
lxsli | samueldmq: huh, ok! thanks | 10:37 |
samueldmq | lxsli: v3 was the newest API when I arrived here , and I've only seen conversations using /v3/ or /v2.0/ | 10:37 |
*** weihan has joined #openstack-keystone | 10:39 | |
*** btully has joined #openstack-keystone | 10:41 | |
*** btully has quit IRC | 10:45 | |
*** roxanagh_ has joined #openstack-keystone | 10:50 | |
*** roxanagh_ has quit IRC | 10:54 | |
*** lhcheng_ has joined #openstack-keystone | 11:02 | |
*** lhcheng has quit IRC | 11:03 | |
*** lhcheng has joined #openstack-keystone | 11:04 | |
*** ChanServ sets mode: +v lhcheng | 11:04 | |
*** lhcheng_ has quit IRC | 11:04 | |
*** fhubik_brb is now known as fhubik | 11:12 | |
*** topol has joined #openstack-keystone | 11:14 | |
*** ChanServ sets mode: +v topol | 11:14 | |
*** _zouyee has quit IRC | 11:17 | |
*** topol has quit IRC | 11:18 | |
*** fhubik has quit IRC | 11:19 | |
*** fhubik has joined #openstack-keystone | 11:19 | |
*** doug-fish has joined #openstack-keystone | 11:21 | |
*** doug-fish has quit IRC | 11:26 | |
*** aix has quit IRC | 11:34 | |
*** jbell8 has joined #openstack-keystone | 11:36 | |
*** fhubik has quit IRC | 11:36 | |
*** fhubik has joined #openstack-keystone | 11:37 | |
*** jbell8 has quit IRC | 11:40 | |
*** fawadkhaliq has quit IRC | 11:40 | |
*** roxanagh_ has joined #openstack-keystone | 11:50 | |
*** topol has joined #openstack-keystone | 11:51 | |
*** ChanServ sets mode: +v topol | 11:51 | |
*** roxanagh_ has quit IRC | 11:55 | |
*** topol has quit IRC | 11:55 | |
*** EinstCrazy has quit IRC | 11:57 | |
*** doug-fish has joined #openstack-keystone | 12:00 | |
openstackgerrit | Bernhard M. Wiedemann proposed openstack/python-keystoneclient: Revert "Use textwrap instead of home made implementation" https://review.openstack.org/252355 | 12:01 |
*** _zouyee has joined #openstack-keystone | 12:01 | |
*** aix has joined #openstack-keystone | 12:04 | |
*** rha has joined #openstack-keystone | 12:06 | |
*** btully has joined #openstack-keystone | 12:08 | |
*** fhubik is now known as fhubik_brb | 12:11 | |
*** raildo-afk is now known as raildo | 12:12 | |
*** fhubik_brb is now known as fhubik | 12:14 | |
*** LiuNanke has joined #openstack-keystone | 12:16 | |
*** btully has quit IRC | 12:19 | |
*** EinstCrazy has joined #openstack-keystone | 12:22 | |
*** LiuNanke has quit IRC | 12:22 | |
*** btully has joined #openstack-keystone | 12:25 | |
*** topol has joined #openstack-keystone | 12:28 | |
*** ChanServ sets mode: +v topol | 12:28 | |
*** LiuNanke has joined #openstack-keystone | 12:28 | |
*** LiuNanke has quit IRC | 12:29 | |
*** topol has quit IRC | 12:32 | |
*** kiran-r has joined #openstack-keystone | 12:33 | |
*** btully has quit IRC | 12:38 | |
*** btully has joined #openstack-keystone | 12:42 | |
*** gordc has joined #openstack-keystone | 12:42 | |
*** jaosorior has quit IRC | 12:43 | |
*** jaosorior has joined #openstack-keystone | 12:44 | |
*** kiran-r has quit IRC | 12:47 | |
openstackgerrit | Mehdi Abaakouk (sileht) proposed openstack/keystonemiddleware: Keystoneauth shouldn't list options of other lib https://review.openstack.org/252373 | 12:53 |
*** figless has joined #openstack-keystone | 12:54 | |
*** dancn has joined #openstack-keystone | 12:56 | |
*** pauloewerton has joined #openstack-keystone | 13:01 | |
*** figless has left #openstack-keystone | 13:03 | |
*** topol has joined #openstack-keystone | 13:04 | |
*** ChanServ sets mode: +v topol | 13:04 | |
*** topol has quit IRC | 13:09 | |
*** btully has quit IRC | 13:13 | |
*** tyagiprince has quit IRC | 13:15 | |
*** btully has joined #openstack-keystone | 13:15 | |
openstackgerrit | gordon chung proposed openstack/pycadf: relax id validation https://review.openstack.org/252183 | 13:17 |
openstackgerrit | gordon chung proposed openstack/pycadf: relax id validation https://review.openstack.org/252183 | 13:19 |
*** thiagop-afk has joined #openstack-keystone | 13:22 | |
*** topol has joined #openstack-keystone | 13:22 | |
*** ChanServ sets mode: +v topol | 13:22 | |
*** topol has quit IRC | 13:24 | |
*** thiagop-afk is now known as thiagop | 13:26 | |
dolphm | lbragstad: the eBay keystone talk https://www.youtube.com/watch?v=vV6KfxWdSKY | 13:33 |
*** lhinds has joined #openstack-keystone | 13:34 | |
*** markvoelker has joined #openstack-keystone | 13:36 | |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Unified delegation model https://review.openstack.org/208488 | 13:37 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Unified delegation driver https://review.openstack.org/209600 | 13:37 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Unified delegation migration https://review.openstack.org/237047 | 13:37 |
*** ninag has joined #openstack-keystone | 13:40 | |
*** btully has quit IRC | 13:41 | |
*** markvoelker_ has joined #openstack-keystone | 13:41 | |
*** jaosorior has quit IRC | 13:42 | |
*** markvoelker has quit IRC | 13:42 | |
*** btully has joined #openstack-keystone | 13:43 | |
*** jaosorior has joined #openstack-keystone | 13:43 | |
*** edmondsw has joined #openstack-keystone | 13:46 | |
*** roxanagh_ has joined #openstack-keystone | 13:52 | |
*** links has quit IRC | 13:53 | |
*** josecastroleon has quit IRC | 13:56 | |
*** josecastroleon has joined #openstack-keystone | 13:57 | |
*** roxanagh_ has quit IRC | 13:57 | |
*** jed56 has joined #openstack-keystone | 13:58 | |
openstackgerrit | Monty Taylor proposed openstack/python-keystoneclient: Accept v2 params to v3 service create https://review.openstack.org/233102 | 14:01 |
*** dims has joined #openstack-keystone | 14:01 | |
*** topol has joined #openstack-keystone | 14:02 | |
*** ChanServ sets mode: +v topol | 14:02 | |
*** breitz has quit IRC | 14:05 | |
*** breitz has joined #openstack-keystone | 14:05 | |
lbragstad | dolphm nice, watching it now | 14:06 |
*** topol has quit IRC | 14:06 | |
*** richm has joined #openstack-keystone | 14:10 | |
*** jerrygb has joined #openstack-keystone | 14:10 | |
*** btully has quit IRC | 14:10 | |
*** ayoung has quit IRC | 14:13 | |
*** e0ne has joined #openstack-keystone | 14:14 | |
*** fawadkhaliq has joined #openstack-keystone | 14:15 | |
*** btully has joined #openstack-keystone | 14:17 | |
*** e0ne_ has joined #openstack-keystone | 14:23 | |
*** petertr7_away is now known as petertr7 | 14:23 | |
*** e0ne has quit IRC | 14:24 | |
*** topol has joined #openstack-keystone | 14:26 | |
*** ChanServ sets mode: +v topol | 14:26 | |
*** topol has quit IRC | 14:27 | |
*** topol has joined #openstack-keystone | 14:28 | |
*** ChanServ sets mode: +v topol | 14:28 | |
*** topol has quit IRC | 14:28 | |
*** topol has joined #openstack-keystone | 14:28 | |
*** ChanServ sets mode: +v topol | 14:28 | |
*** tyagiprince has joined #openstack-keystone | 14:29 | |
*** btully has quit IRC | 14:31 | |
*** btully has joined #openstack-keystone | 14:31 | |
*** topol has quit IRC | 14:33 | |
*** josecastroleon1 has joined #openstack-keystone | 14:34 | |
*** josecastroleon has quit IRC | 14:35 | |
openstackgerrit | Boris Bobrov proposed openstack/keystone: Enable limiting in ldap for groups https://review.openstack.org/234849 | 14:41 |
openstackgerrit | Boris Bobrov proposed openstack/keystone: Limiting for fake LDAP https://review.openstack.org/247749 | 14:41 |
openstackgerrit | Boris Bobrov proposed openstack/keystone: Use @truncated in ldap for users https://review.openstack.org/233070 | 14:41 |
*** fawadkhaliq has quit IRC | 14:44 | |
*** fhubik is now known as fhubik_brb | 14:46 | |
xek | bknudson, lbragstad, Hi | 14:53 |
*** _zouyee has quit IRC | 14:54 | |
*** roxanagh_ has joined #openstack-keystone | 14:54 | |
openstackgerrit | Alexander Makarov proposed openstack/keystone-specs: Unified delegation spec https://review.openstack.org/189816 | 14:55 |
*** josecastroleon has joined #openstack-keystone | 14:56 | |
*** btully has quit IRC | 14:57 | |
*** josecastroleon1 has quit IRC | 14:58 | |
stevemar | thanks for looking at the pycadf patch bknudson | 14:59 |
stevemar | that seems like the right place to fix it | 14:59 |
*** btully has joined #openstack-keystone | 14:59 | |
*** josecastroleon1 has joined #openstack-keystone | 15:00 | |
bknudson | stevemar: don't we need to fix it in keystone, too? | 15:00 |
bknudson | we don't want warnings all over keystone logs | 15:00 |
*** roxanagh_ has quit IRC | 15:00 | |
xek | bknudson, lbragstad, I'm thinking about introducing a configuration variable to aid online schema migration, like "compatibility_mode=true", which could turn off the migration logic to improve performance | 15:00 |
xek | what do you think? | 15:00 |
*** josecastroleon has quit IRC | 15:00 | |
stevemar | bknudson: filter out the warnings? we can't change the IDs, and we'll always fail since they are not actually UUIDs | 15:01 |
*** EinstCra_ has joined #openstack-keystone | 15:01 | |
*** dancn has quit IRC | 15:02 | |
lbragstad | xek do we know what approach we want to take | 15:03 |
bknudson | stevemar: we could filter the warnings but then we should print out own anyways. If it's wrong to use non-uuids then we're not using pycadf correctly | 15:03 |
*** mhickey has quit IRC | 15:03 | |
lbragstad | xek some people yesterday were thinking the expand/contact path was the right way to go | 15:03 |
xek | in my opinion, the two approaches are complementary | 15:04 |
*** EinstCrazy has quit IRC | 15:04 | |
*** topol has joined #openstack-keystone | 15:04 | |
*** ChanServ sets mode: +v topol | 15:04 | |
*** csoukup has joined #openstack-keystone | 15:05 | |
xek | lbragstad, the expand/contract approach helps in that it would perform the contraction in the same release that stops using the old columns/tables | 15:06 |
bknudson | stevemar: seems like pycadf shouldn't validate that the IDs are UUIDs since it's not actually required to be a UUID | 15:06 |
bknudson | or is the ID required to be a UUID? | 15:06 |
openstackgerrit | Shuquan Huang proposed openstack/keystone: Put py34 first in the env order of tox https://review.openstack.org/252443 | 15:07 |
bknudson | xek: I don't think deployers are going to know when to set compatibility_mode and it's going to be very difficult for devs to get the code right. | 15:07 |
stevemar | gordc: ^ | 15:08 |
*** topol has quit IRC | 15:09 | |
stevemar | bknudson: lemme read the spec... i'm not sure if IDs have to be UUIDs | 15:09 |
xek | bknudson, I think of describing it in the spec as one of the approaches, in the end, the developer could decide if he would like to optimize in this way | 15:09 |
stevemar | i think that may be an implementation choice | 15:09 |
bknudson | maybe pycadf could have a switch or something that we could set in keystone | 15:10 |
*** btully has quit IRC | 15:10 | |
bknudson | that says that we know that IDs aren't uuids. | 15:10 |
bknudson | although I guess that's the same as disabling the warning. | 15:11 |
gordc | bknudson: according to spec, it should be uuid | 15:11 |
gordc | granted, it's damn near impossible for us to actually do that in openstack | 15:11 |
bknudson | I think we have user IDs that are sha256 of user ID and domain ID or something | 15:11 |
*** btully has joined #openstack-keystone | 15:12 | |
gordc | bknudson: yeah, it's not consistent anywhere in openstack. | 15:12 |
bknudson | also we have user IDs that come from the LDAP entry so it could be any string. | 15:12 |
gordc | i proposed an oslo topic on it... but i quite frankly am not that optimisitic of a person | 15:12 |
gordc | 1420 General requirements | 15:13 |
gordc | 1421 CADF Identifier type values SHALL be created to be Universally Unique Identifiers (UUIDs) so that when | 15:13 |
gordc | 1422 CADF data (e.g., CADF Event Records, Logs, Reports, Resources, Metrics, etc.) is federated, it will be | 15:13 |
gordc | 1423 uniquely identifiable to the source (e.g., cloud provider, service, etc.) that created it. | 15:13 |
gordc | that's from cadf spec. | 15:13 |
stevemar | CADF Identifier type values SHALL be created to be Universally Unique Identifiers (UUIDs) so that when | 15:14 |
stevemar | 1422 CADF data (e.g., CADF Event Records, Logs, Reports, Resources, Metrics, etc.) is federated, it will be | 15:14 |
stevemar | 1423 uniquely identifiable to the source (e.g., cloud provider, service, etc.) that created it. | 15:14 |
stevemar | heyooo | 15:14 |
gordc | lol | 15:14 |
bknudson | ok, ok, I get it! | 15:14 |
gordc | one more time! | 15:14 |
bknudson | so what's wrong with stevemar's keystone change? | 15:14 |
bknudson | https://review.openstack.org/#/c/252182/1/keystone/notifications.py | 15:14 |
*** tyagiprince1 has joined #openstack-keystone | 15:14 | |
stevemar | it's a change in behavior | 15:14 |
bknudson | right, other than it's not backwards compatible | 15:15 |
bknudson | but we already said the pycadf change wasn't backwards compatible | 15:15 |
bknudson | how about we always set initiator.user_id to user_id | 15:15 |
stevemar | we could revert the pycadf change and break the spec, which is better than breaking customers | 15:15 |
bknudson | and only set initiator.id if it's a uuid? | 15:15 |
gordc | bknudson: my only concern is the more we generate new ids, the more likely you are going to have no idea what the hell that new id is | 15:15 |
notmorgan | mordred: https://review.openstack.org/#/c/252447/ | 15:15 |
*** mhickey has joined #openstack-keystone | 15:16 | |
stevemar | that was another idea | 15:16 |
*** tyagiprince has quit IRC | 15:16 | |
*** tyagiprince1 is now known as tyagiprince | 15:16 | |
*** raginbajin has quit IRC | 15:16 | |
gordc | bknudson: well the patch i had was to allow you to continue to put non-uuid... but it'll probably flood your based on what you're saying | 15:16 |
*** raginbajin has joined #openstack-keystone | 15:17 | |
stevemar | gordc: bknudson only if you have notifications turned on | 15:17 |
bknudson | it should only be printed once, but the problem is I don't think deployers are going to know what to do about it | 15:17 |
gordc | bknudson: ignore it. as they do with all non-errors.lol | 15:18 |
bknudson | I'll tell them to complain to stevemar. | 15:18 |
gordc | good choice | 15:18 |
gordc | bknudson: maybe a more neutral warning? | 15:19 |
mordred | notmorgan: wow, we bumped the major? | 15:20 |
gordc | tbh, i partly put warning there so more people would start realising we need uuid | 15:20 |
notmorgan | mordred: dropped py26 support | 15:20 |
*** tyagiprince has quit IRC | 15:20 | |
mordred | YAY! | 15:21 |
bknudson | gordc: I don't have a problem with the warning from pycadf (or even continuing to raise) | 15:21 |
notmorgan | mordred: even though we had no py26 code or special cases | 15:21 |
*** tyagiprince1 has joined #openstack-keystone | 15:21 | |
notmorgan | mordred: so i am grumpy we had to bump the major... but... | 15:21 |
notmorgan | the reason makes sense | 15:21 |
bknudson | gordc: I think we need to figure out how keystone is supposed to work when cadf says we're supposed to use uuid | 15:21 |
gordc | bknudson: cool cool. | 15:21 |
stevemar | bknudson: dolphm's plan for shadow user accounts would fix this | 15:22 |
stevemar | bknudson: this also breaks federated user's since their IDs are not uuid also | 15:22 |
gordc | bknudson: what we did in gnocchi was we convert all non-uuid to uuid. | 15:22 |
stevemar | gordc: how'd you convert it? | 15:22 |
gordc | knida like a display_id vs real id | 15:22 |
lbragstad | that sounds similar to the shadow user thing | 15:23 |
gordc | stevemar: using uuid5 | 15:23 |
*** tyagiprince1 is now known as tyagiprince | 15:23 | |
gordc | stevemar: i'll need to find exact code. | 15:23 |
stevemar | gordc: hook it up | 15:23 |
gordc | but it does add another level of processing where you need to resolve stuff | 15:24 |
gordc | stevemar: https://github.com/openstack/gnocchi/blob/master/gnocchi/utils.py#L24-L43 | 15:24 |
lbragstad | gordc interesting, you just passed the exsiting ids as the strings and hashed them? | 15:25 |
gordc | lbragstad: basically. | 15:25 |
gordc | any id comes in, we check if its uuid, if not, we hash them and assume it's that hashed version. | 15:25 |
*** ayoung has joined #openstack-keystone | 15:26 | |
*** ChanServ sets mode: +v ayoung | 15:26 | |
bknudson | is pycadf an oslo project? | 15:26 |
lbragstad | uuid.uuid5(ns, 'my-user-id-which-is-not-uuid--at-all') | 15:26 |
lbragstad | UUID('54c0ebe3-e212-55a4-bbdc-fdc26c731c5e') | 15:26 |
bknudson | I can't tell anymore. | 15:26 |
lbragstad | sweet | 15:26 |
dims | bknudson : nope | 15:26 |
gordc | bknudson: it's yours :) | 15:27 |
bknudson | ok, I'll go ahead and approve it | 15:27 |
*** mhickey has quit IRC | 15:27 | |
*** mhickey has joined #openstack-keystone | 15:27 | |
bknudson | why does gcb have +2 on pycadf? | 15:27 |
*** petertr7 is now known as petertr7_away | 15:28 | |
bknudson | pycadf must be oslo | 15:28 |
*** josecastroleon has joined #openstack-keystone | 15:28 | |
stevemar | bknudson: he's oslo core and pycadf is oslo | 15:28 |
*** fawadkhaliq has joined #openstack-keystone | 15:28 | |
gordc | bknudson: oslo group is probably still listed... take it off i guess. | 15:28 |
*** btully has quit IRC | 15:28 | |
*** markvoelker_ has quit IRC | 15:28 | |
dims | bknudson : http://markmail.org/message/7ev4ecgwrt43bflu | 15:29 |
dims | it's keystone's! | 15:29 |
dims | :) | 15:29 |
*** josecastroleon1 has quit IRC | 15:29 | |
*** petertr7_away is now known as petertr7 | 15:29 | |
dims | +1 to take oslo group off pycadf | 15:29 |
*** weihan has quit IRC | 15:30 | |
lbragstad | dolphm fyi - https://review.openstack.org/#/c/195780/ | 15:30 |
bknudson | and I assume we still have a pycadf-core | 15:30 |
dolphm | lbragstad: woooooooooooooo | 15:31 |
bknudson | we'll be defaulting to fernet in not ime. | 15:31 |
bknudson | time | 15:31 |
notmorgan | dims: sure | 15:31 |
notmorgan | dims: oslo core was kept on as a courtesy | 15:31 |
dims | thanks notmorgan :) | 15:32 |
notmorgan | dims: but i mean, i'm sure stevemar wont mind if you want to drop oslo-core off | 15:32 |
notmorgan | cause oslo-core is kinda your thing :P | 15:32 |
dims | notmorgan : i'd recommend looking at individuals who have helped from oslo and add them if appropriate | 15:32 |
stevemar | nice job lbragstad and dolphm | 15:32 |
notmorgan | dims: dhellmann and gordc should be explicits as well | 15:33 |
notmorgan | dims: otherwise ... i don't think many folks have | 15:33 |
dims | notmorgan : +1 | 15:33 |
stevemar | dims: you have helped review as well | 15:33 |
stevemar | so +1 for dims | 15:33 |
notmorgan | bknudson: lets land that change! :) | 15:33 |
stevemar | and of course gordc and dhellmann | 15:33 |
notmorgan | bknudson: >.> | 15:33 |
lbragstad | dolphm stevemar i have a patch up for deprecating pki/z | 15:33 |
stevemar | lbragstad: i know ;) | 15:34 |
gordc | yay | 15:34 |
*** spandhe has joined #openstack-keystone | 15:34 | |
lbragstad | stevemar that you do :) thanks for the review | 15:34 |
dolphm | lbragstad: does it depend on the default in devstack? | 15:34 |
*** ChanServ has quit IRC | 15:34 | |
*** raginbajin has quit IRC | 15:34 | |
*** roxanaghe has quit IRC | 15:34 | |
*** marekd has quit IRC | 15:34 | |
*** jaosorior has quit IRC | 15:34 | |
*** hogepodge has quit IRC | 15:34 | |
*** Ephur has quit IRC | 15:34 | |
*** ninag has quit IRC | 15:34 | |
*** lhinds has quit IRC | 15:34 | |
*** pauloewerton has quit IRC | 15:34 | |
*** gordc has quit IRC | 15:34 | |
*** rha has quit IRC | 15:34 | |
*** doug-fish has quit IRC | 15:34 | |
*** lhcheng has quit IRC | 15:34 | |
*** alex_xu has quit IRC | 15:34 | |
*** zz_john5223 has quit IRC | 15:34 | |
*** dtroyer has quit IRC | 15:34 | |
*** pkarikh has quit IRC | 15:34 | |
*** tsufiev has quit IRC | 15:34 | |
*** amakarov has quit IRC | 15:34 | |
*** stevemar has quit IRC | 15:34 | |
*** sileht has quit IRC | 15:34 | |
*** chlong has quit IRC | 15:34 | |
*** xek has quit IRC | 15:34 | |
*** amit213 has quit IRC | 15:34 | |
*** notmyname has quit IRC | 15:34 | |
*** opilotte has quit IRC | 15:34 | |
*** mkoderer has quit IRC | 15:34 | |
*** crinkle has quit IRC | 15:34 | |
*** reed has quit IRC | 15:34 | |
*** swebb has quit IRC | 15:34 | |
*** mgagne has quit IRC | 15:34 | |
*** fawadkhaliq has quit IRC | 15:34 | |
*** josecastroleon has quit IRC | 15:34 | |
*** e0ne_ has quit IRC | 15:34 | |
*** jerrygb has quit IRC | 15:34 | |
*** breitz has quit IRC | 15:34 | |
*** aix has quit IRC | 15:34 | |
*** david-lyle has quit IRC | 15:34 | |
*** chmouel has quit IRC | 15:34 | |
*** dulek has quit IRC | 15:34 | |
*** mdavidson has quit IRC | 15:34 | |
*** anteaya has quit IRC | 15:35 | |
*** elmiko has quit IRC | 15:35 | |
*** x58 has quit IRC | 15:35 | |
*** _fortis has quit IRC | 15:35 | |
*** Daviey has quit IRC | 15:35 | |
*** rmstar has quit IRC | 15:35 | |
*** albertom has quit IRC | 15:35 | |
*** mordred has quit IRC | 15:35 | |
*** charz has quit IRC | 15:35 | |
*** afazekas has quit IRC | 15:35 | |
*** hrou has quit IRC | 15:35 | |
*** kfox1111 has quit IRC | 15:35 | |
*** lifeless has quit IRC | 15:35 | |
*** breton has quit IRC | 15:35 | |
*** gerhardqux has quit IRC | 15:35 | |
*** Madkiss has quit IRC | 15:35 | |
*** raildo has quit IRC | 15:35 | |
*** hugokuo has quit IRC | 15:35 | |
*** blogan has quit IRC | 15:35 | |
*** grantbow has quit IRC | 15:35 | |
*** htruta has quit IRC | 15:35 | |
*** samueldmq has quit IRC | 15:35 | |
*** ptoohill has quit IRC | 15:35 | |
*** rodrigods has quit IRC | 15:35 | |
*** jgriffith has quit IRC | 15:35 | |
*** sirushti has quit IRC | 15:35 | |
*** cburgess has quit IRC | 15:35 | |
*** bknudson has quit IRC | 15:35 | |
*** ir2ivps8_ has quit IRC | 15:35 | |
*** sshen_ has quit IRC | 15:35 | |
*** trey has quit IRC | 15:35 | |
*** dstanek has quit IRC | 15:35 | |
*** mtreinish has quit IRC | 15:35 | |
*** zzzeek has quit IRC | 15:35 | |
*** bapalm has quit IRC | 15:35 | |
*** jistr has quit IRC | 15:35 | |
*** jimbaker has quit IRC | 15:35 | |
*** bigjools has quit IRC | 15:35 | |
*** mhu has quit IRC | 15:35 | |
*** boltR has quit IRC | 15:35 | |
*** toddnni has quit IRC | 15:35 | |
*** zhiyan has quit IRC | 15:35 | |
*** ekarlso has quit IRC | 15:35 | |
*** bradjones has quit IRC | 15:35 | |
*** noqa_v_g1ovnie has quit IRC | 15:35 | |
*** DuncanT has quit IRC | 15:35 | |
*** ramishra has quit IRC | 15:35 | |
*** iurygregory has quit IRC | 15:35 | |
*** andreaf_ has quit IRC | 15:35 | |
*** andreaf has quit IRC | 15:35 | |
*** errr has quit IRC | 15:35 | |
*** briancurtin has quit IRC | 15:35 | |
*** EinstCra_ has quit IRC | 15:35 | |
*** dims has quit IRC | 15:35 | |
*** fhubik_brb has quit IRC | 15:35 | |
*** tomoiaga has quit IRC | 15:35 | |
*** tsymanczyk has quit IRC | 15:35 | |
*** mancdaz has quit IRC | 15:35 | |
*** mnaser has quit IRC | 15:35 | |
*** flaper87 has quit IRC | 15:35 | |
*** tjcocozz has quit IRC | 15:35 | |
*** krotscheck has quit IRC | 15:35 | |
*** petertr7 has quit IRC | 15:35 | |
*** Tridde has quit IRC | 15:35 | |
*** lxsli has quit IRC | 15:35 | |
*** darrenc has quit IRC | 15:35 | |
*** gissi has quit IRC | 15:35 | |
*** jrist has quit IRC | 15:35 | |
*** gsilvis__ has quit IRC | 15:35 | |
*** ericksonfgds has quit IRC | 15:35 | |
*** kragniz has quit IRC | 15:35 | |
*** baffle has quit IRC | 15:35 | |
*** arunkant_ has quit IRC | 15:35 | |
*** arunkant has quit IRC | 15:35 | |
*** david8hu has quit IRC | 15:35 | |
*** d0ugal has quit IRC | 15:35 | |
*** lars2 has quit IRC | 15:35 | |
*** ccard has quit IRC | 15:35 | |
*** zigo has quit IRC | 15:35 | |
*** Nakato has quit IRC | 15:35 | |
*** mjb has quit IRC | 15:35 | |
*** esp has quit IRC | 15:35 | |
*** timburke has quit IRC | 15:35 | |
*** miguelgrinberg has quit IRC | 15:35 | |
*** EmilienM has quit IRC | 15:35 | |
*** telemonster has quit IRC | 15:35 | |
*** notmorgan has quit IRC | 15:35 | |
*** freerunner has quit IRC | 15:35 | |
*** med_ has quit IRC | 15:35 | |
*** jmccrory has quit IRC | 15:35 | |
*** wolsen has quit IRC | 15:35 | |
*** dgonzalez has quit IRC | 15:35 | |
*** Dave has quit IRC | 15:35 | |
*** nonameentername has quit IRC | 15:35 | |
*** Anticimex has quit IRC | 15:35 | |
*** tobasco has quit IRC | 15:35 | |
*** jed56 has quit IRC | 15:35 | |
*** serverascode has quit IRC | 15:35 | |
*** johnthetubaguy has quit IRC | 15:35 | |
*** hockeynut has quit IRC | 15:35 | |
*** lbragstad has quit IRC | 15:35 | |
*** jraim has quit IRC | 15:35 | |
*** sudorandom has quit IRC | 15:35 | |
*** jamielennox has quit IRC | 15:35 | |
*** wasmum has quit IRC | 15:35 | |
*** cloudnull has quit IRC | 15:35 | |
*** d34dh0r53 has quit IRC | 15:35 | |
*** dolphm has quit IRC | 15:35 | |
*** eglute has quit IRC | 15:35 | |
*** BrAsS_mO- has quit IRC | 15:35 | |
*** dobson has quit IRC | 15:35 | |
*** notmorgan has joined #openstack-keystone | 15:36 | |
*** jgriffith has joined #openstack-keystone | 15:37 | |
*** sirushti has joined #openstack-keystone | 15:37 | |
*** cburgess has joined #openstack-keystone | 15:37 | |
*** bknudson has joined #openstack-keystone | 15:37 | |
*** sshen_ has joined #openstack-keystone | 15:37 | |
*** ir2ivps8_ has joined #openstack-keystone | 15:37 | |
*** trey has joined #openstack-keystone | 15:37 | |
*** wolfe.freenode.net sets mode: +v bknudson | 15:37 | |
*** notmorgan has quit IRC | 15:38 | |
*** spandhe has quit IRC | 15:38 | |
*** adelia has joined #openstack-keystone | 15:38 | |
*** ninag has joined #openstack-keystone | 15:39 | |
*** lhinds has joined #openstack-keystone | 15:39 | |
*** pauloewerton has joined #openstack-keystone | 15:39 | |
*** gordc has joined #openstack-keystone | 15:39 | |
*** rha has joined #openstack-keystone | 15:39 | |
*** doug-fish has joined #openstack-keystone | 15:39 | |
*** lhcheng has joined #openstack-keystone | 15:39 | |
*** alex_xu has joined #openstack-keystone | 15:39 | |
*** zz_john5223 has joined #openstack-keystone | 15:39 | |
*** dtroyer has joined #openstack-keystone | 15:39 | |
*** pkarikh has joined #openstack-keystone | 15:39 | |
*** tsufiev has joined #openstack-keystone | 15:39 | |
*** amakarov has joined #openstack-keystone | 15:39 | |
*** stevemar has joined #openstack-keystone | 15:39 | |
*** sileht has joined #openstack-keystone | 15:39 | |
*** chlong has joined #openstack-keystone | 15:39 | |
*** xek has joined #openstack-keystone | 15:39 | |
*** amit213 has joined #openstack-keystone | 15:39 | |
*** notmyname has joined #openstack-keystone | 15:39 | |
*** opilotte has joined #openstack-keystone | 15:39 | |
*** mkoderer has joined #openstack-keystone | 15:39 | |
*** swebb has joined #openstack-keystone | 15:39 | |
*** crinkle has joined #openstack-keystone | 15:39 | |
*** reed has joined #openstack-keystone | 15:39 | |
*** mgagne has joined #openstack-keystone | 15:39 | |
*** wolfe.freenode.net sets mode: +vo lhcheng stevemar | 15:39 | |
*** jistr has joined #openstack-keystone | 15:39 | |
*** jimbaker has joined #openstack-keystone | 15:39 | |
*** bigjools has joined #openstack-keystone | 15:39 | |
*** mhu has joined #openstack-keystone | 15:39 | |
*** boltR has joined #openstack-keystone | 15:39 | |
*** toddnni has joined #openstack-keystone | 15:39 | |
*** zhiyan has joined #openstack-keystone | 15:39 | |
*** ekarlso has joined #openstack-keystone | 15:39 | |
*** bradjones has joined #openstack-keystone | 15:39 | |
*** noqa_v_g1ovnie has joined #openstack-keystone | 15:39 | |
*** DuncanT has joined #openstack-keystone | 15:39 | |
*** ramishra has joined #openstack-keystone | 15:39 | |
*** iurygregory has joined #openstack-keystone | 15:39 | |
*** andreaf_ has joined #openstack-keystone | 15:39 | |
*** andreaf has joined #openstack-keystone | 15:39 | |
*** marekd has joined #openstack-keystone | 15:39 | |
*** wolfe.freenode.net sets mode: +v marekd | 15:39 | |
*** btully has joined #openstack-keystone | 15:39 | |
*** raginbajin has joined #openstack-keystone | 15:40 | |
*** zigo has joined #openstack-keystone | 15:40 | |
*** Nakato has joined #openstack-keystone | 15:40 | |
*** mjb has joined #openstack-keystone | 15:40 | |
*** esp has joined #openstack-keystone | 15:40 | |
*** timburke has joined #openstack-keystone | 15:40 | |
*** miguelgrinberg has joined #openstack-keystone | 15:40 | |
*** EmilienM has joined #openstack-keystone | 15:40 | |
*** telemonster has joined #openstack-keystone | 15:40 | |
*** freerunner has joined #openstack-keystone | 15:40 | |
*** med_ has joined #openstack-keystone | 15:40 | |
*** jmccrory has joined #openstack-keystone | 15:40 | |
*** wolsen has joined #openstack-keystone | 15:40 | |
*** dgonzalez has joined #openstack-keystone | 15:40 | |
*** Dave has joined #openstack-keystone | 15:40 | |
*** nonameentername has joined #openstack-keystone | 15:40 | |
*** Anticimex has joined #openstack-keystone | 15:40 | |
*** tobasco has joined #openstack-keystone | 15:40 | |
*** iurygregory has quit IRC | 15:41 | |
*** alex_xu has quit IRC | 15:41 | |
*** jaosorior has joined #openstack-keystone | 15:42 | |
*** lhinds has quit IRC | 15:42 | |
stevemar | keystone broke everyone this morning | 15:42 |
*** roxanaghe has joined #openstack-keystone | 15:42 | |
stevemar | including itself | 15:42 |
*** dstanek has joined #openstack-keystone | 15:42 | |
*** mtreinish has joined #openstack-keystone | 15:42 | |
*** zzzeek has joined #openstack-keystone | 15:42 | |
*** bapalm has joined #openstack-keystone | 15:42 | |
*** wolfe.freenode.net sets mode: +v dstanek | 15:42 | |
*** errr has joined #openstack-keystone | 15:42 | |
*** briancurtin has joined #openstack-keystone | 15:42 | |
*** hogepodge has joined #openstack-keystone | 15:42 | |
*** Ephur has joined #openstack-keystone | 15:42 | |
*** johnthetubaguy has joined #openstack-keystone | 15:43 | |
*** jed56 has joined #openstack-keystone | 15:43 | |
*** serverascode has joined #openstack-keystone | 15:43 | |
*** hockeynut has joined #openstack-keystone | 15:43 | |
*** lbragstad has joined #openstack-keystone | 15:43 | |
*** jraim has joined #openstack-keystone | 15:43 | |
*** sudorandom has joined #openstack-keystone | 15:43 | |
*** jamielennox has joined #openstack-keystone | 15:43 | |
*** wasmum has joined #openstack-keystone | 15:43 | |
*** cloudnull has joined #openstack-keystone | 15:43 | |
*** d34dh0r53 has joined #openstack-keystone | 15:43 | |
*** dolphm has joined #openstack-keystone | 15:43 | |
*** eglute has joined #openstack-keystone | 15:43 | |
*** BrAsS_mO- has joined #openstack-keystone | 15:43 | |
*** dobson has joined #openstack-keystone | 15:43 | |
*** wolfe.freenode.net sets mode: +vo jamielennox dolphm | 15:43 | |
*** topol has joined #openstack-keystone | 15:44 | |
*** sigmavirus24 has joined #openstack-keystone | 15:46 | |
*** ctina has joined #openstack-keystone | 15:51 | |
*** btully has quit IRC | 15:51 | |
*** aix has joined #openstack-keystone | 15:51 | |
*** _fortis has joined #openstack-keystone | 15:51 | |
dstanek | it felt like i was cut off from the world for a bit | 15:51 |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Deprecate the pki and pkiz token providers. https://review.openstack.org/241389 | 15:51 |
lbragstad | dolphm if we are recommending fernet *or* uuid, then I don't think it does | 15:53 |
bknudson | we should change one of the devstack jobs to use fernet | 15:54 |
*** ayoung has quit IRC | 15:54 | |
bknudson | maybe there's a devstack job using pki? | 15:54 |
lbragstad | bknudson not sure, where do I look for that? | 15:54 |
dolphm | bknudson: not that i'm aware of | 15:54 |
bknudson | lbragstad: you could check the logs in the gate-tempest-dsvm-* jobs in keystone reviews | 15:55 |
*** markvoelker has joined #openstack-keystone | 15:55 | |
*** slberger has joined #openstack-keystone | 15:55 | |
bknudson | probably best to ask in -qa how they figure out what options to send to devstack. | 15:55 |
lbragstad | bknudson http://logs.openstack.org/82/251482/1/check/gate-tempest-dsvm-full/194678e/logs/apache/keystone.txt.gz#_2015-11-30_17_59_43_195453 | 15:56 |
*** elmiko has joined #openstack-keystone | 15:58 | |
*** iurygregory has joined #openstack-keystone | 15:59 | |
*** d0ugal has joined #openstack-keystone | 15:59 | |
*** jrist has joined #openstack-keystone | 15:59 | |
*** chmouel has joined #openstack-keystone | 15:59 | |
*** fawadkhaliq has joined #openstack-keystone | 15:59 | |
*** josecastroleon has joined #openstack-keystone | 15:59 | |
*** e0ne_ has joined #openstack-keystone | 15:59 | |
*** jerrygb has joined #openstack-keystone | 15:59 | |
*** breitz has joined #openstack-keystone | 15:59 | |
*** david-lyle has joined #openstack-keystone | 15:59 | |
*** dulek has joined #openstack-keystone | 15:59 | |
*** mdavidson has joined #openstack-keystone | 15:59 | |
*** anteaya has joined #openstack-keystone | 15:59 | |
*** x58 has joined #openstack-keystone | 15:59 | |
*** Daviey has joined #openstack-keystone | 15:59 | |
*** rmstar has joined #openstack-keystone | 15:59 | |
*** albertom has joined #openstack-keystone | 15:59 | |
*** mordred has joined #openstack-keystone | 15:59 | |
*** charz has joined #openstack-keystone | 15:59 | |
*** kfox1111 has joined #openstack-keystone | 15:59 | |
*** lifeless has joined #openstack-keystone | 15:59 | |
*** breton has joined #openstack-keystone | 15:59 | |
*** gerhardqux has joined #openstack-keystone | 15:59 | |
*** Madkiss has joined #openstack-keystone | 15:59 | |
*** raildo has joined #openstack-keystone | 15:59 | |
*** hugokuo has joined #openstack-keystone | 15:59 | |
*** blogan has joined #openstack-keystone | 15:59 | |
*** grantbow has joined #openstack-keystone | 15:59 | |
*** htruta has joined #openstack-keystone | 15:59 | |
*** samueldmq has joined #openstack-keystone | 15:59 | |
*** ptoohill has joined #openstack-keystone | 15:59 | |
*** rodrigods has joined #openstack-keystone | 15:59 | |
lbragstad | xek have you worked with the expand/contact method much? | 15:59 |
*** rcernin has quit IRC | 15:59 | |
lbragstad | xek i like the expand/contact approach from the perspective that we don't have to keep things around for several releases. | 16:00 |
lbragstad | that is appealing, just because it's less context to have to remember over a longer period of time | 16:00 |
openstackgerrit | Mehdi Abaakouk (sileht) proposed openstack/keystonemiddleware: Keystonemiddleware shouldn't list options of other lib https://review.openstack.org/252373 | 16:01 |
lbragstad | and if I were an operator, I'd consider that a plus | 16:01 |
dstanek | lbragstad: that was my main concern with the proposal | 16:01 |
xek | lbragstad, the problem is it doesn't help much, here is a discussion in neutron that a colleague of mine continued http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2015-12-01.log.html#t2015-12-01T11:59:57 | 16:02 |
dstanek | keeping cruft for a year or year and a half | 16:02 |
*** mhickey has quit IRC | 16:02 | |
*** kragniz has joined #openstack-keystone | 16:03 | |
xek | lbragstad, so to really shorten the timeframe, we would have to introduce something like that configuration value, and to shorten the upgrade to one release, multiple versions of sqlalchemy models should be supported | 16:03 |
lbragstad | xek so, in order to do that we would have to know which model to used based on schema? | 16:05 |
lbragstad | xek try and load a model, if it fails try and load another one, so on and so forth | 16:06 |
bknudson | we can get the version of the schema from sqlalchemy | 16:06 |
dstanek | lbragstad: loading the model won't fail in many cases. you just won't get all of the data | 16:06 |
xek | lbragstad, yes, but it would also have to be configured somewhere, so we know which schema to use before we get a DB error | 16:06 |
lbragstad | what if the model requires something that has been removed? | 16:06 |
bknudson | os then you could load the model based on the migration #. | 16:07 |
lbragstad | will we ever hit that case? | 16:07 |
dstanek | bknudson: ++ | 16:07 |
*** ctina has quit IRC | 16:07 | |
xek | bknudson, oh, your'e right | 16:07 |
bknudson | so you don't need a config option, just check the migration #. | 16:07 |
*** ctina has joined #openstack-keystone | 16:07 | |
bknudson | umm... maybe not... have to think about that some more | 16:08 |
dstanek | xek: lbragstad: bknudson: so that means we may have to have our versioned drivers keep their old models after all? | 16:08 |
bknudson | dstanek: I was thinking about that too, since we can use the old sql driver... | 16:08 |
dstanek | couldn't this be as simple as having the correct versioned driver in the config? | 16:08 |
lbragstad | so, instead of specifying the sql driver, you'd specify the versioned driver? | 16:09 |
*** iurygregory has quit IRC | 16:09 | |
*** d0ugal has quit IRC | 16:09 | |
*** jrist has quit IRC | 16:09 | |
*** chmouel has quit IRC | 16:09 | |
*** fawadkhaliq has quit IRC | 16:09 | |
*** josecastroleon has quit IRC | 16:09 | |
*** e0ne_ has quit IRC | 16:09 | |
*** jerrygb has quit IRC | 16:09 | |
*** breitz has quit IRC | 16:09 | |
*** david-lyle has quit IRC | 16:09 | |
*** dulek has quit IRC | 16:09 | |
*** mdavidson has quit IRC | 16:09 | |
*** anteaya has quit IRC | 16:09 | |
*** x58 has quit IRC | 16:09 | |
*** Daviey has quit IRC | 16:09 | |
*** rmstar has quit IRC | 16:09 | |
*** albertom has quit IRC | 16:09 | |
*** mordred has quit IRC | 16:09 | |
*** charz has quit IRC | 16:09 | |
*** kfox1111 has quit IRC | 16:09 | |
*** lifeless has quit IRC | 16:09 | |
*** breton has quit IRC | 16:09 | |
*** gerhardqux has quit IRC | 16:09 | |
*** Madkiss has quit IRC | 16:09 | |
*** raildo has quit IRC | 16:09 | |
*** hugokuo has quit IRC | 16:09 | |
*** blogan has quit IRC | 16:09 | |
*** grantbow has quit IRC | 16:09 | |
*** htruta has quit IRC | 16:09 | |
*** samueldmq has quit IRC | 16:09 | |
*** ptoohill has quit IRC | 16:09 | |
*** rodrigods has quit IRC | 16:09 | |
bknudson | the new driver might still have to do some work until the migration is complete. | 16:09 |
dstanek | lbragstad: yes | 16:09 |
dstanek | bknudson: not the driver but the manager | 16:10 |
dstanek | or actually an adapter | 16:10 |
dstanek | it already has to know how to deal with the difference | 16:10 |
lbragstad | the driver will have to be smart enough to handle both schemas | 16:10 |
xek | dstanek, not the old models, but the intermediate models, which migrate the data | 16:10 |
dstanek | lbragstad: no, only it's schema | 16:10 |
xek | but only in case of migrating a column to a new type | 16:10 |
lbragstad | so what if we take this as an example - https://review.openstack.org/#/c/243742/ | 16:11 |
bknudson | also, we might be overarchitecting this. maybe we don't change the schema enough that it's actually going to be a problem. | 16:11 |
xek | bknudson, I'm of the same opinion | 16:12 |
lbragstad | bknudson what do you mean? | 16:12 |
dstanek | bknudson: ++ | 16:12 |
lbragstad | not being able to change types? | 16:12 |
dstanek | if this gets too complicated we'll just break it in worse ways | 16:13 |
bknudson | lbragstad: if there's only 1 or 2 times that we're planning on a backwards-incompatible change then it's not that big of a deal to carry some cruft for a release. | 16:13 |
lbragstad | bknudson oh, i see what you're saying | 16:13 |
gordc | how do i avoid this in my test: oslo_config.cfg.RequiredOptError: value required for option: keystone_authtoken.auth-url | 16:13 |
lbragstad | bknudson so we would be opting for *not* the expand/contact model? | 16:14 |
bknudson | lbragstad: https://review.openstack.org/#/c/243742/ is a good example, so would be interesting to know how online schema migration would handle it. | 16:14 |
bknudson | lbragstad: yes, then we wouldn't worry about expand/contract. | 16:14 |
dstanek | xek: so the overall goal is to require restarts to load new keystone code, but not have to take the database down? | 16:14 |
xek | dstanek, yes | 16:15 |
dstanek | xek: so do we need to tell people to stop using MySQL? doesn't it table lock in lots of cases? like adding or changing an index | 16:15 |
xek | dstanek, but restarting one by one, so there may be 2 versions running simultaneously, like L+M | 16:15 |
bknudson | I think the goal would be to do 1) run keystone-manage db_sync with new code, 2) ansible-deploy new keystone code to new notes and retire old instances | 16:15 |
bknudson | eventually all your instances are running new code | 16:16 |
xek | dstanek, I heard it does, but I think operators have some ways to work around those issues, or at least know about them | 16:16 |
dstanek | bknudson: i think you may be better off moving all to new code first and then doing the migration | 16:16 |
*** EinstCrazy has joined #openstack-keystone | 16:16 | |
dstanek | the code can understand the current and future versions of the schema | 16:16 |
dstanek | xek: i don't think you can work around them. i think the database needs to stop (if it's mysql) | 16:17 |
xek | with the unit forbidding backward incomatible changes in place, an operator could even downgrade the service, without downgrade scripts | 16:17 |
xek | *unit test | 16:18 |
*** EinstCrazy has quit IRC | 16:18 | |
*** woodster_ has joined #openstack-keystone | 16:18 | |
bknudson | dstanek: how would keystone know when the migration is complete? is it going to be monitoring the schema version? | 16:18 |
dstanek | xek: no, because we can still interpret the data differently | 16:18 |
bknudson | you'd need a new column if the data is interpreted differently | 16:19 |
bknudson | and you'd need to maintain both columns for a release. | 16:19 |
dstanek | bknudson: the way you do it in a nosql database is looking at the data. in lbragstad's example the data from the same column would have different type | 16:19 |
dstanek | bknudson: that is the traditional way with sql databases | 16:20 |
bknudson | then we should switch to nosql | 16:20 |
bknudson | but that's not what we're doing | 16:20 |
bknudson | in sql you can't have some rows where the column is INTEGER and other rows where the column is DATETIME | 16:21 |
dstanek | bknudson: exactly | 16:21 |
bknudson | I'm not sure how sql-based code would be able to handle the column type changing under it. | 16:22 |
dstanek | so in lbragstad's example you'd have issued_before as a datetime and issued_before2 as an integer | 16:22 |
dstanek | writes would go into the new column and reads would deal with both | 16:23 |
lbragstad | bknudson ++ i think updating the application layer first makes sense | 16:23 |
dstanek | a migration would move the data | 16:23 |
xek | bknudson, there would have to be some abstraction layer, like another object, which would replace the abstracted sqlalchemy model | 16:23 |
*** jbell8 has joined #openstack-keystone | 16:23 | |
dstanek | lbragstad: yep, that's what i said above. code first and that wold handle old and new schema | 16:23 |
xek | bknudson, ^ | 16:24 |
bknudson | dstanek: but I don't get how you're going to change the schema while the instances are running? | 16:24 |
dstanek | but it doesn't solve the issue of not bringing mysql down | 16:24 |
lbragstad | yeah, so that code has to be smart enough to look in the old place if the new place doesn't have anything in it | 16:24 |
dstanek | bknudson: you would just add the column | 16:24 |
lbragstad | bring mysql down is a case by case thing | 16:24 |
bknudson | then keystone would somehow discover that the column was added? | 16:25 |
lbragstad | depending on what you're doing to the schema | 16:25 |
xek | dstanek, I don't think all mysql db backends have these problems | 16:25 |
xek | dstanek, but I run postgres in production, so I wouldn't know | 16:25 |
dstanek | xek: it's a mysql server thing, or at least it use to be (not just a table type thing) | 16:25 |
dstanek | we'd have to do some research since i haven't had to mess with mysql in at least 5 years | 16:26 |
lbragstad | also, what do we consider "bringing mysql down"? | 16:26 |
bknudson | why do you have to restart mysql? | 16:26 |
lbragstad | what about locking the table? | 16:26 |
lbragstad | because if we can't lock a table, then that throws alter table statements out the window right? | 16:27 |
dstanek | lbragstad: if you lock a table then the better experience would be to bring the service down and give 500s than have somethings work and others not | 16:27 |
lbragstad | yeah, depending on the table you're locking | 16:28 |
dstanek | bknudson: you don't have to restart, but in the past mysql would table lock | 16:28 |
dstanek | from way back in the day https://web.archive.org/web/20090421001753/http://bret.appspot.com/entry/how-friendfeed-uses-mysql | 16:28 |
bknudson | yes, schema changes typically lock the table | 16:28 |
xek | dstanek, I just googled that there are some some options of altering the schema without bringing mysql down https://signalvnoise.com/posts/3174-taking-the-pain-out-of-mysql-schema-changes | 16:29 |
lbragstad | xek dstanek bknudson do you think it would make sense to detail that more in the spec? the expectation between lock and bringing down? | 16:29 |
bknudson | I think with the work we're doing we really shouldn't have much in the database | 16:30 |
bknudson | eventually | 16:30 |
lbragstad | bknudson you mean the stuff that keystone stores? | 16:30 |
bknudson | lbragstad: right | 16:30 |
lbragstad | yay to tokens being gone! | 16:30 |
lbragstad | (almost) | 16:30 |
dstanek | xek: the question is "is all that worth it?" | 16:31 |
lbragstad | odyssey4me had some good feedback at the summit around this too | 16:31 |
lbragstad | maybe cloudnull if he's available? | 16:32 |
bknudson | I don't want my cloud to have to be taken down during upgrades. | 16:32 |
cloudnull | wat!? | 16:32 |
lbragstad | that seems to be the general concensus | 16:32 |
dstanek | xek: where i use to work we bought companies and migrated them to our systems. the code would understand how to get the data from both systems during the migration and we'd have to do incremental data migrations because the data could change in the source system | 16:32 |
dstanek | it got complicated | 16:32 |
lbragstad | dstanek you needed something to migrate the delta between the two, right | 16:33 |
dstanek | lbragstad: yes | 16:33 |
lbragstad | that's hairy | 16:33 |
bknudson | why don't we keep users and groups in nosql. | 16:33 |
lbragstad | what about revocation events? | 16:33 |
bknudson | and tokens and revocation events | 16:33 |
stevemar | bknudson: agree/disagree, keystone fix for pycadf warnings is not critical to m1? | 16:34 |
dstanek | option 3 is what i am use to, but if would require us to deal with some interesting issues | 16:34 |
lbragstad | lol, so the catalog is the only thing still in sql | 16:34 |
stevemar | once we depend on the new library... | 16:34 |
bknudson | stevemar: I don't think the fix for warnings is critical to m1 | 16:34 |
*** ccard has joined #openstack-keystone | 16:34 | |
*** lars2 has joined #openstack-keystone | 16:34 | |
*** david8hu has joined #openstack-keystone | 16:34 | |
*** arunkant has joined #openstack-keystone | 16:34 | |
*** arunkant_ has joined #openstack-keystone | 16:34 | |
*** baffle has joined #openstack-keystone | 16:34 | |
*** ericksonsantos has joined #openstack-keystone | 16:34 | |
*** gsilvis__ has joined #openstack-keystone | 16:34 | |
*** gissi has joined #openstack-keystone | 16:34 | |
*** darrenc has joined #openstack-keystone | 16:34 | |
*** Tridde has joined #openstack-keystone | 16:34 | |
*** petertr7 has joined #openstack-keystone | 16:34 | |
*** krotscheck has joined #openstack-keystone | 16:34 | |
*** tjcocozz has joined #openstack-keystone | 16:34 | |
*** flaper87 has joined #openstack-keystone | 16:34 | |
*** mancdaz has joined #openstack-keystone | 16:34 | |
*** tsymanczyk has joined #openstack-keystone | 16:34 | |
*** lxsli has joined #openstack-keystone | 16:34 | |
*** hrou has joined #openstack-keystone | 16:34 | |
*** notmorgan has joined #openstack-keystone | 16:34 | |
*** afazekas has joined #openstack-keystone | 16:34 | |
*** alex_xu_ has joined #openstack-keystone | 16:34 | |
*** mnaser has joined #openstack-keystone | 16:34 | |
*** lhinds has joined #openstack-keystone | 16:34 | |
*** diazjf has joined #openstack-keystone | 16:34 | |
*** d0ugal has joined #openstack-keystone | 16:34 | |
*** jrist has joined #openstack-keystone | 16:34 | |
*** chmouel has joined #openstack-keystone | 16:34 | |
*** fawadkhaliq has joined #openstack-keystone | 16:34 | |
*** jerrygb has joined #openstack-keystone | 16:34 | |
*** breitz has joined #openstack-keystone | 16:34 | |
*** david-lyle has joined #openstack-keystone | 16:34 | |
*** dulek has joined #openstack-keystone | 16:34 | |
*** mdavidson has joined #openstack-keystone | 16:34 | |
*** anteaya has joined #openstack-keystone | 16:34 | |
*** x58 has joined #openstack-keystone | 16:34 | |
*** Daviey has joined #openstack-keystone | 16:34 | |
*** rmstar has joined #openstack-keystone | 16:34 | |
*** albertom has joined #openstack-keystone | 16:34 | |
*** mordred has joined #openstack-keystone | 16:34 | |
*** charz has joined #openstack-keystone | 16:34 | |
*** kfox1111 has joined #openstack-keystone | 16:34 | |
*** lifeless has joined #openstack-keystone | 16:34 | |
*** breton has joined #openstack-keystone | 16:34 | |
*** gerhardqux has joined #openstack-keystone | 16:34 | |
*** Madkiss has joined #openstack-keystone | 16:34 | |
*** raildo has joined #openstack-keystone | 16:34 | |
*** hugokuo has joined #openstack-keystone | 16:34 | |
*** blogan has joined #openstack-keystone | 16:34 | |
*** grantbow has joined #openstack-keystone | 16:34 | |
*** htruta has joined #openstack-keystone | 16:34 | |
*** samueldmq has joined #openstack-keystone | 16:34 | |
*** ptoohill has joined #openstack-keystone | 16:34 | |
*** rodrigods has joined #openstack-keystone | 16:34 | |
stevemar | cool. i will ask dhellmann to release a new version of it and bump the requirements | 16:34 |
dstanek | bknudson: is there already an expectation that a cloud needs nosql? | 16:34 |
lbragstad | cloudnull from an operator perspective - have you had much experience with expand/contract models? | 16:34 |
bknudson | it's webscale | 16:35 |
lbragstad | cloudnull versus adding and removing things over long running time periods | 16:35 |
dstanek | mongodb it is! | 16:35 |
bknudson | we can't even use foreign key constraints | 16:36 |
* lbragstad waves goodbye to referential integrity | 16:36 | |
xek | lol | 16:36 |
lbragstad | :) | 16:36 |
lbragstad | as keystone, do we care about one of those more than the other/ | 16:37 |
lbragstad | as keystone operators and developers | 16:37 |
lbragstad | ? | 16:37 |
dstanek | i'm interested in hearing what odyssey4me and cloudnull think about it | 16:38 |
odyssey4me | o/ sorry, in another meeting simultaneously | 16:39 |
lbragstad | ++ from a dev perspective it sounds like we want the ability to be flexible, but I've never scaled mongodb or anything of the like | 16:39 |
xek | odyssey4me, +1 a previous version of the spec | 16:39 |
dstanek | with the second table approach we had a way to tell the code that the data was being migrated so that it wouldn't update records in the old system and instead would migrate on demand when it needed data that wasn't yet migrated | 16:39 |
odyssey4me | I haven't re-read the spec in detail recently. Conceptually I'm in favour of implementing some sort of mechanism. Are there any specific questions on the table? | 16:39 |
lbragstad | odyssey4me do you have experience with an expand/contract db migration model? | 16:40 |
cloudnull | dstanek: I have not used much of the expand / contract capabilities, the only service that has that implemented, for liberty, was neutron (best of my knowledge). I think expand/contract makes a lot of sense for maintaining overall uptime and supporting a deployment for long periods of time. | 16:40 |
lbragstad | versus having long running tables that get cleaned up after a long period of time? | 16:40 |
xek | odyssey4me, neutron has an expand/contract approach, but it doesn't yet support rolling upgrades | 16:40 |
cloudnull | ^ that. | 16:41 |
dstanek | cloudnull: doesn't expand/contract introduce downtime anyway? | 16:41 |
cloudnull | however i think if work is being done on the models / upgrade working toward rolling upgrades is the way to go | 16:41 |
openstackgerrit | Henrique Truta proposed openstack/keystone: API support for project cascade delete https://review.openstack.org/244248 | 16:42 |
openstackgerrit | Henrique Truta proposed openstack/keystone: Manager support for project delete cascade https://review.openstack.org/244149 | 16:42 |
openstackgerrit | Henrique Truta proposed openstack/keystone: Add backend support for deleting a projects list https://review.openstack.org/245916 | 16:42 |
odyssey4me | yeah, the discussion in the spec around expand/contract versus the long running tables has been interesting | 16:42 |
*** jaosorior has quit IRC | 16:42 | |
cloudnull | dstanek: it does for larger migrations however work is being done to get to rolling upgrades | 16:42 |
lbragstad | cloudnull odyssey4me this is the example we're working with - https://review.openstack.org/#/c/243742/ | 16:42 |
bknudson | if you have to maintain 2 copies of the data that's going to affect your performance for the entire release | 16:43 |
odyssey4me | while I don't have specific operational experience either way, expand/contract seems to be beneficial to developers and operators... for operators it's all about minimising down-time and making it predictable... the nova approach isn't so nice for developers, but is very nice for operators as it's no down time | 16:43 |
bknudson | and we seem to have enough performance problems already | 16:43 |
lbragstad | the other thing to think about, is if you have to add a new column, but the original column has references to it. | 16:44 |
lbragstad | that's something i get hung up on | 16:44 |
dstanek | odyssey4me: how is it no downtime? | 16:44 |
*** d0ugal has quit IRC | 16:45 | |
*** jrist has quit IRC | 16:45 | |
*** chmouel has quit IRC | 16:45 | |
*** fawadkhaliq has quit IRC | 16:45 | |
*** jerrygb has quit IRC | 16:45 | |
*** breitz has quit IRC | 16:45 | |
*** david-lyle has quit IRC | 16:45 | |
*** dulek has quit IRC | 16:45 | |
*** mdavidson has quit IRC | 16:45 | |
*** anteaya has quit IRC | 16:45 | |
*** x58 has quit IRC | 16:45 | |
*** Daviey has quit IRC | 16:45 | |
*** rmstar has quit IRC | 16:45 | |
*** albertom has quit IRC | 16:45 | |
*** mordred has quit IRC | 16:45 | |
*** charz has quit IRC | 16:45 | |
*** kfox1111 has quit IRC | 16:45 | |
*** lifeless has quit IRC | 16:45 | |
*** breton has quit IRC | 16:45 | |
*** gerhardqux has quit IRC | 16:45 | |
*** Madkiss has quit IRC | 16:45 | |
*** raildo has quit IRC | 16:45 | |
*** hugokuo has quit IRC | 16:45 | |
*** blogan has quit IRC | 16:45 | |
*** grantbow has quit IRC | 16:45 | |
*** htruta has quit IRC | 16:45 | |
*** samueldmq has quit IRC | 16:45 | |
*** ptoohill has quit IRC | 16:45 | |
*** rodrigods has quit IRC | 16:45 | |
*** diazjf has quit IRC | 16:45 | |
*** lhinds has quit IRC | 16:45 | |
*** alex_xu_ has quit IRC | 16:45 | |
*** afazekas has quit IRC | 16:45 | |
*** notmorgan has quit IRC | 16:45 | |
*** hrou has quit IRC | 16:45 | |
*** mnaser has quit IRC | 16:45 | |
*** tsymanczyk has quit IRC | 16:45 | |
*** mancdaz has quit IRC | 16:45 | |
*** flaper87 has quit IRC | 16:45 | |
*** tjcocozz has quit IRC | 16:45 | |
*** krotscheck has quit IRC | 16:45 | |
*** petertr7 has quit IRC | 16:45 | |
*** Tridde has quit IRC | 16:45 | |
*** lxsli has quit IRC | 16:45 | |
*** darrenc has quit IRC | 16:45 | |
*** gissi has quit IRC | 16:45 | |
*** gsilvis__ has quit IRC | 16:45 | |
*** ericksonsantos has quit IRC | 16:45 | |
*** baffle has quit IRC | 16:45 | |
*** arunkant_ has quit IRC | 16:45 | |
*** arunkant has quit IRC | 16:45 | |
*** david8hu has quit IRC | 16:45 | |
*** lars2 has quit IRC | 16:45 | |
*** ccard has quit IRC | 16:45 | |
dstanek | odyssey4me: i think what they've solved is the need to update DB and code at the same time and not DB upgrades without downtime | 16:45 |
odyssey4me | perhaps it's also good to bear in mind the type of service nova is, versus keystone - nova has many, many agents all over the place... keystone simply has clients | 16:46 |
odyssey4me | I think | 16:46 |
*** rodrigods has joined #openstack-keystone | 16:46 | |
*** ptoohill has joined #openstack-keystone | 16:46 | |
*** samueldmq has joined #openstack-keystone | 16:46 | |
*** htruta has joined #openstack-keystone | 16:46 | |
*** grantbow has joined #openstack-keystone | 16:46 | |
*** blogan has joined #openstack-keystone | 16:46 | |
*** hugokuo has joined #openstack-keystone | 16:46 | |
*** raildo has joined #openstack-keystone | 16:46 | |
*** Madkiss has joined #openstack-keystone | 16:46 | |
*** gerhardqux has joined #openstack-keystone | 16:46 | |
*** breton has joined #openstack-keystone | 16:46 | |
*** lifeless has joined #openstack-keystone | 16:46 | |
*** kfox1111 has joined #openstack-keystone | 16:46 | |
*** charz has joined #openstack-keystone | 16:46 | |
*** mordred has joined #openstack-keystone | 16:46 | |
*** albertom has joined #openstack-keystone | 16:46 | |
*** rmstar has joined #openstack-keystone | 16:46 | |
*** Daviey has joined #openstack-keystone | 16:46 | |
*** x58 has joined #openstack-keystone | 16:46 | |
*** anteaya has joined #openstack-keystone | 16:46 | |
*** mdavidson has joined #openstack-keystone | 16:46 | |
*** dulek has joined #openstack-keystone | 16:46 | |
*** david-lyle has joined #openstack-keystone | 16:46 | |
*** breitz has joined #openstack-keystone | 16:46 | |
*** jerrygb has joined #openstack-keystone | 16:46 | |
*** fawadkhaliq has joined #openstack-keystone | 16:46 | |
*** chmouel has joined #openstack-keystone | 16:46 | |
*** jrist has joined #openstack-keystone | 16:46 | |
*** d0ugal has joined #openstack-keystone | 16:46 | |
*** diazjf has joined #openstack-keystone | 16:46 | |
*** lhinds has joined #openstack-keystone | 16:46 | |
*** mnaser has joined #openstack-keystone | 16:46 | |
*** alex_xu_ has joined #openstack-keystone | 16:46 | |
*** afazekas has joined #openstack-keystone | 16:46 | |
*** notmorgan has joined #openstack-keystone | 16:46 | |
*** hrou has joined #openstack-keystone | 16:46 | |
*** lxsli has joined #openstack-keystone | 16:46 | |
*** tsymanczyk has joined #openstack-keystone | 16:46 | |
*** mancdaz has joined #openstack-keystone | 16:46 | |
*** flaper87 has joined #openstack-keystone | 16:46 | |
*** tjcocozz has joined #openstack-keystone | 16:46 | |
*** krotscheck has joined #openstack-keystone | 16:46 | |
*** petertr7 has joined #openstack-keystone | 16:46 | |
*** Tridde has joined #openstack-keystone | 16:46 | |
*** darrenc has joined #openstack-keystone | 16:46 | |
*** gissi has joined #openstack-keystone | 16:46 | |
*** gsilvis__ has joined #openstack-keystone | 16:46 | |
*** ericksonsantos has joined #openstack-keystone | 16:46 | |
*** baffle has joined #openstack-keystone | 16:46 | |
*** arunkant_ has joined #openstack-keystone | 16:46 | |
*** arunkant has joined #openstack-keystone | 16:46 | |
*** david8hu has joined #openstack-keystone | 16:46 | |
*** lars2 has joined #openstack-keystone | 16:46 | |
*** ccard has joined #openstack-keystone | 16:46 | |
stevemar | odyssey4me: you got it | 16:46 |
dstanek | odyssey4me: for example adding an index (i think) will result in some downtime for the duration of the alter | 16:46 |
odyssey4me | dstanek I am happy to be wrong. :) I haven't yet had enough time to really dig into the real details of both approaches. | 16:47 |
stevemar | odyssey4me: i tihnk mfisch upgrading keystone in < 20 minutes,, and just had a tiny planned outage | 16:47 |
lbragstad | that depends on various SLAs | 16:47 |
xek | dstanek, http://superuser.openstack.org/articles/upgrading-nova-to-kilo-with-minimal-downtime | 16:48 |
dstanek | odyssey4me: i need to see if my assumptions are still true - but 'alter table' use to lock the table during the execution | 16:48 |
odyssey4me | I'm happy for people to add additional reasearch here: https://etherpad.openstack.org/p/openstack-ansible-upgrade-framework | 16:48 |
notmorgan | ok looking | 16:48 |
*** topol has quit IRC | 16:48 | |
*** topol has joined #openstack-keystone | 16:48 | |
*** aix has quit IRC | 16:48 | |
*** aix has joined #openstack-keystone | 16:48 | |
*** elmiko has quit IRC | 16:48 | |
*** elmiko has joined #openstack-keystone | 16:48 | |
*** woodster_ has quit IRC | 16:48 | |
*** woodster_ has joined #openstack-keystone | 16:48 | |
notmorgan | oooh and de-netsplit here | 16:48 |
notmorgan | yay | 16:48 |
*** btully has joined #openstack-keystone | 16:48 | |
odyssey4me | it's a planning etherpad for putting together a framework in OSA - that'll eventually make its way into a spec. | 16:49 |
lbragstad | dstanek http://stackoverflow.com/questions/463677/alter-table-without-locking-the-table | 16:50 |
odyssey4me | the references would be of general interest | 16:50 |
bknudson | dstanek: realistically, don't we only care about locking the token table? | 16:50 |
notmorgan | krotscheck: X-Auth-Token is the actual auth-token sent (both used to/from keystone and to endpoints), X-Identity-Status, X-Roles, X-Service-Catalog, X-User-Id, X-Tenant-Id, are all Middleware driven | 16:50 |
*** iurygregory has joined #openstack-keystone | 16:50 | |
lbragstad | the revocation table gets big, too | 16:50 |
*** roxanagh_ has joined #openstack-keystone | 16:50 | |
bknudson | y, revocations, too would be a problem since you couldn't delete tokens. | 16:50 |
dstanek | lbragstad: so it looks like it's true as of a year ago | 16:50 |
notmorgan | krotscheck: those other ones are set when passing down to the application under middleware and are translated to HTTP_X_* | 16:50 |
lbragstad | dstanek yeah | 16:51 |
notmorgan | krotscheck: so the underlying app can access them | 16:51 |
notmorgan | krotscheck: so, not sure the difference between allow and expose. | 16:51 |
krotscheck | notmorgan: Coooooool. So the middleware headers are request only? | 16:51 |
dstanek | bknudson: depends if the lock blocks reads because we read all kinds of stuff when generating token responses | 16:51 |
notmorgan | krotscheck: the middleware headers are stripped by keystonemiddleware and then repopulated based on the auth token... NOW... | 16:51 |
bknudson | y, role assignments | 16:51 |
krotscheck | notmorgan: Allow is "I want to send you this header, may I" from the client. Expose is "I'm sending you this response, and here's the headers you're allowed to read" | 16:51 |
notmorgan | krotscheck: i am trying to change that | 16:51 |
bknudson | I assume reads would be blocked | 16:51 |
dstanek | bknudson: me too | 16:52 |
lbragstad | so if doing an ALTER statement locks the table, and we opt to create a new table and migrate data, we run into possible performance issues, as well we referential integrity head aches | 16:52 |
*** chmouel has quit IRC | 16:52 | |
notmorgan | krotscheck: so we only authorize a request once at the edge, so you still will want to accept them and let keystonemiddleware strip them/repopulate them | 16:52 |
lbragstad | bknudson dstanek reads would be blocked, at least according to that link | 16:52 |
dstanek | xek: lbragstad: bknudson: my point is that we need to know what we are solving because I'd hate to add tons of complexity only to realize we still have downtime | 16:52 |
*** d0ugal has quit IRC | 16:52 | |
notmorgan | krotscheck: auth-token will be used in both cases | 16:52 |
lbragstad | dstanek ++ | 16:52 |
xek | I know that in case of postgres, there is also a lock, but it's brief in cases like adding a column | 16:52 |
lbragstad | dstanek I think we want to solve the "no-downtime" problem | 16:53 |
krotscheck | notmorgan: Yes, I will always want to accept them, because else the CORS middleware will block the request because security. (urm... yeah. Because that's secure?) | 16:53 |
krotscheck | ¯\_(ツ)_/¯ | 16:53 |
notmorgan | krotscheck: yeah haha. | 16:53 |
krotscheck | notmorgan: But those middleware headers aren't sent back, yes? | 16:53 |
xek | and in case of the tool I found for mysql, it operates on a copy of the table, so the old table is accessible the whole time https://www.percona.com/doc/percona-toolkit/2.1/pt-online-schema-change.html | 16:53 |
lbragstad | I, as an operator, want to be able to upgrade my keystone deployment without an interruption of service | 16:53 |
lbragstad | cloudnull odyssey4me right? ^ | 16:53 |
notmorgan | krotscheck: they should not be part of the response | 16:53 |
dstanek | xek: usually in mysql is fast. the issues we had were generating indexes on really large tables that were replicated | 16:53 |
notmorgan | krotscheck: they should only be part of the "what is sent" to the application | 16:53 |
krotscheck | notmorgan: Same with X-Auth-Token? (it's not in the response?) | 16:54 |
notmorgan | krotscheck: depends on where you use X-Auth-token and X-Subject-token and X-Service-Token | 16:54 |
notmorgan | those are valid to get as responses from keystone | 16:54 |
notmorgan | but to apps behind middleware it should not be part of the response. | 16:54 |
notmorgan | from the app* | 16:54 |
notmorgan | krotscheck: here is the (very basic) diagram of what i'm working towards, and i think it works with what you've laid out | 16:55 |
krotscheck | notmorgan: Right. I'm talking about twhat the user agent (browser) sees. | 16:56 |
cloudnull | lbragstad: yes. however as an operator I understand that some downtime maybe required. | 16:56 |
notmorgan | krotscheck: https://drive.google.com/file/d/0B3TpqJW7-VEebTZ6c05lY3RwcG8/view?usp=sharing | 16:56 |
lbragstad | cloudnull what would those cases be to you? | 16:56 |
lbragstad | cloudnull or what cases are acceptable to have downtime? | 16:56 |
notmorgan | krotscheck: with the goal that the browser/agent/horizon lives outside [perhaps] | 16:56 |
*** timcline has joined #openstack-keystone | 16:57 | |
krotscheck | Yep. That makes sense. | 16:57 |
notmorgan | krotscheck: i'm actually setitng up a PoC of this now so i can hack on it some and see if i can get everything to talk sanely through the API layer then make it so projects don't re-auth all the time | 16:58 |
notmorgan | krotscheck: :) | 16:58 |
notmorgan | krotscheck: for svc->svc that is | 16:58 |
notmorgan | krotscheck: also it's an excuse to learn OSAD, Shade, and Ansible better | 16:59 |
notmorgan | krotscheck: i might bug you to poke at it once i have it stood up | 16:59 |
krotscheck | notmorgan: Let me know how that goes, I have to write a js-keystonelib pretty soon. | 16:59 |
odyssey4me | lbragstad Generally speaking, Operators like things to be predictable. If down time is required, then it is - but it should be easy for me to understand how much down time is required and what the risk is of failure or that time being extended. Every instance of down time has to be justified when planning changes and often has ripple effects. | 16:59 |
* notmorgan has been writing LUA integration for keystonemiddleware to run in HAProxy | 17:00 | |
notmorgan | krotscheck: ^_^ | 17:00 |
*** btully has quit IRC | 17:00 | |
notmorgan | krotscheck: if i'm lucky i can do this for $50/mo or so [i need to get a real lab] | 17:00 |
odyssey4me | So I would say that down time is undesirable, but can happen when necessary. When it is necessary then it must be for a predictable period. | 17:00 |
*** btully has joined #openstack-keystone | 17:01 | |
krotscheck | notmorgan: Ya know, our entire team needs a hardware lab. | 17:01 |
lbragstad | odyssey4me makes sense | 17:01 |
krotscheck | notmorgan: Ok, here's an update, does that all make sense? http://paste.openstack.org/show/480663/ | 17:01 |
*** jistr has quit IRC | 17:01 | |
odyssey4me | lbragstad That's where the expand/contract mechanism can help - do what can be done online and minimise the offline time. | 17:01 |
openstackgerrit | Henrique Truta proposed openstack/keystone: Restricting domain_id update https://review.openstack.org/207218 | 17:02 |
*** pgbridge has joined #openstack-keystone | 17:02 | |
odyssey4me | notmorgan I saw your tweet on that - nifty work. :) | 17:02 |
bknudson | you might not be offline, but operations are all locked up waiting for the schema change | 17:02 |
xek | odyssey4me, I think data migration is what can be more unpredictable, so they should be done online rather then offline | 17:03 |
odyssey4me | xek does data migration involve more risk? | 17:03 |
*** d0ugal has joined #openstack-keystone | 17:03 | |
xek | odyssey4me, well I think it's more unpredictable then schema changes, because it depends how much data you have to migrate | 17:04 |
odyssey4me | risk of failure, data loss, etc? | 17:04 |
xek | odyssey4me, so you have to think about it case by case | 17:04 |
xek | odyssey4me, I was thinking about the execution time | 17:04 |
*** ChanServ has joined #openstack-keystone | 17:04 | |
*** wolfe.freenode.net sets mode: +o ChanServ | 17:04 | |
openstackgerrit | Merged openstack/pycadf: relax id validation https://review.openstack.org/252183 | 17:04 |
*** ChanServ sets mode: +v topol | 17:05 | |
*** mnaser has quit IRC | 17:05 | |
*** mnaser has joined #openstack-keystone | 17:05 | |
*** e0ne has joined #openstack-keystone | 17:05 | |
*** rderose has joined #openstack-keystone | 17:05 | |
*** d0ugal is now known as Guest63340 | 17:05 | |
*** notmorgan is now known as Guest66391 | 17:05 | |
cloudnull | lbragstad: i dont have a specific case that makes downtime "acceptable". however if we cant get the a rolling upgrade 100% then I understand. | 17:05 |
*** btully is now known as Guest87049 | 17:05 | |
*** chmouel has joined #openstack-keystone | 17:06 | |
cloudnull | but i think a rolling upgrade should be the target (even if its a moving one) | 17:06 |
*** Guest66391 is now known as morganfainberg | 17:07 | |
*** morganfainberg has quit IRC | 17:07 | |
*** morganfainberg has joined #openstack-keystone | 17:07 | |
*** ChanServ sets mode: +v morganfainberg | 17:07 | |
*** morganfainberg is now known as notmorgan | 17:07 | |
*** tyagiprince has quit IRC | 17:07 | |
openstackgerrit | Steve Martinelli proposed openstack/keystone: Ensure pycadf initiator IDs are UUID https://review.openstack.org/252182 | 17:07 |
xek | maybe we could merge the unit test, and at least require that the incompatible schema changes would be listed in the release notes | 17:08 |
xek | I think some knowledgeable DBAs could work around those with triggers | 17:08 |
*** belmoreira has joined #openstack-keystone | 17:08 | |
*** tyagiprince has joined #openstack-keystone | 17:09 | |
lbragstad | bknudson dstanek thoughts? ^ | 17:09 |
dstanek | xek: i do like that idea | 17:10 |
bknudson | A unit test shouldn't cause problems, so I'm fine with that. | 17:10 |
lbragstad | xek think we could rework the spec for that scope? | 17:11 |
*** rcernin has joined #openstack-keystone | 17:11 | |
lbragstad | specifically detailing the responsibility on the dba after they read the release notes | 17:11 |
lbragstad | it could also use a rename | 17:12 |
lbragstad | since it not necessarily an online-migration anymore | 17:12 |
lbragstad | its more or less a primer for a real solution to online-migrations | 17:12 |
*** gyee has joined #openstack-keystone | 17:12 | |
*** ChanServ sets mode: +v gyee | 17:12 | |
*** Guest63340 is now known as d0ugal | 17:12 | |
*** d0ugal has quit IRC | 17:13 | |
*** d0ugal has joined #openstack-keystone | 17:13 | |
*** jed56 has quit IRC | 17:13 | |
xek | lbragstad, ok, do you know maybe of someone with DB skills that could review it? | 17:13 |
lbragstad | xek I thought that was you! | 17:15 |
lbragstad | :L) | 17:15 |
xek | well, I'm not entirely sure all changes could be worked around in this way | 17:16 |
xek | and I don't know about mysql | 17:17 |
*** Guest87049 has quit IRC | 17:17 | |
lbragstad | xek if you know of someone that is a dba, it would be nice to get their opinion | 17:19 |
*** EinstCrazy has joined #openstack-keystone | 17:19 | |
lbragstad | xek otherwise I'd value any operator feedback | 17:19 |
*** diazjf has quit IRC | 17:19 | |
xek | dstanek, bknudson, lbragstad, summing up, we are worried mainly about performance? | 17:20 |
lbragstad | xek i think we're worried about a bunch of things | 17:21 |
bknudson | I'm concerned about the performance and complicating the code which will lead to bugs and potential security vulnerabilities. | 17:21 |
*** navid_ has joined #openstack-keystone | 17:21 | |
xek | lbragstad, I also think that the DB would have to somehow know what code version is connecting to it | 17:21 |
dstanek | xek: i'm more worried about the added complication that is bound to break things | 17:21 |
dstanek | since we are supposed to be one the things that prevents unauthorized cloud use, I think we need to be careful | 17:22 |
lbragstad | xek dstanek new question | 17:22 |
lbragstad | do we really need a spec for adding a unit test? | 17:23 |
bknudson | we don't need a spec to add a unit test | 17:23 |
dstanek | lbragstad: this one maybe... since it will change the way we work | 17:23 |
*** btully has joined #openstack-keystone | 17:23 | |
lbragstad | I think we need a spec for online migrations, but I don't think this addresses online migrations | 17:23 |
dstanek | this isn't just verifying new behavior, but forcing a new development process | 17:23 |
lbragstad | so, maybe a blueprint so that we can track it | 17:23 |
lbragstad | ? | 17:24 |
dstanek | we also need to add the docs for this too | 17:24 |
lbragstad | agreed | 17:24 |
dstanek | what do i need when i need to change the schema | 17:24 |
lbragstad | essentially, the way in which we migrate schema versions wouldn't change | 17:24 |
lbragstad | but we would just add release notes for every migration | 17:25 |
dstanek | lbragstad: but doesn't the test force you to add expection when making a "breaking" change? | 17:25 |
*** EinstCrazy has quit IRC | 17:26 | |
*** belmoreira has quit IRC | 17:26 | |
bknudson | the docs need to be in the test case | 17:26 |
xek | maybe adding an exception would just require you to make a release note, that the upgrade requires downtime, with information on what data will be migrated (for the operator to know how much time it will take) | 17:27 |
xek | I think there may be some future releases which wouldn't do braking changes on the DB, and then the operator will know, that he doesn't have to stop his services | 17:28 |
odyssey4me | xek lbragstad it may be good to continue the thread here: http://lists.openstack.org/pipermail/openstack-operators/2015-November/009001.html | 17:29 |
*** dims has joined #openstack-keystone | 17:29 | |
dstanek | bknudson: you don't think that should be part of the developer docs? | 17:30 |
bknudson | developer docs would probably have more detail, but if it was with the testcase then you'd see the docs in the gerrit review. | 17:31 |
bknudson | maybe we need to have a review checklist in developer docs | 17:35 |
*** navid_ has quit IRC | 17:35 | |
*** ryansb has joined #openstack-keystone | 17:36 | |
lbragstad | odyssey4me i can respond with the new direction? | 17:38 |
odyssey4me | lbragstad sure, do it | 17:39 |
lbragstad | so, to summarize | 17:39 |
odyssey4me | it might be a good idea to reach out to some of the working groups too - for example the large scale deployments and enterprise working groups | 17:39 |
*** timcline has quit IRC | 17:40 | |
lbragstad | we will have a new unit test to detect certain migration that could incur downtime, which will require documentation/release notes | 17:40 |
*** lhcheng has quit IRC | 17:40 | |
lbragstad | then do we target online-migrations as a spec for N? | 17:41 |
lbragstad | once we have more feedback? | 17:41 |
xek | lbragstad, I think so, or maybe we could still discuss it at the midcycle? | 17:42 |
lbragstad | xek yeah, that would work. | 17:42 |
xek | although I can't promise I will be there | 17:42 |
lbragstad | xek I don't think it will be hard to get the spec in or marked complete | 17:42 |
lbragstad | xek the tricky part is allowing time for other things to implement what ever online-migration we go with | 17:42 |
lbragstad | all migrations in Mitaka would have to adhere to it | 17:43 |
dstanek | xek: i wonder if that guy that wrote about the different options actually did them... the option three that he described is deficient compared to what we had to do. it wasn't table at a time it was groups based on the relations | 17:44 |
lbragstad | dstanek where are you reading that? | 17:45 |
dstanek | lbragstad: https://signalvnoise.com/posts/3174-taking-the-pain-out-of-mysql-schema-changes | 17:46 |
dstanek | it's about migrations with no downtime | 17:46 |
*** NM has joined #openstack-keystone | 17:47 | |
xek | ok, thanks for all the feedback! I'm rolling myself home, see you tomorrow | 17:47 |
dstanek | xek: have a good one | 17:47 |
lbragstad | xek o/ | 17:47 |
dstanek | lbragstad: AGI would buy a company and want to migrate their systems into the existing ones. we had to do all sorts of crazy migrations to have both websites up during large migrations. | 17:48 |
lbragstad | i've used pt-online-schema-change before | 17:49 |
dstanek | lbragstad: think 10s or 100s of millions of customers and their data moving across data centers | 17:49 |
lbragstad | it's a neat tool | 17:49 |
lbragstad | and you guys did that with changes to the application | 17:50 |
lbragstad | and duplicate schemas, etc... | 17:50 |
dstanek | yes and yes | 17:50 |
dstanek | each was different because the source systems were different | 17:50 |
lbragstad | agreed, every migration is going to be handled differently | 17:51 |
dstanek | this should be a lot easier since it's in the sane logical DB, but i worry about making MySQL based assumptions if people are using PG | 17:52 |
dstanek | lbragstad: pt-online-schema-change looks interesting. i've never used it. | 17:55 |
dstanek | lbragstad: the foreign key issues it mentions are why we replicated groups of tables | 17:55 |
*** sigmavirus24 is now known as sigmavirus24_awa | 17:57 | |
*** jbell8 has quit IRC | 18:03 | |
*** mhickey has joined #openstack-keystone | 18:05 | |
*** btully has quit IRC | 18:06 | |
*** jbell8 has joined #openstack-keystone | 18:09 | |
notmorgan | dstanek: lets just drop support for PGSQL :P | 18:11 |
notmorgan | dstanek: much easier that way | 18:11 |
*** ninag has quit IRC | 18:11 | |
notmorgan | i mean... does anyone *really* use it? | 18:11 |
* notmorgan goes back to the corner | 18:12 | |
*** ninag has joined #openstack-keystone | 18:12 | |
dstanek | notmorgan: we can join the cool kids in mongo land.... | 18:12 |
notmorgan | dstanek: nope. | 18:12 |
notmorgan | dstanek: we can't cause nope nope nope nope nope | 18:12 |
*** harlowja has joined #openstack-keystone | 18:12 | |
dstanek | notmorgan: thanks dad, i was just trying to have some fun :-) | 18:13 |
*** ninag has quit IRC | 18:13 | |
*** e0ne has quit IRC | 18:13 | |
notmorgan | dstanek: mongo...is fun...?! | 18:13 |
*** ninag has joined #openstack-keystone | 18:13 | |
dstanek | notmorgan: yes, just like smashing your hand with a hammer! | 18:14 |
bknudson | I thought hpe had their own mongo driver | 18:15 |
*** ninag has quit IRC | 18:17 | |
*** ninag has joined #openstack-keystone | 18:17 | |
gyee | bknudson, yes we do | 18:17 |
gyee | and it works well | 18:18 |
gyee | what's wrong with mongo? | 18:18 |
bknudson | I used to think it was a bad idea but then I realized we got rid of all the foreign keys so there's no point to sql anymore. | 18:18 |
bknudson | gyee: does it make online upgrades easier? | 18:18 |
notmorgan | bknudson, gyee, the issue with mongo is two fold: 1) AGPL (lawyer'd!), 2) testing is ugly right now in OpenStack | 18:19 |
gyee | bknudson, yes | 18:19 |
gyee | notmorgan, valid points, | 18:19 |
gyee | 1) we can't do much | 18:19 |
notmorgan | 3) we have sucked at SQL quite a bit, adding in something that most developers know less about wont help | 18:19 |
gyee | mongo is easy! | 18:19 |
notmorgan | "it's webscale" | 18:20 |
gyee | if you know how to use a dict, you know mongo already | 18:20 |
notmorgan | gyee: *cough* that doesn't mean people wont design around mongo things that work that (similar to SQL) are terrible ideas | 18:20 |
gyee | I am not saying Mongo is better than SQL in all aspects | 18:21 |
notmorgan | at least SQL we have some level of folks who can look at it and go "uhhh. oh god why!?" i think we lack those folks in openstack for mongo | 18:21 |
notmorgan | mostly | 18:21 |
gyee | for rolling upgrade, yes | 18:21 |
*** ninag has quit IRC | 18:21 | |
gyee | but yeah, licensing is a killer | 18:21 |
notmorgan | among other things. | 18:21 |
*** ninag has joined #openstack-keystone | 18:22 | |
notmorgan | lack of solid knowledge of mongo and what is good vs "hey it doesn't break" | 18:22 |
notmorgan | makes it a harder sell | 18:22 |
notmorgan | esp. when *everything* else uses sql | 18:22 |
gyee | technically, you don't need much to use mongo | 18:22 |
notmorgan | if everything went mongo, this argument would go away quickly as people would ramp up | 18:22 |
notmorgan | gyee: that falls into the "well it works" category | 18:22 |
gyee | yeah, folks will have to weight the pros and cons | 18:23 |
notmorgan | but is that a good idea? is it going to fall over as we scale? does it make something in the backend of mongo unhappy in <case> | 18:23 |
notmorgan | so i don't think we can say "move to mongo" because of a few reasons, but the tech side is def an issue too | 18:23 |
gyee | for mid-scale, 2-3 site, mongo is fine | 18:23 |
gyee | anything large, you'll need to think federation | 18:24 |
notmorgan | gyee: you're countering my statements with "it just works" | 18:24 |
notmorgan | gyee: i disagree with that sentiment | 18:24 |
gyee | what does it mean "it just works"? :) | 18:24 |
notmorgan | we can't just throw it out there and tell people "yeah this is good" and wait for the fallout. we need slightly more reasoning going into the choices | 18:24 |
notmorgan | i'm saying we don't have the critical mass of knowledge of "good" vs "bad" practices developing against mongo | 18:25 |
notmorgan | you're saying "yeah but it's fine in small deployments" - those are two different things! | 18:25 |
gyee | well, open source is about choice, nothing is certain, use cases are different | 18:25 |
gyee | we can only provide data | 18:25 |
notmorgan | and we're not growing that skillset in openstack really | 18:25 |
notmorgan | so, i think a move ot mongo is generally unwise. | 18:26 |
notmorgan | upstream supported mongo* | 18:26 |
gyee | I am not advocating anything | 18:26 |
notmorgan | unless folks want to grow that skillset :) | 18:26 |
gyee | just sharing out experience | 18:26 |
notmorgan | which case, i'm happy to see more options. | 18:26 |
gyee | s/out/our/ | 18:26 |
notmorgan | [but i can also just ignore the storage backends most of the time, yay!] | 18:26 |
bknudson | we have customers complaining about wanting to do online upgrades and I don't think you can totally accomplish it using sql | 18:27 |
zao | If mysql is a problem, go postgres :D | 18:27 |
bknudson | unless you use blobs | 18:27 |
* zao looks for a winking smiley | 18:27 | |
*** rderose has quit IRC | 18:28 | |
bknudson | I mean the extra blobs are essentially nosql already | 18:28 |
gyee | extra is a hybrid blob :) | 18:31 |
*** ninag has quit IRC | 18:35 | |
*** ninag has joined #openstack-keystone | 18:35 | |
*** ninag has quit IRC | 18:38 | |
*** ninag has joined #openstack-keystone | 18:38 | |
*** mhickey has quit IRC | 18:41 | |
dstanek | gyee: designing a schema in mongo is more complicated than just using a dict | 18:43 |
dstanek | gyee: you still have to design for usage patterns and you have the added complexity of the working set (and memory mapping) | 18:44 |
gyee | and sharding | 18:44 |
gyee | dstanek, for the basic stuff, we don't need awhole lot | 18:46 |
dstanek | as long as the schema is designed correctly, that is true | 18:47 |
*** ayoung has joined #openstack-keystone | 18:47 | |
*** ChanServ sets mode: +v ayoung | 18:47 | |
dstanek | i'd worry if tokens were ever put in it, but with ephemeral tokens that's not a big issue | 18:49 |
*** fawadkhaliq has quit IRC | 18:49 | |
*** fawadkhaliq has joined #openstack-keystone | 18:49 | |
gyee | dstanek, I am still depressed from Monday Night Football | 18:51 |
gyee | saddest game in recent memory | 18:51 |
dstanek | gyee: yeah, i knew i should have left before the game started | 18:51 |
*** btully has joined #openstack-keystone | 18:52 | |
* gyee is looking forward to the next NFL draft already | 18:53 | |
*** gsilvis__ has quit IRC | 18:53 | |
*** fangxu has joined #openstack-keystone | 18:53 | |
*** aginwala has joined #openstack-keystone | 18:55 | |
*** jbell8 has quit IRC | 19:03 | |
*** lhcheng has joined #openstack-keystone | 19:04 | |
*** ChanServ sets mode: +v lhcheng | 19:04 | |
*** browne has joined #openstack-keystone | 19:04 | |
*** rderose has joined #openstack-keystone | 19:05 | |
*** btully has quit IRC | 19:07 | |
*** sigmavirus24_awa is now known as sigmavirus24 | 19:09 | |
*** lhcheng has quit IRC | 19:09 | |
*** btully has joined #openstack-keystone | 19:10 | |
lbragstad | bknudson dstanek for the release notes around schema changes - what all would you expect to be in those notes? | 19:14 |
lbragstad | 1.) what is changing 2.) why it's changing 3.) how to migrate data if any ... | 19:14 |
openstackgerrit | werner mendizabal proposed openstack/keystone-specs: Multifactor Authentication https://review.openstack.org/130376 | 19:18 |
*** aix has quit IRC | 19:20 | |
*** spandhe has joined #openstack-keystone | 19:21 | |
*** btully has quit IRC | 19:22 | |
*** pwp has joined #openstack-keystone | 19:23 | |
*** jasonsb has quit IRC | 19:24 | |
*** btully has joined #openstack-keystone | 19:24 | |
openstackgerrit | werner mendizabal proposed openstack/keystone-specs: Multifactor Authentication https://review.openstack.org/130376 | 19:24 |
*** mancdaz has quit IRC | 19:25 | |
*** mancdaz has joined #openstack-keystone | 19:26 | |
*** fawadkhaliq has quit IRC | 19:28 | |
*** fawadkhaliq has joined #openstack-keystone | 19:28 | |
*** jbell8 has joined #openstack-keystone | 19:29 | |
*** jbell8 has quit IRC | 19:30 | |
*** rderose has quit IRC | 19:31 | |
*** pwp has left #openstack-keystone | 19:32 | |
*** jbell8 has joined #openstack-keystone | 19:32 | |
*** briancurtin has quit IRC | 19:33 | |
*** serverascode has quit IRC | 19:33 | |
*** pwp has joined #openstack-keystone | 19:33 | |
*** jraim has quit IRC | 19:33 | |
*** zhiyan has quit IRC | 19:33 | |
*** tyagiprince1 has joined #openstack-keystone | 19:34 | |
*** tyagiprince has quit IRC | 19:35 | |
*** tyagiprince1 is now known as tyagiprince | 19:35 | |
*** btully has quit IRC | 19:37 | |
*** fangxu has quit IRC | 19:38 | |
*** RichardRaseley has joined #openstack-keystone | 19:40 | |
*** btully has joined #openstack-keystone | 19:41 | |
*** flwang has joined #openstack-keystone | 19:41 | |
*** ayoung has quit IRC | 19:41 | |
*** browne has quit IRC | 19:44 | |
*** browne has joined #openstack-keystone | 19:45 | |
*** aginwala has quit IRC | 19:45 | |
*** pumaranikar has joined #openstack-keystone | 19:46 | |
ryansb | hi, I'm having a problem that seems to be coming from keystonemiddleware -- is this the right channel or is there a separate one for mw? | 19:47 |
*** aginwala has joined #openstack-keystone | 19:48 | |
*** DuncanT has quit IRC | 19:54 | |
*** woodster_ has quit IRC | 19:54 | |
*** ramishra has quit IRC | 19:54 | |
*** markvoelker has quit IRC | 19:55 | |
bknudson | lbragstad: if the deployer wants to know how long their system is down then we should say that. | 19:56 |
ctina | +1 | 19:56 |
*** gsilvis has joined #openstack-keystone | 19:57 | |
lbragstad | bknudson that would be dependent on how much data they have, | 19:58 |
lbragstad | bknudson which we don't necessarily know | 19:58 |
bknudson | right, so tell them what it depends on | 19:58 |
*** markvoelker has joined #openstack-keystone | 19:59 | |
lbragstad | bknudson so, for example "in order to do this migration all entries from x table.row need to be converted to `something`". | 19:59 |
bknudson | lbragstad: we can just say that the downtime depends on the number of users or whatever it is. | 20:00 |
lbragstad | ok | 20:00 |
*** diazjf has joined #openstack-keystone | 20:01 | |
flwang | stevemar: ping | 20:02 |
stevemar | flwang: pong | 20:02 |
flwang | stevemar: could you please have a quick look for this http://logs.openstack.org/25/250125/4/check/gate-zaqarclient-dsvm-functional/1125b36/console.html | 20:02 |
flwang | we're using osc-config to get the credentials but the auth_url is 'auth_url': 'http://127.0.0.1:35357' | 20:03 |
flwang | i suppose it should be like http://127.0.0.1:5000/2.0 | 20:03 |
*** jasonsb has joined #openstack-keystone | 20:04 | |
bknudson | it's doing http://127.0.0.1:35357/tokens which doesn't exist, it needs to be http://127.0.0.1:35357/v2.0/tokens | 20:04 |
*** jraim has joined #openstack-keystone | 20:04 | |
stevemar | flwang: sort of, keystone should be able to discover the versions though | 20:04 |
flwang | bknudson: yep, i see | 20:04 |
bknudson | for some reason it's doing v2 auth. | 20:04 |
flwang | stevemar: since you're also a osc guy, so it's the special question for you :D | 20:05 |
stevemar | which is weird since it's specifying both user_domain_id and project_domain_id | 20:05 |
flwang | stevemar: so, anything we should investigate continually? | 20:09 |
*** lhcheng has joined #openstack-keystone | 20:10 | |
*** ChanServ sets mode: +v lhcheng | 20:10 | |
stevemar | flwang: not sure yet! :) | 20:10 |
*** jasonsb has quit IRC | 20:10 | |
stevemar | flwang: looking at how the tests are set up now | 20:10 |
flwang | stevemar: https://review.openstack.org/#/c/250125/4/zaqarclient/tests/base.py | 20:11 |
*** aginwala has quit IRC | 20:11 | |
*** mhickey has joined #openstack-keystone | 20:12 | |
flwang | stevemar: thanks for the hlep | 20:15 |
stevemar | flwang: that makes it easier :) | 20:15 |
stevemar | oh that's a nice idea, using the defined name 'devstack-admin' | 20:15 |
* stevemar will steal that idea for osc functional tests | 20:16 | |
*** serverascode has joined #openstack-keystone | 20:16 | |
flwang | stevemar: is there any change in osc or the keystone related lib? | 20:16 |
flwang | stevemar: you can't steal, mordred has a patent for that | 20:17 |
stevemar | flwang: haha | 20:17 |
stevemar | flwang: i don't think there are any changes that would have affected this | 20:17 |
stevemar | i saw another bug about someone sourcing the devstack rc file and it didn't have a version attached | 20:18 |
flwang | stevemar: ok | 20:18 |
*** zhiyan has joined #openstack-keystone | 20:19 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 20:20 | |
mordred | stevemar: PLEASE DO use that | 20:20 |
mordred | stevemar: there is even an oslotest base class which does the work | 20:20 |
stevemar | mordred: i hear you'll send patent trolls to get me if i do | 20:21 |
*** lhcheng_ has joined #openstack-keystone | 20:21 | |
mordred | if anyone uses anything other than clouds.yaml for functional test auth, I swear I will kill them with knives | 20:21 |
lbragstad | stevemar do we need a version bump of pycadf? | 20:21 |
stevemar | lbragstad: we did, a new version was released about an hour ago | 20:22 |
stevemar | feel free to recheck everything | 20:22 |
stevemar | i just ran a recheck and it's passing gate again | 20:22 |
stevemar | i have a patch to requirements to bump the upper constraints on all keystone libraries, and to block pycadf 2.0.0 | 20:23 |
stevemar | mordred: does occ use version discovery? | 20:24 |
*** lhcheng has quit IRC | 20:24 | |
mordred | stevemar: occ uses what's configured - I _believe_ that the version discovery URL is being written into the clouds.yaml by devstack | 20:26 |
flwang | mordred: any comments for this http://logs.openstack.org/25/250125/4/check/gate-zaqarclient-dsvm-functional/1125b36/console.html | 20:26 |
stevemar | mordred: that's what i'm trying to check | 20:26 |
mordred | stevemar: and I believe it points to v3 by default - we have an extra devstack test for shade that edits the clouds.yaml to force it to version v2 so that we can test that | 20:26 |
stevemar | mordred: so flwang is sourcing devstack-admin for occ, but when he's running tests, it 404's (missing the v2.0 in auth_url | 20:27 |
mordred | stevemar: http://git.openstack.org/cgit/openstack-infra/shade/tree/shade/tests/functional/hooks/post_test_hook.sh#n25 | 20:27 |
*** briancurtin has joined #openstack-keystone | 20:27 | |
mordred | stevemar: yes. it should be missing the v2.0 in the auth_url | 20:28 |
mordred | becuase the auth_url in clouds.yaml is the version discovery url | 20:28 |
mordred | becuase that's what devstack defaults to | 20:28 |
*** btully has quit IRC | 20:28 | |
stevemar | mordred: so i guess OSC may not be handling auth_url properly? | 20:29 |
flwang | mordred: but it's called 'auth_url' | 20:29 |
mordred | yes | 20:29 |
mordred | auth_url is unversioned in devstack | 20:29 |
flwang | mordred: +1 | 20:29 |
mordred | because it' points to the version discovery url | 20:29 |
mordred | stevemar: it should be - we use occ to test osc too | 20:29 |
stevemar | hmph | 20:30 |
*** rderose has joined #openstack-keystone | 20:30 | |
mordred | stevemar: I have to run - just know that what is put into clouds.yaml by devstack does work correctly for v2 and v3 of keystone (we test this with every shade patch) | 20:30 |
stevemar | mordred: run run, i'll mull it over | 20:30 |
mordred | if you don't have whatever is wrong with zaqar figured out before I get back, I'll dive in and help fix it | 20:30 |
stevemar | cool :) | 20:31 |
*** btully has joined #openstack-keystone | 20:32 | |
lbragstad | stevemar fyi - https://review.openstack.org/#/c/130376/ | 20:32 |
lbragstad | stevemar that came in late | 20:33 |
flwang | mordred: thanks | 20:33 |
stevemar | lbragstad: yeah i saw movement on it this morning | 20:34 |
*** henrynash has joined #openstack-keystone | 20:34 | |
*** ChanServ sets mode: +v henrynash | 20:34 | |
stevemar | notmorgan: can you lift your -2 on https://review.openstack.org/#/c/130376/ ? | 20:34 |
*** aginwala has joined #openstack-keystone | 20:38 | |
*** woodster_ has joined #openstack-keystone | 20:38 | |
flwang | stevemar: so should i expect this is a fix from osc-config? | 20:38 |
stevemar | flwang: honestly, i'm not sure yet | 20:38 |
flwang | stevemar: otherwise, i may have to hardcode the version for now since it's breaking our gate | 20:38 |
stevemar | flwang: i think that is OK to do for now | 20:39 |
stevemar | flwang: it's just the functional job right? it's non-voting i thought? | 20:39 |
flwang | stevemar: ok, thanks. I will hardcode it for now, and when there is a fix, pls add me as a reviewer | 20:39 |
flwang | stevemar: it's not voting for client, but it's voting for zaqar server :( | 20:39 |
flwang | now we're seeing differents errors, but i hope the server side issue can be fixed as well | 20:40 |
stevemar | flwang: let me try to reproduce it locally | 20:42 |
flwang | stevemar: ok, cool | 20:43 |
*** btully has quit IRC | 20:46 | |
*** henrynash has quit IRC | 20:46 | |
*** ramishra has joined #openstack-keystone | 20:48 | |
*** DuncanT has joined #openstack-keystone | 20:48 | |
samueldmq | /q stevemar | 20:48 |
samueldmq | oops | 20:48 |
stevemar | :P | 20:48 |
samueldmq | :) | 20:49 |
gordc | stevemar: why does keystonemiddleware tell me auth-url is required now. | 20:49 |
*** fawadkhaliq has quit IRC | 20:49 | |
stevemar | gordc: we're using keystoneauth1 now | 20:50 |
gordc | stevemar: if i don't want to bother setting a auth-url, how can i do that? i'm not sure what exactly is pulling in keystoneauth1 right nwo | 20:51 |
gordc | but my tests are b*tching that i haven't setup auth-url | 20:51 |
*** alex_xu_ has quit IRC | 20:52 | |
*** alex_xu has joined #openstack-keystone | 20:53 | |
*** EinstCrazy has joined #openstack-keystone | 20:56 | |
*** RichardRaseley has quit IRC | 20:57 | |
*** raildo is now known as raildo-afk | 20:58 | |
bknudson | gordc: in a related note, ksm has a test fixture now. | 21:00 |
*** EinstCrazy has quit IRC | 21:00 | |
bknudson | we should probably revert the change since it's obviously not backwards-compatible. | 21:01 |
gordc | bknudson: which change? | 21:03 |
*** sigmavirus24_awa is now known as sigmavirus24 | 21:03 | |
bknudson | gordc: https://review.openstack.org/#/c/235090/ | 21:03 |
bknudson | unless that wasn't the commit that changed the behavior | 21:04 |
*** EinstCrazy has joined #openstack-keystone | 21:06 | |
gordc | bknudson: not sure. i'm not sure keystonemiddleware should be even loading in our tests so i think it just exposed a conf leak somewhere in our code | 21:07 |
*** henrynash has joined #openstack-keystone | 21:08 | |
*** ChanServ sets mode: +v henrynash | 21:08 | |
*** aginwala has quit IRC | 21:08 | |
*** btully has joined #openstack-keystone | 21:09 | |
*** aginwala has joined #openstack-keystone | 21:12 | |
*** EinstCrazy has quit IRC | 21:12 | |
*** lhcheng_ has quit IRC | 21:13 | |
*** lhcheng has joined #openstack-keystone | 21:13 | |
*** ChanServ sets mode: +v lhcheng | 21:13 | |
*** pauloewerton has quit IRC | 21:14 | |
*** diazjf1 has joined #openstack-keystone | 21:15 | |
*** diazjf has quit IRC | 21:17 | |
*** lhcheng has quit IRC | 21:18 | |
*** btully has quit IRC | 21:22 | |
lbragstad | notmorgan would you be able to lift your -2 here https://review.openstack.org/#/c/130376/ ? Or are we going to keep it since we have already voted on Mitaka specs? | 21:29 |
*** diazjf1 has quit IRC | 21:31 | |
*** navid_ has joined #openstack-keystone | 21:31 | |
*** tyagiprince has quit IRC | 21:32 | |
*** btully has joined #openstack-keystone | 21:36 | |
gordc | bknudson: is keystonemiddleware 4.x suppose to work in liberty too? | 21:37 |
*** lhcheng has joined #openstack-keystone | 21:37 | |
*** ChanServ sets mode: +v lhcheng | 21:37 | |
bknudson | gordc: yes! | 21:37 |
bknudson | I don't see why not. | 21:37 |
stevemar | gordc: yes.... | 21:37 |
bknudson | the only thing we were supposed to remove is py26 support | 21:37 |
stevemar | we just changed it from 3->4 cause of py26 | 21:38 |
gordc | i see... | 21:38 |
gordc | i hate debugging broken gate when it runs fine locally | 21:38 |
*** dolphm is now known as dolphm_418 | 21:38 | |
*** fangxu has joined #openstack-keystone | 21:40 | |
stevemar | is there something better than clean.sh for devstack? | 21:43 |
stevemar | i keep running into errors apparently | 21:43 |
stevemar | (when stacking) | 21:43 |
stevemar | is there a "nuke it" option | 21:43 |
gordc | "rm -rf /" | 21:45 |
sigmavirus24 | stevemar: delete everything, make a new VM? | 21:45 |
*** ctina_ has joined #openstack-keystone | 21:45 | |
stevemar | sigmavirus24: i'm one attempt away from doing that | 21:46 |
*** btully has quit IRC | 21:48 | |
*** ctina has quit IRC | 21:49 | |
henrynash | gyee: hi | 21:50 |
*** ctina_ has quit IRC | 21:50 | |
henrynash | notmorgan: ping | 21:51 |
lbragstad | stevemar what issues are you having? | 21:58 |
stevemar | lbragstad: something about unavailable plugins when the command `openstack image create --os-config=devstack-admin` | 22:00 |
stevemar | something like this: https://github.com/openstack-dev/devstack/blob/f95c9a960322df3cce1f4d98430f86a9654fc632/functions#L73 | 22:00 |
lbragstad | stevemar did you update your project repositories? | 22:01 |
stevemar | lbragstad: i removed all cloned projects | 22:01 |
stevemar | and ran clean.sh | 22:01 |
lbragstad | ah | 22:01 |
* lbragstad hands stevemar a bigger hammer | 22:02 | |
*** NM has quit IRC | 22:02 | |
*** mhickey has quit IRC | 22:03 | |
stevemar | lbragstad: thank you sir | 22:03 |
lbragstad | :) | 22:04 |
dstanek | stevemar: i periodically run into issues that force me to create a new VM | 22:05 |
dstanek | i do so many experiments that it's likely my fault | 22:05 |
*** petertr7 is now known as petertr7_away | 22:06 | |
stevemar | dstanek: possiprobably | 22:06 |
*** thiagop has quit IRC | 22:06 | |
*** NM has joined #openstack-keystone | 22:06 | |
*** ninag has quit IRC | 22:07 | |
*** aginwala has quit IRC | 22:08 | |
*** ninag has joined #openstack-keystone | 22:08 | |
*** ninag_ has joined #openstack-keystone | 22:12 | |
*** ninag has quit IRC | 22:13 | |
*** ninag_ has quit IRC | 22:16 | |
gyee | henrynash, back | 22:17 |
gyee | henrynash, for implied roles, both prior and impled roles goes into the token | 22:17 |
*** henrynash has quit IRC | 22:26 | |
*** aginwala has joined #openstack-keystone | 22:29 | |
*** mancdaz has quit IRC | 22:30 | |
*** mancdaz has joined #openstack-keystone | 22:31 | |
*** richm has quit IRC | 22:32 | |
*** navid_ has quit IRC | 22:32 | |
*** navid_ has joined #openstack-keystone | 22:33 | |
*** ninag has joined #openstack-keystone | 22:39 | |
*** edmondsw has quit IRC | 22:41 | |
*** adelia has quit IRC | 22:41 | |
*** ninag has quit IRC | 22:44 | |
*** btully has joined #openstack-keystone | 22:46 | |
*** rderose has quit IRC | 22:51 | |
*** rderose has joined #openstack-keystone | 22:51 | |
*** rderose has quit IRC | 22:51 | |
*** rderose has joined #openstack-keystone | 22:51 | |
*** henrynash has joined #openstack-keystone | 22:52 | |
*** ChanServ sets mode: +v henrynash | 22:52 | |
henrynash | gyee: hi | 22:52 |
*** navid_ has quit IRC | 22:55 | |
*** rderose has quit IRC | 22:57 | |
*** RichardRaseley has joined #openstack-keystone | 22:57 | |
henrynash | notmorgan: ping | 22:57 |
gyee | henrynash, yes sir | 22:59 |
gyee | henrynash, your option #1 make a lot of sense | 22:59 |
henrynash | gyee: hi….ok…so wanted to try and get us to some lind of agreement here…. | 22:59 |
henrynash | gyee: but you can’t jsut do 1), you have to do 2) and 3) as well | 23:00 |
gyee | henrynash, I am not worry too much about internal code | 23:00 |
henrynash | gyee: that’s a lot of API work..and in manke case dulaiction of APIs | 23:00 |
gyee | its the API that we need to get it right, since they are contracts | 23:00 |
henrynash | gyee: and ia just don’t se teh UX problem | 23:00 |
henrynash | gyee: i simply do not see the confusion | 23:01 |
notmorgan | henrynash: huh? sortof here | 23:01 |
notmorgan | henrynash: but only very sortof. my brain is hurting cause i'm staring at neutron | 23:01 |
henrynash | notmorgan: ok, sorry….want to talk unicode, but currently depatingdomain specific role with gyee! | 23:01 |
notmorgan | oh | 23:01 |
notmorgan | i can do that | 23:01 |
henrynash | gyee: a domain specific role (i.e. one that was created with a domain id) never goes in a token | 23:02 |
notmorgan | here is my vote on domain specific roles: Something something, idea something something, mush, something something, as long as we don | 23:02 |
notmorgan | t blow out the token size, i don't care how roles end up in the token | 23:02 |
notmorgan | but i worry that this is a "nice to have" vs a "super important feature" | 23:02 |
gyee | notmorgn, not that, its UX | 23:03 |
notmorgan | like "oh we'd totally use it...." and then people don't | 23:03 |
henrynash | notmorgan: cwe haev real customer who want this | 23:03 |
notmorgan | UX can be worked through | 23:03 |
notmorgan | henrynash: riht and i had real customers wanting it at metacloud too | 23:03 |
gyee | right now, the kinda weird to explain the difference to people | 23:03 |
henrynash | gyee: a domain role never goes in a token. Full stop | 23:03 |
gyee | correct | 23:04 |
henrynash | gyee: a domain role is a handle to imply a set of roel that do go in a token | 23:04 |
gyee | implied roles does | 23:04 |
notmorgan | wait implied role goes in the token? | 23:04 |
gyee | henrynash, have to tried to explain that to the doc people? :) | 23:04 |
notmorgan | no. afaik the implied role explodes out to the full list? | 23:04 |
henrynash | gyee: implied roles always go in the token | 23:04 |
gyee | notmorgan, nope, both prior and implied roles goes into the token | 23:05 |
notmorgan | [domain role "foo"] = ["role X"] = ["role y,z,q,r,t"] ? | 23:05 |
notmorgan | right? | 23:05 |
henrynash | notmorgan: in the “implied roles spec”, you have a prior role and those roels taht proor role implies | 23:05 |
*** btully has quit IRC | 23:05 | |
notmorgan | and the last one is in the token | 23:05 |
gyee | all of them | 23:05 |
notmorgan | uh. | 23:05 |
gyee | henrynash, see my last review comment | 23:05 |
*** fangxu has quit IRC | 23:05 | |
gyee | I quoted that paragraph from the spec | 23:05 |
notmorgan | uh if "X" and "yzrqt" are in [in my example] i think it might be bad | 23:05 |
henrynash | but in a domain specifc role, then the prior role does NOT go in the token | 23:06 |
notmorgan | but the "foo" role wouldn't be in. | 23:06 |
gyee | henrynash, yes, hence the confusion | 23:06 |
notmorgan | so, henrynash what is the customer asking for | 23:06 |
gyee | there's fundamental difference between the two | 23:06 |
notmorgan | like functionality wise | 23:06 |
notmorgan | what is their intent for this? | 23:06 |
henrynash | gyee: I don’t see the confusion at all…since the role definition states it is a domain specifc role…and they, by defiention, don’t go i tokens | 23:06 |
notmorgan | i think that will help us understand why it is needed | 23:06 |
henrynash | christ, the spec says it very clearly | 23:07 |
notmorgan | because right now it feels like abstraction for the sake of abstraction at the end user level | 23:07 |
gyee | henrynash, I am not worry about that part | 23:07 |
gyee | I am worry about overloading the assignment part | 23:07 |
henrynash | very very clearly | 23:07 |
gyee | assignment API | 23:07 |
notmorgan | henrynash: i'm sorry i just jumped into the convo and haven't read the spec recently | 23:07 |
notmorgan | sorry | 23:07 |
henrynash | gyee; what’s teh worry there | 23:07 |
gyee | notmorgan, you are on the hook now :) | 23:07 |
gyee | henrynash, the worry is using the same API on two different set of resources result in different outcomes | 23:08 |
openstackgerrit | Brad Topol proposed openstack/keystone: Deprecate ldap Role https://review.openstack.org/252669 | 23:08 |
notmorgan | henrynash: no, i'm sorry the spec does not spell out the reason a customer wants this or what they are trying to accomplish. it is spelling out just waht the role is. | 23:08 |
henrynash | all we are doing is allowing a domain admin to create handle taht is meaningful to them that can imply a set of roels that were created by a cloud provider who has to define a set of generaic roels since tehy want to saisfy many types of customers | 23:08 |
notmorgan | is this another level of role grouping? | 23:09 |
notmorgan | is that really the intent? | 23:09 |
*** EinstCrazy has joined #openstack-keystone | 23:09 | |
henrynash | domain specif roel groupoing, yes | 23:09 |
notmorgan | ok | 23:09 |
gyee | notmorgan, yes, they are essentially role groups | 23:09 |
gyee | they are not implied roles, at least by definition | 23:09 |
henrynash | which is what I called hem in the first version of tehspec…and everyone barfed | 23:09 |
notmorgan | i feel this is a weird abstraction to add. | 23:09 |
notmorgan | but not opposed to it | 23:09 |
henrynash | gyee: that’s sematics…I call implied roels roel groups as well | 23:09 |
notmorgan | and i would move it back to domain-role-grouping | 23:10 |
gyee | implied roles are not role groups | 23:10 |
notmorgan | or something [wont hold it up on naming though] | 23:10 |
henrynash | gyee: why not | 23:10 |
gyee | henrynash, because they got expended into token response, as roles | 23:10 |
henrynash | so do domain specifc role groups | 23:11 |
gyee | so in the token response, can you tell from the roles list whether the giving "role" is role group or implied role? | 23:11 |
notmorgan | henrynash: i would describe them that way, regardless of the name :) | 23:11 |
henrynash | no | 23:11 |
notmorgan | henrynash: like i said i wouldn't hold this up on a naming concern atm. | 23:11 |
henrynash | (taht was to gyee) | 23:11 |
notmorgan | ah ok | 23:11 |
gyee | if you can't tell, the they are roles | 23:11 |
henrynash | sorry :-) | 23:11 |
henrynash | tehy are all roles! | 23:11 |
gyee | nope, not role groups | 23:11 |
gyee | they don't get to be part of the token | 23:12 |
gyee | big difference | 23:12 |
notmorgan | so for a public cloud perspective - i don't care about domain admins defining their own groups | 23:12 |
henrynash | the name of teh groiup diesn’t go in the token | 23:12 |
*** sigmavirus24 is now known as sigmavirus24_awa | 23:12 | |
henrynash | so in our public cloud d=custoemr absolutely wnat to do that | 23:12 |
notmorgan | from a private cloud perspective i would say it is *likely* someone could ask for a new implied-role-grouping that doesn't need to be domain specific | 23:12 |
gyee | role groups != roles | 23:12 |
gyee | implied roles = roles | 23:13 |
*** topol has quit IRC | 23:13 | |
gyee | there :) | 23:13 |
*** pumaranikar has quit IRC | 23:13 | |
henrynash | the contest of both are roles | 23:13 |
henrynash | contents, sorry | 23:13 |
*** EinstCrazy has quit IRC | 23:13 | |
henrynash | ok, so we’re not going to agree. | 23:13 |
henrynash | I just don’t see the UX confusion at all | 23:14 |
gyee | call them roles will cause confusions | 23:14 |
*** gordc has quit IRC | 23:14 | |
notmorgan | so henrynash, down at an implementation detail, | 23:15 |
henrynash | ok | 23:15 |
notmorgan | the grant in the DB ends up before for the domain-specific-role? | 23:15 |
notmorgan | or the underlying roles? | 23:15 |
notmorgan | just so i can understand your view on how opaque this is | 23:15 |
notmorgan | [i wont hold you to this answer if you change it down the line] | 23:15 |
*** btully has joined #openstack-keystone | 23:15 | |
henrynash | in the assignment table, the grant has a domain specific role ( i.e. teh ID of a role created with a domain_id as an attribute) | 23:16 |
notmorgan | ok | 23:16 |
notmorgan | hm. | 23:16 |
notmorgan | and when you ask what roles the user has on project, do you get the domain-specific-role or the complete exploded list? | 23:16 |
notmorgan | or both items? | 23:17 |
henrynash | so it works like groups and inheritance | 23:17 |
gyee | see, see, groups :) | 23:17 |
notmorgan | gyee: hold on | 23:17 |
henrynash | if you use teh GRANT APIs, then you see teh physical assignemnts | 23:17 |
notmorgan | physical assignment is the domain-specific-grant? | 23:18 |
notmorgan | or the exploded list? | 23:18 |
henrynash | if you use list_assignments in effective mode, then like groups and inheriatnce (and implied roels) these get exapnded out so you see teheffective roles | 23:18 |
notmorgan | hm. | 23:18 |
henrynash | this is how we do ingerited roels and group assinements today | 23:18 |
notmorgan | i worry this is going to make it harder to determine how a user has role X | 23:18 |
notmorgan | but i am not able to specifically say it will | 23:19 |
henrynash | teh list assigment respose, tells you the assignment that lef to a use haveing this role (e.g. inheritance, group, implied. etc.) | 23:19 |
notmorgan | yeah the inhertiance one is easy | 23:19 |
henrynash | it provides a link to the url that was teh grant | 23:19 |
notmorgan | but... the domain-specific one is a bit opaque | 23:20 |
notmorgan | dolphm_418: you are not a teapot | 23:20 |
gyee | one option would be to make domain-specific roles also implied roles | 23:20 |
henrynash | err, inheritance ain’t that eash (e.g. a user could have got a role on a project form a group grant on teh parent domain)…actualy teh common case in federation | 23:20 |
notmorgan | henrynash: but it is a known role | 23:21 |
notmorgan | vs a role that confers some set of roles | 23:21 |
*** lhcheng has quit IRC | 23:21 | |
notmorgan | but again, i can't definitely say it will be an issue | 23:21 |
notmorgan | so, i don't see this as a huge value add. | 23:22 |
henrynash | well, there are all know roles….but yes, in erither of the solutions being proposed, the url that caused the user to get the actual role would refernce some other handke (a role-group or a domain-specific-role) | 23:22 |
notmorgan | but as long as we can provide transparency on these new role constructs i am not opposed | 23:22 |
notmorgan | i also am not opposed to it being a top-level implied role, just owned at the domain level | 23:22 |
henrynash | i thnnk we HAVE to be able to do that | 23:22 |
notmorgan | so the UX is identical | 23:23 |
*** pwp has quit IRC | 23:23 | |
notmorgan | so here is my take: i think this is a very, very, very narrow use-case and not a value add | 23:24 |
henrynash | my proposal is really that…the top level role is domain specific, which implies a set of glocal roles (i.e. ones that turn up i policy files) | 23:24 |
notmorgan | it will be used in the minority of minority of deployments at best | 23:24 |
notmorgan | i think it makes things harder to follow unless we are very careful how we represent it | 23:24 |
notmorgan | i don't have a strong read on how important this is going to be for the environments that want it | 23:24 |
notmorgan | i'm not strongly opposed to it. | 23:25 |
notmorgan | i also am slightly more opposed than for it. | 23:25 |
henrynash | ok, apprecaite the candor | 23:25 |
henrynash | wnat to swicth to unicode and url safe names? | 23:25 |
notmorgan | i would encourage this to be, if anything, a domain-specific reporesentation of the implied roles (with all the pitfalls that come with that) | 23:25 |
henrynash | soemthing dear to your heart, I know | 23:25 |
notmorgan | so the UX is the same if it is added | 23:25 |
henrynash | (on doman roles….that is exactly teh proposal) | 23:26 |
notmorgan | that way it's the same code-paths, same representations, etc, but allowing the domain to control it. | 23:26 |
notmorgan | and if the grouping at the global implied role appears in the token, the domain one would too | 23:26 |
notmorgan | i do mean identical ux | 23:26 |
gyee | notmorgan, don't think they are the same | 23:26 |
henrynash | ahh, hmm no we cant do that | 23:27 |
notmorgan | gyee: i'm saying if we do this, it should be the same | 23:27 |
notmorgan | henrynash: force a prefix on them. OS_DOMAIN_ROLE:<rolename> | 23:27 |
gyee | notmorgan, how can that be? 1) domain-specific roles don't get included in the token, and 2) they can't be nested | 23:27 |
notmorgan | henrynash: but i would say it should be *the* same mechanism | 23:27 |
henrynash | so domain A has specific role called “developer” and so does domain B…but the imply differnet roles | 23:27 |
notmorgan | henrynash: namespace it w/ the domain ;) | 23:28 |
openstackgerrit | Merged openstack/keystone: Add release notes for mitaka-1 https://review.openstack.org/249523 | 23:28 |
gyee | if we are using the same API to infer roles, they will return different results | 23:28 |
notmorgan | use the domain_id. *shrug* | 23:28 |
notmorgan | anyway | 23:28 |
notmorgan | i'm done, i've added my $0.0000002 | 23:28 |
notmorgan | ;) | 23:28 |
henrynash | I was only pinging you to talk about unicode…not this! | 23:29 |
notmorgan | yah | 23:29 |
notmorgan | wellllllll | 23:29 |
notmorgan | hah | 23:29 |
notmorgan | you got more than you bargained for | 23:29 |
flaper87 | stevemar: hey, thanks for the review here: https://review.openstack.org/#/c/241986/ | 23:29 |
flaper87 | if you have a chance, it'd be great to have your vote on the latest PS | 23:29 |
flaper87 | stevemar: ^ | 23:29 |
henrynash | so ho would a current customer you named their porjects in unicode handle urls today? | 23:29 |
notmorgan | flaper87: hey could use you to put pressure on nova to help make it so glance can live at a sub-url | 23:29 |
notmorgan | flaper87: if you don't mind ;) | 23:29 |
henrynash | how would they do : GET /projects?name=myrpojectname | 23:30 |
notmorgan | flaper87: the current answer is "make nova use the catalog", unfortunately that is not a small change. but also as an FYI just letting you know glance cannot live at like http://<api>/image/<glance url> | 23:30 |
notmorgan | flaper87: because nova explictly assumes / | 23:30 |
flaper87 | notmorgan: putting pressure? on nova? to benefit keystone and glance? I'm in | 23:31 |
notmorgan | flaper87: hehe | 23:31 |
notmorgan | flaper87: or at least helping nova fix this | 23:31 |
notmorgan | flaper87: here was my first pass but see sdague's response (which is fair) | 23:31 |
notmorgan | flaper87: https://review.openstack.org/#/c/251138/ | 23:31 |
dolphm_418 | notmorgan: when i get all steamed up, i just shout | 23:31 |
flaper87 | notmorgan: jokes apart, what do you mean exactly ? | 23:31 |
flaper87 | :d | 23:31 |
flaper87 | :D | 23:31 |
notmorgan | flaper87: nova cannot use glance if glance is mounted as a sub-url of a host | 23:32 |
notmorgan | it must exist at / | 23:32 |
notmorgan | nova has no capability to handle /<string>/<glance_urls> | 23:32 |
henrynash | notmorgan: I do, honestly, want to understand how customer are using unicode nmed projects and domains oday | 23:32 |
notmorgan | flaper87: because they explictly configure HOST and PORT or do url_parse and drop the path | 23:32 |
notmorgan | henrynash: easily, projects only ever get references in APIs via id | 23:33 |
flaper87 | notmorgan: ah-ha! gotcha. Lemme look at it. FWIW, we're doing quite some work on the nova.images code to allow it for using glance v2. Probably, making this change in Mitaka is going to be hard but let me take a look and chime in if needed | 23:33 |
notmorgan | henrynash: names are really only used for "viewing" | 23:33 |
henrynash | notmorgan: so how would they do: GET /projects?name=myrpojectname | 23:33 |
stevemar | flaper87: oh that one, i'll get back to that once mitaka-1 closes up | 23:33 |
notmorgan | flaper87: make it use the service catalog to lookup glance instead ;) | 23:33 |
notmorgan | flaper87: that would be even better. | 23:33 |
notmorgan | flaper87: but seriously, url-paths are important so glance can be sub-url mounted | 23:34 |
stevemar | flaper87: i won't be reviewing stuff until monday :( | 23:34 |
flaper87 | notmorgan: yep, making it use the service catalog is right after this v1 -> v2 work | 23:34 |
notmorgan | flaper87: it's important for a PoC i'm doing to try and solve some auth-woes | 23:34 |
stevemar | bha, lemme take a quick look | 23:34 |
stevemar | i'm so easily distracted | 23:34 |
flaper87 | stevemar: wuuuut? WHY? :( | 23:34 |
flaper87 | stevemar: still like you, don't worry | 23:34 |
flaper87 | :D | 23:34 |
stevemar | flaper87: vacation tomorrow til sunday :D | 23:34 |
henrynash | notmorgan: so sorry to bug, but to my question, how would they do: GET /projects?name=mypojectname | 23:35 |
*** dulek has quit IRC | 23:36 | |
notmorgan | henrynash: unicode/utf-8 can be encoded in the URL | 23:37 |
notmorgan | and query string | 23:37 |
notmorgan | i am opposed to explicitly locking that out | 23:37 |
notmorgan | as was described | 23:37 |
*** aginwala has quit IRC | 23:37 | |
flaper87 | stevemar: oh, in that case, do not load gerrit! I repeat, do not load gerrit | 23:37 |
henrynash | ok, so origionally the spec said “you cane’t have the reserved characters” in the name | 23:37 |
henrynash | but peopel wanted more clarity | 23:38 |
henrynash | so I assume you would be OK with it as it was? | 23:38 |
*** btully has quit IRC | 23:38 | |
*** dulek has joined #openstack-keystone | 23:39 | |
*** aginwala has joined #openstack-keystone | 23:40 | |
*** fangxu has joined #openstack-keystone | 23:41 | |
henrynash | notmorgan: so (i think) you would be Ok with the wording I had in the previous version of the proposal that said “the name cannot contain any of the reserved charcters as described in section 2.2 of http://tools.ietf.org/html/rfc3986 ” ? | 23:42 |
notmorgan | henrynash: yes. | 23:43 |
notmorgan | henrynash: unless they are encoded appropriately if possible | 23:43 |
notmorgan | and we need to decode appropriately | 23:43 |
notmorgan | that was my dissent in the spec | 23:43 |
flaper87 | jamielennox: you also reviewed this once. It'd be awesome to get your feedback as well before we merge it: https://review.openstack.org/#/c/241986/ | 23:44 |
henrynash | notmorgan: ok, let me circuel back to whoever didn’t like that stateemtn before! | 23:44 |
henrynash | notmorgan: always aiming for less dissnet! | 23:44 |
henrynash | dissent, even | 23:44 |
henrynash | thx | 23:44 |
*** henrynash has quit IRC | 23:45 | |
*** slberger has left #openstack-keystone | 23:47 | |
*** csoukup has quit IRC | 23:54 | |
*** RichardRaseley has quit IRC | 23:56 | |
*** dolphm_418 is now known as dolphm | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!