Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-06
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
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
15:36:41 sean-k-mooney so it has signifcatly newer packages in some cases
15:36:54 fungi yeah, we test on centos not rhel, and there is no centos 8 (yet)
15:36:59 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Replace non-nova server fault message https://review.opendev.org/674848
15:37:19 sean-k-mooney rhel/centos revs so rarely that it is very uncommon for it to be ahead of the ubunut lts but it was for stien
15:37:34 sean-k-mooney ya hopefully centos 8 will be around soon
15:37:42 sean-k-mooney *available
15:37:50 fungi if red hat had worked with the community to release centos 8 in concert with rhel 8 we would have been testing on it
15:38:23 sean-k-mooney i think the triplo builds are using rhel8 at least some of them are
15:38:23 fungi but since centos releases only get started after rhel releases are made available there is a definite lag between them
15:38:41 fungi probably in rdo's ci system, yes
15:39:04 fungi opendev is unable to test on rhel owing to cloud providers requiring purchased support licenses if you want to boot instances with rhel images
15:39:33 fungi which is why we ended up using centos
15:39:48 sean-k-mooney ya well i think centos is fine for testing
15:40:36 sean-k-mooney it sound like redhat might need to backport this too at some point based lyarwood comment so it might make more sense to do it once upstream
15:40:42 fungi but it does mean that rhel is left out in the cold until centos gets in sync (i have no sympathy there, it's a problem red hat has created through their licensing policies)

Earlier   Later