| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-24 | |||
| 13:27:01 | mriedem | artom: https://bugs.launchpad.net/nova/+bug/1845146 this is a known issue right? | |
| 13:27:01 | openstack | Launchpad bug 1845146 in OpenStack Compute (nova) "NUMA aware live migration failed when vCPU pin set" [Undecided,New] | |
| 13:30:49 | artom | mriedem, no, that's the thing that Ya was testing | |
| 13:31:17 | artom | mriedem, http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009608.html | |
| 13:31:55 | artom | I'm gonna look at his logs today, but initial instinct is there's a race somewhere | |
| 13:36:30 | efried | dansmith: Please review this RC candidate with RPC in the title and one +2 from mriedem: https://review.opendev.org/#/c/683948/ | |
| 13:37:05 | dansmith | ah cool, we're on to approving actual bugs during this bug phase? | |
| 13:44:44 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/stein: Add reno about nova-api eventlet monkey-patching and rabbitmq https://review.opendev.org/662095 | |
| 13:45:19 | dansmith | mriedem: so on that gibi rpc version patch... | |
| 13:45:55 | dansmith | mriedem: we often gate features on service version, especially when they have API impacts, which is cool, and this is kinda like that | |
| 13:46:33 | dansmith | however, one could take a more RPC-centric world view and say that "if the RPC version allows it I should send it", meaning if they're not set =auto or =stein, they're asking us to send the newer thing | |
| 13:46:53 | dansmith | which could be useful if you're trying to get migrated off the last few computes, or something like that, | |
| 13:47:20 | dansmith | although it could cause problems for *other* calls that might be too new, and/or if you scheduled to an old one but don't have your rpc version pinned properly | |
| 13:47:31 | mriedem | you mean if upgrade_levels=train or =5.3? | |
| 13:47:39 | dansmith | yeah | |
| 13:49:14 | mriedem | out of curiosity, does tripleo actually pin to specific versions or release names during an upgrade or just use 'auto'? | |
| 13:49:24 | mriedem | because osa uses auto and doesn't allow you to override it https://github.com/openstack/openstack-ansible-os_nova/blob/3d99b2bd80287a3dd7cd35eb7075b80535f9ce42/templates/nova.conf.j2#L273 | |
| 13:49:54 | dansmith | I dunno, I both suspect they default to auto and also let you override it to something else | |
| 13:50:09 | dansmith | however,I think that you *can* do a gradual upgrade with tripleo, but it's not the default IIRC | |
| 13:50:15 | dansmith | so it likely doesn't matter as much to them | |
| 13:50:20 | dansmith | at least in the kinda default case | |
| 13:50:53 | dansmith | like, I think that if you're doing a piecemeal upgrade, you have to do a stack update each time you roll any compute forward, which touches everything, so it's not worth it, or something like that | |
| 13:52:16 | mriedem | do most tripleo (private cloud) deployments just do a full down maintenane upgrade rather than rolling then? | |
| 13:53:01 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate some API sample tests off of nova-net https://review.opendev.org/684325 | |
| 13:53:02 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Use nova-net explicitly in '_IntegratedTestBase' subclasses https://review.opendev.org/684326 | |
| 13:53:02 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove unnecessary 'USE_NEUTRON = False' https://review.opendev.org/684327 | |
| 13:53:03 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Use nova-net explicitly in 'ApiSampleTestBase' subclasses https://review.opendev.org/684328 | |
| 13:53:03 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove yet more unnecessary 'USE_NEUTRON = False' https://review.opendev.org/684329 | |
| 13:53:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Disable neutron explicitly for 'ServersSampleBase' subclasses https://review.opendev.org/684330 | |
| 13:53:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove *even* more unnecessary 'USE_NEUTRON = False' https://review.opendev.org/684331 | |
| 13:53:05 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_availability_zone' functional tests https://review.opendev.org/684332 | |
| 13:53:05 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Migrate 'test_floating_ip_pools' functional tests https://review.opendev.org/684333 | |
| 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 | |