| *** markvoelker has joined #openstack-keystone | 00:00 | |
| *** markvoelker has quit IRC | 00:05 | |
| *** dtruong has quit IRC | 00:07 | |
| *** dtruong has joined #openstack-keystone | 00:07 | |
| *** markvoelker has joined #openstack-keystone | 00:22 | |
| *** gyee has quit IRC | 00:36 | |
| *** markvoelker has quit IRC | 00:47 | |
| *** spatel has joined #openstack-keystone | 01:23 | |
| *** dave-mccowan has joined #openstack-keystone | 02:35 | |
| *** markvoelker has joined #openstack-keystone | 02:40 | |
| *** markvoelker has quit IRC | 02:46 | |
| *** markvoelker has joined #openstack-keystone | 03:20 | |
| *** markvoelker has quit IRC | 03:25 | |
| *** markvoelker has joined #openstack-keystone | 04:40 | |
| *** markvoelker has quit IRC | 04:45 | |
| *** jaosorior has joined #openstack-keystone | 05:01 | |
| *** spatel has quit IRC | 05:15 | |
| *** dave-mccowan has quit IRC | 05:16 | |
| *** adriant has joined #openstack-keystone | 05:23 | |
| *** markvoelker has joined #openstack-keystone | 06:40 | |
| *** markvoelker has quit IRC | 06:45 | |
| *** shyamb has joined #openstack-keystone | 06:49 | |
| *** dancn has joined #openstack-keystone | 06:52 | |
| *** jawad_axd has joined #openstack-keystone | 07:07 | |
| *** takamatsu has joined #openstack-keystone | 07:08 | |
| *** rcernin has quit IRC | 07:15 | |
| *** trident has quit IRC | 07:25 | |
| *** trident has joined #openstack-keystone | 07:31 | |
| *** sapd1_ has joined #openstack-keystone | 07:33 | |
| *** xek has joined #openstack-keystone | 07:37 | |
| *** sapd1 has quit IRC | 07:37 | |
| *** dancn has quit IRC | 07:39 | |
| *** dancn has joined #openstack-keystone | 07:45 | |
| *** shyamb has quit IRC | 07:51 | |
| *** tkajinam has quit IRC | 08:19 | |
| mordred | kmalloc, cmurphy: I can get behind a keystoneauth2 in U. I could also get behind some minor cleanups of transitional stuff. I feel like there's one or two parameter defaults we've wanted to change but can't for backwards compat reasons. might make sense to take a pass through, make an etherpad of things we think we'd like to change in a 2 and see which ones we're comfortable with | 08:19 |
|---|---|---|
| *** ivve has joined #openstack-keystone | 08:26 | |
| *** dancn has quit IRC | 08:28 | |
| *** dancn has joined #openstack-keystone | 08:34 | |
| *** shyamb has joined #openstack-keystone | 08:43 | |
| *** shyamb has quit IRC | 08:56 | |
| *** shyamb has joined #openstack-keystone | 09:04 | |
| *** dancn has quit IRC | 09:31 | |
| *** dancn has joined #openstack-keystone | 09:36 | |
| *** shyamb has quit IRC | 09:57 | |
| *** jaosorior has quit IRC | 10:10 | |
| *** dancn has quit IRC | 10:11 | |
| *** shyamb has joined #openstack-keystone | 10:22 | |
| *** jaosorior has joined #openstack-keystone | 10:27 | |
| *** shyamb has quit IRC | 10:44 | |
| *** shyamb has joined #openstack-keystone | 11:04 | |
| openstackgerrit | Merged openstack/keystone master: Fix translated response https://review.opendev.org/677117 | 11:10 |
| *** tesseract has joined #openstack-keystone | 11:12 | |
| *** jaosorior has quit IRC | 11:26 | |
| *** jaosorior has joined #openstack-keystone | 11:43 | |
| *** markvoelker has joined #openstack-keystone | 11:57 | |
| *** dave-mccowan has joined #openstack-keystone | 12:06 | |
| *** shyamb has quit IRC | 12:21 | |
| *** shyamb has joined #openstack-keystone | 12:25 | |
| *** shyamb has quit IRC | 12:41 | |
| *** spatel has joined #openstack-keystone | 12:43 | |
| *** spatel has quit IRC | 12:48 | |
| *** jaosorior has quit IRC | 13:14 | |
| *** spatel has joined #openstack-keystone | 13:14 | |
| *** spatel has quit IRC | 13:17 | |
| *** ivve has quit IRC | 13:24 | |
| *** lbragstad_ has joined #openstack-keystone | 13:24 | |
| *** lbragstad has quit IRC | 13:25 | |
| knikolla | o/ | 13:29 |
| lbragstad_ | o/ | 13:31 |
| *** lbragstad_ is now known as lbragstad | 13:31 | |
| *** bnemec has joined #openstack-keystone | 13:34 | |
| *** gagehugo has quit IRC | 13:34 | |
| *** bnemec is now known as beekneemech | 13:35 | |
| *** jawad_axd has quit IRC | 13:49 | |
| *** jawad_axd has joined #openstack-keystone | 13:53 | |
| *** jawad_axd has quit IRC | 13:58 | |
| lbragstad | kmalloc not sure if you saw the updates to https://review.opendev.org/#/c/676648/3 yet - but it doesn't sound like the approach we talked about yseterday will work | 14:18 |
| *** soumith_ has joined #openstack-keystone | 14:18 | |
| soumith_ | Hello all, I am unable reach cloud when I source rc file and get the status of servers,images,etc... I get the error as "Failed to discover available identity versions when contacting... Unable to establish connection to http://192.168.100.3:5000/v3/auth/tokens: ('Connection aborted.', BadStatusLine('No status line received - the server has closed the connection',)) | 14:23 |
| soumith_ | ". Can anyone help me know why this issue is raised? Thank you! | 14:23 |
| *** jawad_axd has joined #openstack-keystone | 14:46 | |
| *** jawad_axd has quit IRC | 14:51 | |
| *** xek has quit IRC | 14:58 | |
| *** cmurphy is now known as cmorpheus | 15:09 | |
| *** jawad_axd has joined #openstack-keystone | 15:11 | |
| *** jawad_axd has quit IRC | 15:16 | |
| *** dave-mccowan has quit IRC | 15:20 | |
| kmalloc | lbragstad: i hadn't seen it yet | 15:21 |
| *** gagehugo has joined #openstack-keystone | 15:24 | |
| *** soumith_ has quit IRC | 15:28 | |
| *** gyee has joined #openstack-keystone | 15:46 | |
| *** jamesmcarthur has joined #openstack-keystone | 15:47 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystoneauth master: Allow initializing session with connection retries https://review.opendev.org/676648 | 15:55 |
| lbragstad | fwiw - i'm trying to recreate ^ locally | 15:59 |
| kmalloc | lbragstad, cmorpheus ^ see the changes here. fixed the concerns i had with the tests and fixed the releasenote. If everyone is fine with this, we can roll with it as is. if we would prefer the call-args default (vs. in-built session default), I'll quickly spin that up | 15:59 |
| kmalloc | lbragstad: i've been unable to recreate it locally no matter how hard I try | 15:59 |
| kmalloc | lbragstad: but i don't doubt it occurs. | 15:59 |
| lbragstad | hmm | 16:00 |
| *** lbragstad is now known as elbragstad | 16:00 | |
| *** kmalloc is now known as needscoffee | 16:00 | |
| *** needscoffee is now known as needsSoMuchMoreC | 16:00 | |
| *** needsSoMuchMoreC is now known as needscoffee | 16:00 | |
| needscoffee | bah | 16:00 |
| needscoffee | anyway | 16:00 |
| *** AJaeger has left #openstack-keystone | 16:01 | |
| elbragstad | i'm trying to get this to timeout using get_endpoint() with the ksa adapter, per one of the comments | 16:06 |
| elbragstad | no luck so far | 16:06 |
| elbragstad | not sure if i'm doing something wrong - but this is what i'm doing to try and recreate this https://pasted.tech/pastes/2fd7d369468c40fd831bef830c27467f208eea7a.raw | 16:07 |
| *** beekneemech has quit IRC | 16:07 | |
| needscoffee | hm, yeah i think it's a case where it's keystone being slightly overloaded and blocking a connection waiting on DB or something | 16:08 |
| needscoffee | or an endpoint being slow to respond for the version discovery | 16:08 |
| needscoffee | in general | 16:08 |
| needscoffee | but in all seriousness, i can't duplicate it | 16:08 |
| needscoffee | maybe run a keystone with a single thread/worker and have a bunch of these hammer it? | 16:09 |
| *** tesseract has quit IRC | 16:11 | |
| elbragstad | ok - trying that now | 16:20 |
| *** bnemec has joined #openstack-keystone | 16:20 | |
| needscoffee | coreycb: responded to your email. I expect I'll be able to help more directly next week on unblocking the patch | 16:29 |
| needscoffee | coreycb: the comment was definitely not directed at you. | 16:29 |
| needscoffee | coreycb: unless the original submitter can address the concerns. | 16:29 |
| coreycb | needscoffee: thanks. ok well either way i think it's a good point. :) | 16:29 |
| needscoffee | ^_^ | 16:30 |
| needscoffee | coreycb: i am sure you can see why i was frustrated there. I re-wrote the first email at least 10 times to try and not sound like I was too grumpy/unwilling to work with folks. | 16:31 |
| needscoffee | anyway. have a great rest of your friday and i'll see about following up next week so we can get the py3 stuff unblocked | 16:32 |
| coreycb | needscoffee: i completely side-tracked that email. thanks for clearing it up. and yes i completely get it. have a good weekend and thanks! | 16:34 |
| *** markvoelker has quit IRC | 16:39 | |
| *** markvoelker has joined #openstack-keystone | 16:47 | |
| elbragstad | needscoffee i think i was able to recreate it? | 16:49 |
| elbragstad | i set the timeout on the session to be really short (0.1 seconds) | 16:49 |
| needscoffee | ah | 16:49 |
| needscoffee | so it is a case where the server is somewhat overloaded | 16:50 |
| elbragstad | hmm | 16:50 |
| elbragstad | i mean - i guess that's what it's trying to simulate? | 16:50 |
| cmorpheus | needscoffee: re 676648, do you believe it's a good idea to store connection retry settings in the session object where it is likely to be used for all services the session is used for? if so, why not also add all of the other retry and concurrency settings from the adapter to the session? | 16:51 |
| elbragstad | needscoffee https://pasted.tech/pastes/ab7b4cea5fada59c63062a67dfd0a3957986a896.raw | 16:51 |
| *** bnemec has quit IRC | 16:53 | |
| needscoffee | cmorpheus: i really don't like it there. | 16:57 |
| needscoffee | cmorpheus: but i get that they can't really shove it in the adapter for all cases | 16:57 |
| elbragstad | so - i have some questions about that | 16:58 |
| needscoffee | but overall, as long as the call args overrides the session-level set | 16:58 |
| needscoffee | i'm fine with allowing a session-wide set of retries | 16:58 |
| elbragstad | it sounds like heat needs to use a session because the data changes and can't be relied on/cached? | 16:58 |
| needscoffee | and my new test shows it does, properly | 16:58 |
| cmorpheus | elbragstad: i think it's because they get trust tokens for different trust users | 16:59 |
| cmorpheus | trustor users* | 16:59 |
| needscoffee | ^ that is my understanding | 16:59 |
| elbragstad | ok - so they need a session because the use changes | 16:59 |
| elbragstad | ? | 16:59 |
| elbragstad | user* | 16:59 |
| cmorpheus | i'm still unclear on why they can't use an adapter tbh | 16:59 |
| needscoffee | it | 16:59 |
| needscoffee | 's why i've held off on +2 | 17:00 |
| needscoffee | but the +1 is because the code should be fine as it sits | 17:00 |
| elbragstad | ok - so the alternative you proposed cmorpheus was to have an adapter and reach into the session to adjust the auth data? | 17:01 |
| needscoffee | that sounds... weird. | 17:01 |
| cmorpheus | that was my proposal but they face the same issue because it goes through the session which doesn't have retries | 17:01 |
| needscoffee | like breaking the session/adapter divide | 17:01 |
| cmorpheus | because get_access and get_auth_ref don't expose it | 17:01 |
| elbragstad | oh | 17:01 |
| elbragstad | well - neutron actually uses that approach | 17:02 |
| elbragstad | https://opendev.org/openstack/python-neutronclient/src/commit/ab426a791ad1937ea2cf3b340202b3968a378978/neutronclient/client.py#L379 | 17:02 |
| cmorpheus | it is a little weird | 17:04 |
| needscoffee | yeau | 17:04 |
| needscoffee | i think it probably is an option that should go on session ... or maybe in the auth plugins? | 17:05 |
| needscoffee | i really want to encourage not just setting session-wide retries | 17:05 |
| needscoffee | it seems blunt. where adapters are intended to do this. | 17:05 |
| needscoffee | or even just allow get_auth_ref to handle a retry case. | 17:06 |
| cmorpheus | yeah i am trying to figure out whether it's more awkward to add it to the session or the auth plugin | 17:06 |
| elbragstad | i have another dumb question - it's not specific to retries from keystone? | 17:06 |
| needscoffee | ++ | 17:06 |
| needscoffee | it is mostly keystone-specific, but it is in a path that is awkward to work with | 17:06 |
| elbragstad | the traceback in the bug report is between neutron and nova i think | 17:07 |
| elbragstad | so - it's failing because it's using a trust-scoped token to do things with resources in a stack? | 17:07 |
| cmorpheus | that was a weird traceback to use as an example because that actually is using the adapter | 17:07 |
| cmorpheus | the actual issue in the bug report is about get_auth-ref | 17:07 |
| elbragstad | ah | 17:07 |
| cmorpheus | that was part of my confusion and why i withdrew from the discussion a bit on the review | 17:08 |
| cmorpheus | if it's applied to the session, and not overridden in session.request() by the adapter or anything else, then it will be used on all services | 17:09 |
| *** jamesmcarthur has quit IRC | 17:11 | |
| *** jamesmcarthur has joined #openstack-keystone | 17:11 | |
| cmorpheus | which could mean ksa itself will start hammering all of the services even more, and there's no rate semaphore in the session to control the retry delay | 17:13 |
| elbragstad | in that case, would a timeout for a nova call result in a retry for another service? | 17:14 |
| needscoffee | possibly | 17:14 |
| cmorpheus | mm i don't think it would be that bad | 17:14 |
| cmorpheus | it would just keep retrying nova | 17:14 |
| elbragstad | the retry logic is still just using the adapter retry lofic | 17:15 |
| elbragstad | logic* | 17:15 |
| elbragstad | so - it would be service-specific(?) | 17:15 |
| elbragstad | it's just exposing it through the Session | 17:15 |
| * elbragstad is thinking out loud | 17:16 | |
| cmorpheus | so - you get a session object, s = session.Session(auth=auth, connect_retries=10), all good - then do s.request(novaurl) - if nova is healthy then everything is fine, if the nova service is flaky then it will be retried and maybe eventually succeed, or maybe contribute to nova being overloaded | 17:19 |
| cmorpheus | other services wouldn't be involved, but my point was that if the reason you're setting connect_retries=10 is because you expect keystone to be flaky, but then as a side effect get retries for the nova service, that is kind of weird | 17:20 |
| elbragstad | hmm | 17:20 |
| elbragstad | in the original bug report or early review comments it sounded like keystone was timing out but there were plenty of keystone processes available to handle requests | 17:20 |
| cmorpheus | and gets you in the situation where if nova is actually down and you didn't expect it (and you can't set the retriable status codes because we haven't exposed that) then you're waiting for 10 retries for no reason | 17:20 |
| elbragstad | https://bugs.launchpad.net/keystoneauth/+bug/1840235/comments/2 | 17:21 |
| openstack | Launchpad bug 1840235 in keystoneauth "[Errno 110] ETIMEDOUT with endpoint discovery and token request" [Undecided,In progress] - Assigned to Morgan Fainberg (mdrnstm) | 17:21 |
| elbragstad | "When updating large heat stacks with number of nested stacks, we create auth plugins and request number of trust tokens concurrently for every nested stack, and we see ETIMEDOUT errors[1], in spite of having large number of keystone workers. " | 17:22 |
| *** jamesmcarthur has quit IRC | 17:22 | |
| elbragstad | i guess now i'm curous what's causing the timeouts in that particular case if keystone isn't maxed out (and is assumed to be healthy enough to respond to incoming requests) | 17:22 |
| cmorpheus | that's a good question | 17:23 |
| elbragstad | am i understanding the properly? | 17:23 |
| cmorpheus | i think you are | 17:24 |
| elbragstad | hmm | 17:27 |
| elbragstad | ok - commented on the bug | 17:27 |
| elbragstad | i think i'm still missing some context around the heat flow | 17:28 |
| *** zaneb has joined #openstack-keystone | 17:32 | |
| elbragstad | oh - well there he is | 17:32 |
| zaneb | elbragstad: this is probably a better place to discuss :) | 17:33 |
| elbragstad | i was just about to say that i was talking to zaneb in -dev but it looks like he made the move here for us ;) | 17:33 |
| elbragstad | zaneb agreed | 17:33 |
| zaneb | so Rabi was working on it directly, I only know second-hand info | 17:33 |
| zaneb | but AIUI keystone was one of the things that was timing out | 17:34 |
| elbragstad | that's fair - i was pinging him a bit yesterday, but i know our timezones don't really line up | 17:34 |
| zaneb | at that scale everything starts to timeout some (small but usally fatal ;) portion of the time | 17:34 |
| elbragstad | the wording in the bug report makes it seem like the initial timeout aren't related to the amount of keystone resources | 17:35 |
| elbragstad | "When updating large heat stacks with number of nested stacks, we create auth plugins and request number of trust tokens concurrently for every nested stack, and we see ETIMEDOUT errors[1], in spite of having large number of keystone workers." | 17:36 |
| elbragstad | so - just wondering if there was any insight into what's causing those if keystone is relatively healthy at that point | 17:36 |
| elbragstad | or - should i be interpreting that as "even with a high number of keystone nodes, we still overload them with requests when updating tons of stacks" | 17:37 |
| zaneb | elbragstad: yes, the last thing you said | 17:38 |
| elbragstad | ok - i so i was misunderstanding it then | 17:38 |
| elbragstad | cool | 17:38 |
| zaneb | with s/nodes/workers/ | 17:38 |
| zaneb | basically you only get one undercloud node to run everything on, and they scale the workload out until things start failing. then fix those things and scale it up again | 17:38 |
| zaneb | right now what's failing is that even with plenty of workers, they've hit the limit and some requests are now timing out | 17:39 |
| zaneb | which is fine; we just need graceful ways for clients to handle that | 17:39 |
| elbragstad | and https://review.opendev.org/#/c/678039/ does that for nearly all other clients heat uses | 17:40 |
| zaneb | https://review.opendev.org/#/c/678193/ is also necessary for the keystone bits | 17:41 |
| zaneb | I think we'll backport those two, because we can't backport a requirements change to bump keystoneauth anyway | 17:42 |
| elbragstad | yeah | 17:43 |
| zaneb | but it would be nice to have a way to specify retries on the keystone get token/catalog on master at least | 17:43 |
| elbragstad | so https://review.opendev.org/#/c/678193/3 fixes the issue, but just not with ksa directly | 17:43 |
| zaneb | yeah. arguably it's a workaround ;) | 17:44 |
| elbragstad | specifically so you can backport it, yeah? | 17:44 |
| zaneb | right. we would drop that on master in favour of a fix in ksa if it were available | 17:45 |
| * elbragstad nods | 17:46 | |
| elbragstad | so retries are needed here because you're calling get_access https://review.opendev.org/#/c/678193/3/heat/common/context.py@306 | 17:47 |
| elbragstad | and get_endpoint is susceptible to the same thing | 17:47 |
| zaneb | that's my understanding | 17:47 |
| elbragstad | https://review.opendev.org/#/c/678193/3/heat/engine/clients/client_plugin.py,unified@94 looks like keystone-specific code | 17:48 |
| elbragstad | dumb question: but if it's keystone-specific could it use an adapter? | 17:48 |
| zaneb | it's in the base class for all of the client plugins. not sure if it's keystone-specific in the sense that you mean it | 17:50 |
| elbragstad | ah | 17:50 |
| * zaneb has a sketchy understanding of keystone auth stuff | 17:51 | |
| elbragstad | at first glance, i was thinking that method was specific to only connecting to keystone, but i think the keystone-specific stuff i was assuming is only for parsing a service url out of a catalog | 17:51 |
| elbragstad | it looks like it could handle something like url_for(interface='public', service_name='nova') | 17:54 |
| elbragstad | or whatnot | 17:54 |
| zaneb | looks like it | 17:55 |
| elbragstad | iiuc - it looks like the minimum to fix this in ksa would be to expose connection retries through get_access() and get_endpoint() | 17:56 |
| elbragstad | but the current implementation does that via the session (covering both of those cases?) | 17:57 |
| elbragstad | cmorpheus needscoffee thoughts? | 17:57 |
| needscoffee | i'm more inclined to have it be explicit for get_access and get_endpoint, or to enhance to have explicit auth retries independent of the service communication | 18:01 |
| needscoffee | but really, i'm kindof fine with whatever solution is selected, noting that none of these features can be backported | 18:01 |
| needscoffee | in general. | 18:02 |
| *** cp has joined #openstack-keystone | 18:02 | |
| needscoffee | my general view is: give an auth-path retry that is session-specific and leaned on for all auth-bits unless overidden | 18:03 |
| needscoffee | second choice, session-global that can be overidden | 18:03 |
| needscoffee | i am worried that get_access and get_endpoint having separate retry values would be awful to use | 18:03 |
| elbragstad | yeah - that could be strange | 18:06 |
| elbragstad | if there are session-wide concerns, then option #1 makes sense? | 18:18 |
| elbragstad | but i know the least about ksa out of everyone having this discussion, so i'll wait for others to weigh in ;) | 18:20 |
| *** gyee has quit IRC | 18:42 | |
| *** gyee has joined #openstack-keystone | 18:46 | |
| *** xek has joined #openstack-keystone | 18:58 | |
| openstackgerrit | Gage Hugo proposed openstack/keystonemiddleware master: Comment html_static_path entry in docs conf.py https://review.opendev.org/677840 | 19:04 |
| *** hrybacki has joined #openstack-keystone | 19:05 | |
| *** bnemec has joined #openstack-keystone | 19:10 | |
| *** bnemec is now known as beekneemech | 19:11 | |
| cmorpheus | easy review https://review.opendev.org/677840 | 19:23 |
| *** jamesmcarthur has joined #openstack-keystone | 19:28 | |
| *** jamesmcarthur has quit IRC | 19:32 | |
| *** jamesmcarthur has joined #openstack-keystone | 19:32 | |
| *** jamesmcarthur has quit IRC | 19:43 | |
| openstackgerrit | Merged openstack/keystonemiddleware master: Comment html_static_path entry in docs conf.py https://review.opendev.org/677840 | 19:44 |
| *** jamesmcarthur has joined #openstack-keystone | 19:45 | |
| *** jamesmcarthur has quit IRC | 19:50 | |
| *** ivve has joined #openstack-keystone | 20:03 | |
| *** jamesmcarthur has joined #openstack-keystone | 20:14 | |
| *** jamesmcarthur has quit IRC | 20:18 | |
| *** jamesmcarthur has joined #openstack-keystone | 20:19 | |
| needscoffee | cmorpheus: I have a working migration and realized i needed to do some research on orm.relationship backrefs | 20:25 |
| needscoffee | cmorpheus: it's getting close to having a base implementation with a mixin. | 20:25 |
| needscoffee | cmorpheus: there is some additional wonky tooling around json_schema stuff, but should be straightforward. | 20:26 |
| cmorpheus | needscoffee: o7 | 20:28 |
| elbragstad | i know we recently refreshed our service token docs | 21:13 |
| elbragstad | but... do the steps in https://review.opendev.org/#/c/672145/2/doc/source/configuration/block-storage/service-token.rst@43 look accurate to everyone else? | 21:13 |
| * elbragstad didn't think services needed to roll out their own configuration option in order get that functionality? | 21:14 | |
| cmorpheus | i didn't think so either, but i know nova has similar instructions | 21:17 |
| elbragstad | oh - really? | 21:17 |
| elbragstad | i was under the impression that services would build clients with auth information from the [keystone_authtoken] section anyway | 21:18 |
| cmorpheus | yeah i am unclear on why they are not doing that | 21:25 |
| * elbragstad grabs a copy of cinder | 21:25 | |
| *** xek has quit IRC | 21:25 | |
| elbragstad | grepping the cinder source i don't actually see that configuration used? | 21:26 |
| elbragstad | maybe i should just head over there | 21:26 |
| needscoffee | ok i ran into a problem | 21:32 |
| *** needscoffee is now known as kmalloc | 21:32 | |
| kmalloc | i guess i'm just going to create separate options table for each resource. | 21:33 |
| kmalloc | trying to be clever and do some join magic to load them with the ORM.relationship bit is just not working. | 21:33 |
| kmalloc | cmorpheus: let me respin this, I'll just do roles for the moment so we can do immutable there. | 21:34 |
| cmorpheus | kmalloc: okay | 21:34 |
| kmalloc | *sigh*, this is going to mean we need to be very deliberate where we want resource options | 21:35 |
| kmalloc | otherwise we get an explosion ot DB tables. | 21:35 |
| kmalloc | of* | 21:35 |
| kmalloc | so, roles... and anything else should be lumped in? project? domain? | 21:35 |
| kmalloc | adding tables is the easy part here really. | 21:36 |
| *** jamesmcarthur has quit IRC | 21:46 | |
| *** jamesmcarthur has joined #openstack-keystone | 21:48 | |
| *** jamesmcarthur has quit IRC | 21:50 | |
| *** jamesmcarthur has joined #openstack-keystone | 21:51 | |
| *** takamatsu has quit IRC | 21:55 | |
| *** jamesmcarthur has quit IRC | 22:07 | |
| *** jamesmcarthur has joined #openstack-keystone | 22:07 | |
| *** rcernin has joined #openstack-keystone | 22:11 | |
| *** jamesmcarthur has quit IRC | 22:13 | |
| cmorpheus | kmalloc: roles, users, projects, and domains are what i'm concerned about for immutable | 22:15 |
| *** ivve has quit IRC | 22:17 | |
| beekneemech | elbragstad: Heh, I didn't realize that we're coworkers again. And for the same company as last time. | 22:21 |
| beekneemech | What a long, strange trip it's been. :-) | 22:21 |
| *** jamesmcarthur has joined #openstack-keystone | 22:31 | |
| *** jamesmcarthur has quit IRC | 22:37 | |
| *** jamesmcarthur has joined #openstack-keystone | 22:39 | |
| *** jamesmcarthur has quit IRC | 22:46 | |
| *** jamesmcarthur has joined #openstack-keystone | 22:50 | |
| kmalloc | cmorpheus: almost have the Resource Options patch ready, running unit tests now. | 22:57 |
| kmalloc | cmorpheus: looks like i have a little debugging to do, but it's pretty straightforward debugging. | 22:58 |
| *** jamesmcarthur has quit IRC | 23:01 | |
| kmalloc | elbragstad: wow, i haven't run our whole unit tests on my X1C in a looong time. | 23:07 |
| kmalloc | gah it's slow | 23:07 |
| cmorpheus | it's even longer if you have the opportunistic db tests turned on | 23:08 |
| kmalloc | cmorpheus: yeah i don't think i have those enabled. | 23:08 |
| kmalloc | but when check_system_role is taking >10s to run | 23:08 |
| kmalloc | we have issues :( | 23:08 |
| kmalloc | test_user_can_revoke_project_scoped_token should not take 10seconds to run | 23:09 |
| *** rcernin has quit IRC | 23:11 | |
| *** rcernin has joined #openstack-keystone | 23:12 | |
| *** jamesmcarthur has joined #openstack-keystone | 23:15 | |
| *** jamesmcarthur has quit IRC | 23:17 | |
| *** jamesmcarthur has joined #openstack-keystone | 23:19 | |
| kmalloc | wow... | 23:20 |
| kmalloc | Sum of execute time for each test: 10104.3671 sec. | 23:20 |
| kmalloc | cmorpheus: ^ is that... consistent with what you see? | 23:20 |
| kmalloc | that seems... excessive | 23:20 |
| kmalloc | makes me wondr if my laptop is having issues | 23:21 |
| *** jamesmcarthur has quit IRC | 23:22 | |
| *** jamesmcarthur has joined #openstack-keystone | 23:22 | |
| * beekneemech does the math | 23:26 | |
| *** beekneemech is now known as keanu | 23:26 | |
| keanu | whoa | 23:26 |
| *** keanu is now known as beekneemech | 23:27 | |
| cmorpheus | kmalloc: not sure because i never run them serially | 23:32 |
| *** jamesmcarthur has quit IRC | 23:32 | |
| cmorpheus | without the opportunistic tests it's around 15-20 minutes for me with tox | 23:32 |
| cmorpheus | as the ci has been showing it can be upwards of 40 minutes with the opportunistic tests on a slow node | 23:32 |
| *** jamesmcarthur has joined #openstack-keystone | 23:38 | |
| *** jamesmcarthur has quit IRC | 23:42 | |
| kmalloc | ouch | 23:49 |
| kmalloc | hmm... | 23:51 |
| kmalloc | i think my tests took a lot longer | 23:51 |
| kmalloc | ok i'm posting the change it is not passing tests yet, have a couple things to fix. | 23:55 |
| kmalloc | but just so it has some eyes. this does not implemnet immutable yet | 23:56 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Implement resource options for roles and projects https://review.opendev.org/678322 | 23:56 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!