Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-06
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
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 sean-k-mooney ok so its effectivly the same thing without the schduliing bit
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: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

Earlier   Later