| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-24 | |||
| 13:53:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_quota_sets' functional tests https://review.opendev.org/684334 | |
| 13:53:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_server_tags' functional tests https://review.opendev.org/684335 | |
| 13:53:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_servers' functional tests https://review.opendev.org/684336 | |
| 13:53:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_hosts' functional tests https://review.opendev.org/684337 | |
| 13:53:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_networks_associate' functional tests https://review.opendev.org/684338 | |
| 13:53:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_rescue' functional tests https://review.opendev.org/684339 | |
| 13:53:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_hypervisors' functional tests https://review.opendev.org/684340 | |
| 13:53:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_attach_interfaces' functional tests https://review.opendev.org/684341 | |
| 13:53:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_simple_tenant_usage' functional tests https://review.opendev.org/684342 | |
| 13:53:51 | mriedem | efried: it's normally not tracked as a blueprint, but one could argue that there should be a blueprint tracking a compute and compute task api (conductor) rpc api major version bump in ussuri since i think in the last few weeks we've identified a lot of cruft that needs to be cleaned out | |
| 13:55:02 | dansmith | mriedem: afaik, pretty much | |
| 13:56:27 | efried | mriedem: Why have a blueprint if there's not normally a blueprint? | |
| 13:56:43 | mriedem | efried: to track it and make it a priority | |
| 13:56:54 | mriedem | last time we had a major compute rpc api bump was queens | |
| 13:57:04 | mriedem | and never for the conductor compute task api | |
| 13:57:23 | mriedem | for example, there is cells v1 stuff in conductor that we can't remove without that | |
| 13:57:30 | mriedem | well, we can, but not in good conscience | |
| 13:58:10 | mriedem | anyway, just an idea | |
| 13:58:26 | mriedem | i'm not sure i trust myself to do that properly so i'm not necessarily signing up for the work either | |
| 13:59:14 | efried | I'm still stuck on the part where having a blueprint does anything to make something a priority. | |
| 14:00:17 | mriedem | blueprints are historically how we herd cats in nova since we're not using storyboard | |
| 14:00:20 | dansmith | so we can track the work against a milestone? | |
| 14:00:21 | mriedem | if there is another better way, sure | |
| 14:00:46 | mriedem | random etherpad o wishlist is an option, but those generally don't go well and aren't indexable | |
| 14:01:14 | mriedem | or a bug, "nova's rpc interfaces for compute related stuff are crusty" | |
| 14:03:03 | efried | stephenfin: speaking of, do we have a bp for nova-net removal? | |
| 14:03:23 | stephenfin | I've just grabbed remove-nova-network | |
| 14:03:55 | stephenfin | ...which already exists. Damn you, Riedemann | |
| 14:04:30 | bauzas | efried: do you want to wait until tomorrow for +Wing https://review.opendev.org/#/c/683327/ ? | |
| 14:04:33 | efried | remove-nova-network-freal? | |
| 14:04:36 | bauzas | mriedem: thanks for the PS3 | |
| 14:04:38 | sean-k-mooney | related to that i was wondering if we should also move the neutron related code in nova/network to os-vif and load via the exsitsing driver mechanis | |
| 14:04:47 | efried | bauzas: I really just want more people to look at it | |
| 14:04:54 | stephenfin | remove-nova-network-redux ? | |
| 14:05:05 | bauzas | efried: ack | |
| 14:05:20 | bauzas | dansmith: stephenfin: https://review.opendev.org/#/c/683327/ if you want to look at the prelude | |
| 14:05:25 | sean-k-mooney | but thats just something im toying with. | |
| 14:05:53 | efried | alex_xu, luyao: since it mentions vpmem | |
| 14:05:53 | efried | aspiers: since it mentions SEV | |
| 14:05:53 | efried | gmann: to make sure we don't need to call out anything specific about API updates | |
| 14:05:53 | efried | More cores. | |
| 14:05:56 | bauzas | melwitt: if you want to also look at the prelude https://review.opendev.org/#/c/683327/ (once you're there) | |
| 14:06:16 | mriedem | stephenfin: remove-nova-network-ussuri | |
| 14:06:24 | mriedem | is the pattern when we have a blueprint that spans releases | |
| 14:06:29 | mriedem | see the mox removal bp | |
| 14:07:26 | aspiers | efried: struggling to regain contact here, what mentions SEV? | |
| 14:07:30 | aspiers | s/contact/context/ | |
| 14:07:35 | mriedem | efried: for https://review.opendev.org/#/c/680300/ who reviewed the vpmem series besides you and alex_xu that can approve that? stephenfin? | |
| 14:07:49 | efried | yes | |
| 14:07:50 | mriedem | aspiers: both, highlights and release notes | |
| 14:07:52 | stephenfin | mriedem: how come we do that? purely so we don't have blueprints that span multiple releases? | |
| 14:08:02 | efried | aspiers: https://review.opendev.org/#/c/683327/ release prelude | |
| 14:08:18 | mriedem | stephenfin: how come we have a -<release> suffix pattern for bp naming as a convention? | |
| 14:08:22 | stephenfin | yup | |
| 14:08:23 | efried | I think highlights already merged and you looked at 'em. | |
| 14:08:34 | mriedem | stephenfin: because we sometimes have blueprints that...span releases | |
| 14:08:39 | mriedem | and a naming convention is nice | |
| 14:08:49 | sean-k-mooney | mriedem: we dont alway do that. we only do it if some of the blueprint was merged in the cycle right | |
| 14:08:56 | efried | I'm going to guess it's not documented anywhere, just grew out organically over time. | |
| 14:08:58 | gmann | efried: you mean in this - https://review.opendev.org/#/c/683327 | |
| 14:09:00 | stephenfin | yeah, but I'm saying we can't just have that blueprint span multiple cycles? | |
| 14:09:05 | efried | gmann: yes | |
| 14:09:06 | sean-k-mooney | if it was just defereed we keep the same blueprint | |
| 14:09:20 | aspiers | efried: IIRC I wrote that text | |
| 14:09:22 | mriedem | stephenfin: b/c we've marked some as partially complete when they've had some non-trivial amount of work merged | |
| 14:09:34 | mriedem | stephenfin: generally blueprints that are more mechanical in nature | |
| 14:09:38 | mriedem | house cleaning and such | |
| 14:09:51 | dansmith | stephenfin: launchpad doesn't allow a blueprint to be targeted twice | |
| 14:09:53 | efried | aspiers: cool, so just make sure you were quoted appropriately, and that the text is still appropriate for a reno prelude (as opposed to market-y cycle highlights) and we're good | |
| 14:09:55 | mriedem | not something like cross-cell-resize am i going to say "partially complete in train b/c i landed some data migrations" | |
| 14:10:20 | dansmith | stephenfin: so pointing it at a release lets us mark that some work was done there, for writing the highlights, and then more gets done in that the next cycle | |
| 14:10:23 | aspiers | efried: I guess it was copied there from some other review I was involved in? | |
| 14:10:40 | aspiers | ah yes, https://review.opendev.org/#/c/681943/ | |
| 14:12:00 | stephenfin | dansmith: aha, fair | |
| 14:15:37 | gmann | efried: lgtm. 'API Improvements' section is enough for API updates. there is no specific API things need separate highlight. | |
| 14:16:07 | efried | thanks for the look gmann | |
| 14:16:34 | mriedem | aspiers: that's already noted in the commit message | |
| 14:24:57 | KeithMnemonic | good day mriedem. quick question on all of those patches related to https://bugs.launchpad.net/nova/+bug/1469179 it seems everything made it down to rocky other than https://review.opendev.org/#/c/551026/ is there any issue in me trying to also backport this to Rocky? | |
| 14:24:57 | openstack | Launchpad bug 1469179 in OpenStack Compute (nova) "instance.root_gb should be 0 for volume-backed instances" [Medium,Fix released] - Assigned to Dan Smith (danms) | |
| 14:25:02 | kashyap | sean-k-mooney: Hey, on that 'strict' vs. 'preferred' thing for NUMA allocation from the downstream bug - if we change to 'preferred', we'd be "deviating" from libvirt's default of 'strict' | |
| 14:25:20 | kashyap | sean-k-mooney: Not that it's some "blasphemy"; but I'd like to understand why libvirt defaults to it | |
| 14:25:48 | mriedem | KeithMnemonic: heh yes | |
| 14:26:10 | sean-k-mooney | it defualt to stict in numatune because if you said you want to tune the numa memory it makes sense to default to strict | |
| 14:26:24 | sean-k-mooney | given by default numa tune is not used and no tuning is used | |
| 14:26:50 | sean-k-mooney | so you are already opting into affinty by generating the numatune elements | |
| 14:26:58 | KeithMnemonic | mriedem yes there is an issue? or yes i can try and backport it ? | |
| 14:27:15 | mriedem | KeithMnemonic: you basically asked if it's ok to backport something from train that removed something that was deprecated in stein, and has nothing to do with rocky | |
| 14:27:32 | mriedem | i know suse is super in love with rocky | |
| 14:27:35 | mriedem | but... | |
| 14:28:01 | kashyap | sean-k-mooney: I'm NUMA-unaware, so afraid, I still can't parse _why_ libvirt defaults to 'strict' | |
| 14:28:17 | kashyap | (Or weakly-aware) | |
| 14:28:33 | KeithMnemonic | oh i see, filters were deprecated in stein | |
| 14:28:39 | kashyap | sean-k-mooney: Please rephrase, if you can... | |
| 14:28:42 | KeithMnemonic | https://review.opendev.org/#/c/596502/ | |
| 14:28:57 | mriedem | correct | |
| 14:28:59 | sean-k-mooney | kashyap: by default you do not specify numatune elements. so by defualt libvirt does not enforce strict affinity | |
| 14:29:01 | KeithMnemonic | so at a minimum it would make sense to put this to stein as well if someone needed it? | |
| 14:29:09 | kashyap | sean-k-mooney: Aah, like that! | |
| 14:29:37 | mriedem | KeithMnemonic: put what? https://review.opendev.org/#/c/551026/ in stein? | |
| 14:29:40 | sean-k-mooney | kashyap: when you therefor add the numatune element it makes sense for it to default to strcit since you ar opting out of the default behavior of no tuneing | |