| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-06 | |||
| 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) | |
| 15:41:20 | sean-k-mooney | im surprised that the developer/test licensing would not cover this usecase | |
| 15:42:33 | jangutter | fungi: I seem to recall in 2014 when CentOS got acquired by RH that developers on both sides were pretty adamant in maintaining a "Chinese Wall" between them. | |
| 15:44:23 | fungi | jangutter: yep, there is a similar situation between debian and ubuntu, but since debian is doing their development of each new release completely in the open ubuntu can track that and consume packages slated for the next release without waiting | |
| 15:44:25 | jangutter | fungi: also, epel8 is going to trail centos8 by a bit, so even if it's released it's going to be a bit rocky in places. | |
| 15:44:25 | sean-k-mooney | jangutter: i can realy comment on that as i dont know the history and proably shouldnt for leagl reason anyway but i personally was not expecting the delay to be as long as it has been. that said its a lot of work | |
| 15:44:56 | sean-k-mooney | fungi: well redhat does its dev in fedora | |
| 15:45:11 | fungi | but does rhel consume fedora packages? | |
| 15:45:13 | sean-k-mooney | fedroa is upstream of rhel and centos in downstream of rhel | |
| 15:45:18 | sean-k-mooney | fungi: yes | |
| 15:45:25 | sean-k-mooney | well kind of | |
| 15:45:33 | fungi | so the packages built in fedora are the ones which will appear in rhel | |
| 15:45:39 | sean-k-mooney | rhel8 started as a clone of fedora 28 | |