| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-06 | |||
| 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 | |
| 15:45:39 | artom | Dammit, we store image_meta in the DB somewhere, right? | |
| 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 | |
| 15:58:19 | sean-k-mooney | artom: so a rebuild without actully updating the root disk | |
| 15:58:22 | mriedem | "i f'ed up the image properties on the image this pet is using, i need to fix those but can't lose the server and can't rebuild it" | |
| 15:58:33 | fungi | mriedem: lp is loading for me... temporary outage? | |
| 15:58:57 | artom | sean-k-mooney, something like that | |
| 15:59:06 | sean-k-mooney | artom: let me guess the updated the metadata on the image and added somthign that change scheduling behavior and then were suprised when non of there old instance had the new behavior | |
| 15:59:20 | artom | sean-k-mooney, no, they want TRIM | |
| 15:59:29 | artom | So need the correct magic disk model/bus imageprops | |
| 16:00:01 | artom | Because TRIM is no longer just for SSDs: https://ceph.com/geen-categorie/openstack-and-ceph-rbd-discard/ <--- that bit is actually genuinely interesting | |
| 16:00:01 | sean-k-mooney | ok so its effectivly the same thing without the schduliing bit | |
| 16:00:40 | mriedem | fungi: must be something weird on my end then but nope still can't access | |
| 16:00:44 | sean-k-mooney | they want to add the disk_bus=scsi imemage meta and enable virtio-scisis as the scsi model | |
| 16:00:58 | artom | mriedem, you're cut off, forced PTO | |
| 16:01:13 | sean-k-mooney | but they want to apply that chagne to existing instances too | |
| 16:01:14 | mriedem | sweet release | |
| 16:01:31 | artom | sean-k-mooney, yeah, we have a KCS for it: https://access.redhat.com/solutions/2532341 | |
| 16:01:45 | artom | ... which explicitly states "it is not possible to change existing VMs configuration." | |
| 16:01:54 | mriedem | artom: then tell them to snapshot their existing servers, add the image meta they want on the snapshots, and re-deploy | |
| 16:01:57 | sean-k-mooney | well without a rebuild | |
| 16:02:01 | sean-k-mooney | but ya | |
| 16:02:12 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule https://review.opendev.org/649963 | |
| 16:02:14 | mriedem | or rebuild if they don't want to lose keys/uuids/ips whatever | |
| 16:02:23 | jangutter | artom: OpenStack Icehouse got referenced in that article! | |
| 16:02:37 | artom | mriedem, yeah, not sure why a rebuild isn't acceptable | |
| 16:02:41 | fungi | mriedem: yeah, maybe a network problem somewhere then, but it's still working for me (just tried again) | |
| 16:02:50 | sean-k-mooney | and ya trim is used with ceph and lvm thin provisioning to tell the storage backend it can use those blocks for other oversubsried images | |
| 16:02:51 | artom | I guess they forgot to volume-back their valuable pet disks | |
| 16:02:53 | mriedem | artom: b/c it will blow away the root disk | |
| 16:03:01 | mriedem | artom: you can't rebuild + new image on volume-backed servers | |