| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-06 | |||
| 14:29:25 | efried | actually if tempest *were* sending it, I wouldn't be seeing the behavior I'm seeing | |
| 14:29:36 | efried | cdent: So what I'm looking for is this: | |
| 14:29:45 | efried | Presumably the API server sits there waiting for requests | |
| 14:29:56 | efried | when a request comes in, it... spawns? reuses? a thread to handle it | |
| 14:30:21 | efried | Whatever RequestContext that thread gets needs to get a fresh global_request_id | |
| 14:30:31 | efried | early as possible | |
| 14:30:59 | efried | so - I need to grab hold of the code that spins off that thread | |
| 14:31:39 | efried | (btw, ^ is for API requests obvi. Periodics will be a separate thing entirely.) | |
| 14:33:01 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/auth.py#L57 is what creates the RequestContext in the compute API | |
| 14:35:21 | efried | mriedem: yup https://review.opendev.org/#/c/674138/4/nova/api/openstack/auth.py | |
| 14:35:41 | efried | So that's working now | |
| 14:35:57 | efried | the thing I'm trying to tackle now is, I want each API request to get a new global_request_id. | |
| 14:36:16 | efried | because right now it's getting reused for multiple operations | |
| 14:36:33 | efried | Actually, cdent, I think perhaps that compute_req_id might be the place to do it. | |
| 14:36:59 | efried | The superclass is pulling in a request ID from headers if available... but what I can do is *set* a new one if there wasn't one in the header. | |
| 14:43:20 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Always set a global_request_id in RequestContext https://review.opendev.org/674138 | |
| 14:43:22 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Correct global_request_id sent to Placement https://review.opendev.org/674129 | |
| 14:43:36 | efried | cdent, mriedem: let's see how that shakes out ^ | |
| 14:46:23 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Replace non-nova server fault message https://review.opendev.org/674821 | |
| 14:46:34 | mriedem | dansmith: ^ | |
| 14:46:47 | fungi | i'm watching these go up too, thanks mriedem! | |
| 14:47:07 | dansmith | mriedem: ack | |
| 14:55:47 | cdent | sorry efried was drawn away into another converation | |
| 14:56:07 | cdent | I had thought that the existing one was supposed to set a new one | |
| 14:56:08 | cdent | (if not present) | |
| 14:58:16 | efried | cdent: If you look at the parent impl, it doesn't. | |
| 14:58:46 | efried | Previous PS of my change did it further down, but too late, and sucked up whatever was in thread local already if one wasn't set. | |
| 14:59:22 | efried | It's possibly the guts of my ensure_global_id never gets hit now, which would possibly be a good thing. | |
| 14:59:44 | efried | mriedem: rebuild... gets a new image or no? | |
| 15:00:01 | openstackgerrit | Brin Zhang proposed openstack/nova master: Change the response to migrations of Show Migration Details API https://review.opendev.org/674825 | |
| 15:00:09 | efried | okay, yeah, looks like it. | |
| 15:01:21 | mriedem | efried: optional | |
| 15:01:49 | mriedem | https://docs.openstack.org/api-ref/compute/#rebuild-server-rebuild-action | |
| 15:01:59 | efried | mriedem: ack. I was looking at https://review.opendev.org/#/c/673407/ and requesting a func test for rebuild as well as spawn, but that wouldn't have made any sense if you couldn't specify a new image for rebuild. | |
| 15:01:59 | mriedem | rebuild of a volume-backed server is never a new image - you get a 400 if you try | |
| 15:02:04 | cdent | efried: i'm guessing that middleware is making assumptions about clients, which is unfortunate | |
| 15:02:19 | efried | cdent: whadayamean? | |
| 15:02:39 | cdent | it assumes that an e.g., nova client will set a request id | |
| 15:02:55 | cdent | (the INBOUND_HEADER) | |
| 15:02:57 | efried | oh, you mean oslo's middleware is assuming things about clients | |
| 15:03:11 | mriedem | efried: this compression container_format thing seems to be flying under the radar but is a feature/blueprint | |
| 15:03:44 | efried | mriedem: yes, the above patch just adds an early fail for it. No intention of allowing them to attempt to add support for compressed images in Train. | |
| 15:04:27 | efried | mriedem: above patch is goodness because otherwise we happily create the instance and make it ACTIVE per nova, but the OS doesn't come up so it's nonsense. | |
| 15:04:42 | openstackgerrit | Brin Zhang proposed openstack/nova master: Filter migrations by user_id/project_id https://review.opendev.org/674243 | |
| 15:05:15 | efried | mriedem: suspect one of us will get to help them write their func test tho :) | |
| 15:05:16 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/stein: Replace non-nova server fault message https://review.opendev.org/674828 | |
| 15:06:33 | KeithMnemonic | does anyone know if there are plans to put this on Rocky as well https://review.opendev.org/#/c/649372/ | |
| 15:07:15 | KeithMnemonic | i tried doing a simple cherry pick but there are some merge conflicts so was not sure the level of effort or if there are too many dependencies. | |
| 15:10:04 | efried | mnaser, melwitt: ^ ? | |
| 15:10:15 | mriedem | KeithMnemonic: i don't think there are any plans no | |
| 15:10:42 | mriedem | the comment from melwitt on the master branch change was, "Yeah, I agree a reno would be helpful here. Looks like this breakage/change in noVNC behavior was released on Apr 9 [3], which was during Stein, so we could potentially backport to Stein. I don't know about earlier though... I don't know if we should reasonably expect anyone on < Stein would possibly install noVNC 1.1.0?" | |
| 15:11:13 | mriedem | KeithMnemonic: are you using a distro with rocky that has novnc 1.1.0 or are you building packages from source? | |
| 15:11:19 | KeithMnemonic | the problem is without this vnc consoles to esx hypervisors are broken in rocky | |
| 15:11:36 | KeithMnemonic | so i kind of need rocky to support 1.1.0 | |
| 15:11:49 | mriedem | but why/how are you getting/using novnc 1.1.0? | |
| 15:11:55 | mriedem | distro or rolling your own packages from source? | |
| 15:12:19 | KeithMnemonic | i pulled from github to test outside of nova | |
| 15:12:32 | KeithMnemonic | the issue is reproducible just using novnc 1.0 | |
| 15:12:37 | KeithMnemonic | and is fixed in 1.1 | |
| 15:12:44 | sean-k-mooney | KeithMnemonic: is there a feature in 1.1.0 that you need | |
| 15:12:45 | KeithMnemonic | so we could try and patch 1.0 | |
| 15:12:59 | KeithMnemonic | yeah " the it works" feature | |
| 15:13:19 | sean-k-mooney | no i mean we used older versions in rocky | |
| 15:13:20 | mriedem | the commit message on that change from mnaser says that 1.1.0 is the breaking novnc change, i can't comment on 1.0 | |
| 15:14:20 | fungi | this is basically the "maintaining your own distro" problem. if you were a stable server linux distro packaging novnc and considered esx important, you would work out how to backport the esx fix to older novnc you were already shipping | |
| 15:14:26 | KeithMnemonic | so i am just talking about novnc for a minute. the 1.0.0 release do not work with vnc console provide for instances running on esx | |
| 15:14:32 | KeithMnemonic | the 1.1 version does work | |
| 15:14:47 | KeithMnemonic | fungi we can do that | |
| 15:15:07 | KeithMnemonic | we (SUSE) is a stable server linux distro | |
| 15:15:08 | sean-k-mooney | ok so esx is the issue | |
| 15:15:27 | sean-k-mooney | or rather that while we test with 1.0.0 | |
| 15:15:29 | sean-k-mooney | https://github.com/openstack/devstack/blob/1f6bea1768c2066f3dd5604aee569ad633f45fbc/stackrc#L605-L606 | |
| 15:15:29 | fungi | KeithMnemonic: aha, got it, so yes you know this route well | |
| 15:15:37 | sean-k-mooney | we dont test with esx | |
| 15:15:43 | KeithMnemonic | but instead of hacking in patches to noVNC, was wondering if there were plans to support 1.1 in rocky since this effects anyone using rocky and novnc 1.0 | |
| 15:15:54 | sean-k-mooney | which is why 1.0.0 was used for rocky | |
| 15:16:20 | sean-k-mooney | KeithMnemonic: no it only effect those using rocky and novnc with esk | |
| 15:16:23 | sean-k-mooney | *esx | |
| 15:16:31 | sean-k-mooney | if you use libvirt kvm its fine | |
| 15:16:32 | KeithMnemonic | correct | |
| 15:16:47 | fungi | i'm separately curious why it's okay for a stable distro to change the upstream version of novnc but not openstack (though i can guess at the reasons) | |
| 15:16:58 | KeithMnemonic | rocky/novnc/esx | |
| 15:17:42 | KeithMnemonic | so was just looking for any guidance from nova as to which path we need to take and it looks like we need to carry a patched novnc | |
| 15:18:00 | sean-k-mooney | i mean regardless of if this is backported upstream it could be backported in suses distro version of nova | |
| 15:18:42 | sean-k-mooney | looking at the patch | |
| 15:19:05 | sean-k-mooney | its mainly test update | |
| 15:19:39 | sean-k-mooney | i personally dont think it would be a large risk to backport if the path paramter works with loder releases | |
| 15:21:19 | sean-k-mooney | e.g. if using path with 1.0.0 is fine then this seams resonable to backport to me. we are modifying one of the properties on the console_auth_token ovo but we are not modifying the data fields so i think that is safe | |
| 15:23:44 | KeithMnemonic | sean-k-mooney: we prefer to track upstream where possible but if you think it is worth trying to backport I can play with it | |
| 15:25:39 | sean-k-mooney | well we try to do that at redhat too but if i had to choose between carrying this patch to nova an potentially several to novnc i would carry this | |
| 15:26:32 | sean-k-mooney | but i think this could be considerd for backport upstream but for OSP we are not shiping novnc 1.1 until stien | |
| 15:28:25 | sean-k-mooney | lyarwood: we dont have any plans to land novnc 1.1 in any rhel 7.x release do we that only used on rhel8 right | |
| 15:28:35 | fungi | KeithMnemonic: to play devil's advocate for a moment, if you prefer to track upstream where possible, then why are you shipping openstack rocky? | |
| 15:29:01 | sean-k-mooney | fungi: you mean openstack rocky with novnc 1.1 | |
| 15:29:12 | fungi | well, they're not currently | |
| 15:29:34 | fungi | seems like if you're carrying a point-in-time snapshot of a project then you're committed to carrying the contemporary versions of its dependencies too | |
| 15:30:36 | KeithMnemonic | fungi we have not released our next product yet based on > rocky | |
| 15:30:41 | fungi | which is the assumption our stable branch policies are based on | |
| 15:31:23 | fungi | we avoid backporting potentially disruptive changes, including testing against newer versions of dependencies, so as to avoid breaking that assumption for stable distros | |
| 15:31:24 | sean-k-mooney | fungi: well i know from a redhat persoective OSP uses newer versions of some deps then are in upper constraits because the version in the base distor are newer | |