Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-06
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 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

Earlier   Later