| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-06 | |||
| 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 | fungi | but since centos releases only get started after rhel releases are made available there is a definite lag between them | |
| 15:38:23 | sean-k-mooney | i think the triplo builds are using rhel8 at least some of them are | |
| 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 | 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: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: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 | artom | Dammit, we store image_meta in the DB somewhere, right? | |
| 15:45:39 | sean-k-mooney | rhel8 started as a clone of fedora 28 | |
| 15:46:04 | fungi | anyway, we're verging way off-topic for #openstack-nova i expect | |
| 15:46:22 | sean-k-mooney | fungi: they get rebuilt and sometimes they are tweek due to versions change but ya i belive that is how it works | |
| 15:46:32 | sean-k-mooney | fungi: ya | |
| 15:46:52 | lyarwood | sean-k-mooney: they are always rebuilt | |
| 15:46:57 | fungi | so in theory centos 8 could also have started as a f28 clone, and instead they chose to wait for rhel to finish 8. got it | |
| 15:46:58 | dansmith | artom: I don't think we store all of it | |
| 15:47:16 | artom | dansmith, the image properties part | |
| 15:47:23 | artom | They're not *just* in Glance... right? | |
| 15:47:35 | jangutter | sean-k-mooney, fungi: I'm definitely not dissing either side here, fedora, rhel and centos cannot exist without each other, and there's been some long and hard though given their relationships. | |
| 15:47:47 | dansmith | artom: we might copy that into reqspec actually, now that I think of it, but I think we only persist a few selected things into the cell db, IIRC | |
| 15:48:16 | lyarwood | sean-k-mooney: sorry I'm only half paying attention here, is this all about novnc? | |
| 15:48:39 | sean-k-mooney | lyarwood: yes tangenaly | |
| 15:48:42 | jangutter | for anyone who's interested in some really funky geometries: https://www.youtube.com/watch?v=HQsUdLPJW20 | |
| 15:48:56 | artom | dansmith, aha, request_specs, thanks! | |
| 15:49:06 | sean-k-mooney | lyarwood: KeithMnemonic was wondering if https://review.opendev.org/#/c/649372/4 could be backport upstrea to rocky | |
| 15:49:32 | sean-k-mooney | lyarwood: since suse woudl be shipng novnc 1.1 with there rocky release to enable esx console support | |
| 15:49:35 | mriedem | artom: instance_system_metadata, | |
| 15:49:38 | mriedem | keys prefixed with image_ | |
| 15:50:08 | mriedem | artom: https://github.com/openstack/nova/blob/master/nova/utils.py#L870 | |
| 15:50:27 | mriedem | the ImageMeta object would be serialized and stored in the RequestSpec as well like dan said | |
| 15:50:47 | mriedem | launchpad.net is down, yikes | |
| 15:51:08 | efried | who needs it | |
| 15:51:14 | artom | mriedem, ah, thanks, I wasn't seeing what I wanted in my devstack because (obviously) a key doesn't appear unless it's actually set | |
| 15:51:21 | sean-k-mooney | mriedem: its been a while since that happened last | |
| 15:51:27 | dansmith | mriedem: and only a few keys though right? | |
| 15:51:46 | lyarwood | sean-k-mooney: kk, IMHO yes it should, we've already backported it downstream for 15 | |
| 15:52:01 | mriedem | dansmith: i think you're thinking of these https://github.com/openstack/nova/blob/master/nova/utils.py#L72 | |
| 15:52:05 | sean-k-mooney | lyarwood: well it backport upstream for stien | |
| 15:52:12 | dansmith | mriedem: right | |
| 15:52:40 | mriedem | i don't think that's all though | |
| 15:52:41 | mriedem | https://github.com/openstack/nova/blob/master/nova/utils.py#L874 | |
| 15:53:00 | sean-k-mooney | KeithMnemonic: but if lyarwood is ok with it then maybe just propose the backport and people can review | |
| 15:53:09 | mriedem | it stores all the image properties (except the bdm ones), | |
| 15:53:16 | mriedem | but only stores a few of the top-level image fields | |
| 15:53:19 | dansmith | mriedem: ah, all the properties but not all the image keys | |
| 15:53:21 | mriedem | right | |
| 15:53:22 | dansmith | gotcha | |
| 15:53:35 | sean-k-mooney | mriedem: https://launchpad.net/nova seam to be fine by the way so maybe refesh | |
| 15:53:41 | mriedem | if only we had a gd docstring on that method to expedite the re-learning of that code :P | |
| 15:54:30 | mriedem | sean-k-mooney: maybe if you're in ireland | |
| 15:55:35 | sean-k-mooney | blame comcast/twc/other-isp but ya im obviously getting routed to a different server | |
| 15:55:39 | jangutter | mriedem: well here in South Africa it also seems to work.... Maybe east of the Atlantic? | |
| 15:55:48 | artom | mriedem, dansmith, thanks again! This was for a weird unsupported support request downstream, so I'm not even sure why I spent so much time on it | |
| 15:55:55 | artom | But... good to know they're all over place, I guess :D | |
| 15:56:51 | mriedem | artom: i look forward to your spec for whatever the nutty customer request is | |
| 15:57:07 | mriedem | maybe an api to change the embedded instance image system metadata? | |
| 15:57:08 | artom | DWIM all the time, everytime | |
| 15:57:34 | artom | mriedem, that's... actually pretty spot on | |
| 15:57:44 | artom | And if it can hard reboot the instance as well, after, it's be perfect | |
| 15:57:45 | mriedem | it wouldn't be the first time | |
| 15:58:04 | mriedem | heh, sure | |