| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-06 | |||
| 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 | mriedem | rebuild of a volume-backed server is never a new image - you get a 400 if you try | |
| 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: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 | fungi | KeithMnemonic: aha, got it, so yes you know this route well | |
| 15:15:29 | sean-k-mooney | https://github.com/openstack/devstack/blob/1f6bea1768c2066f3dd5604aee569ad633f45fbc/stackrc#L605-L606 | |
| 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 | |
| 15:31:55 | sean-k-mooney | e.g. form an openstack porduct perspective we can donwgrade the version of a dep from that provide by the base os | |
| 15:32:39 | sean-k-mooney | granted that a bit of a specil case for OSP 15 on RHEL 8 since RHEL 8 was based on fedora 28 ish | |
| 15:32:41 | fungi | well, we *try* to test openstack against the newest available dependencies while it's under development, and then we freeze that list of dependencies when we release and make a stable branch | |
| 15:33:12 | sean-k-mooney | so it ended up pulling newer deps then were released when stine was under deveopment | |
| 15:33:13 | fungi | so the dependencies we test stable branches against should be those which were contemporary with the release | |
| 15:33:19 | mnaser | in openstack ansible world, we use source | |
| 15:33:24 | mnaser | so we found out it was broken inside stein | |
| 15:33:57 | lyarwood | sean-k-mooney: we might back to 13 for stable/queens | |
| 15:34:09 | lyarwood | sean-k-mooney: it isn't per RHEL release, it's something we build for each OSP release downstream | |
| 15:34:21 | mnaser | we had to pin the novnc version in openstack-ansible | |
| 15:34:30 | mnaser | (and thats also how i found out it was broken) | |
| 15:34:33 | sean-k-mooney | mnaser: ya we pin it in devstack too | |
| 15:34:49 | mnaser | sean-k-mooney: afaik based on my research devstack deploys the ubuntu package | |
| 15:34:54 | sean-k-mooney | fungi: that is only true for python packages really | |
| 15:34:57 | lyarwood | yeah it's packages in devstack | |
| 15:34:59 | mnaser | at least at the time when i was wondering how that issue wasnt caught | |
| 15:35:17 | sean-k-mooney | mnaser: its a job var. so we default to packages or you can enabel source install | |
| 15:35:30 | sean-k-mooney | but we use 18.04 in the gate and package is the default | |
| 15:35:41 | sean-k-mooney | so it would have been using an older version | |
| 15:35:48 | fungi | sean-k-mooney: it's true for other dependencies too, insofar as we test on lts distros which make the same assumptions about selectively backporting fixes in their packages | |
| 15:36:14 | fungi | and we don't change the distro version we test a given branch on from what it was tested on while that release was still under development | |
| 15:36:19 | sean-k-mooney | fungi: sure but RHEL8 for example was based on the latest fedroa that was availble during stine | |