| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-24 | |||
| 09:05:31 | openstackgerrit | Arthur Dayne proposed openstack/nova master: Fix block disk attachment failure https://review.opendev.org/682772 | |
| 09:16:48 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Move HostNameWeigher to a common fixture https://review.opendev.org/683874 | |
| 09:59:11 | tellesnobrega | hi folks, is there a way from nova to check state of instances and update db if it detects that an instance is not running anymore? | |
| 10:00:13 | tellesnobrega | I saw the reset-state command but wanted to make sure it does what I'm looking for | |
| 11:54:57 | openstackgerrit | Jacek Tomasiak proposed openstack/nova master: Ensure volume filesystems are mounted on resume https://review.opendev.org/684290 | |
| 12:07:16 | gibi | bauzas: left comments and a bug report in https://review.opendev.org/#/c/670112 | |
| 12:11:03 | cdent | gibi: you have a theory about what's going wrong there? | |
| 12:11:47 | gibi | cdent: not yet but I can dig in if needed | |
| 12:12:07 | cdent | no, I was just curious if anything obvious stuck out. and was very happy to see you testing it with real stuff | |
| 12:12:18 | cdent | presumably better functional tests is needed | |
| 12:21:34 | gibi | cdent: I have one commment about context targeting when querying instances from the db that could be the reason | |
| 12:28:57 | gibi | cdent: yeah something with the db access is problematic as the script does not even found the compute node. I guess it querying from the wrong cell db | |
| 12:42:24 | bauzas | gibi: thanks for the comments, as great as usual ;) | |
| 12:42:45 | bauzas | gibi: I'll first write the last functional test and then I'll look at your comments | |
| 12:43:17 | gibi | bauzas: sure. If you need me to re-run the test with more logs or a differnet patch set just let me know | |
| 12:43:41 | gibi | bauzas: or I can provide my devstack conf to test with bandwidth allocation | |
| 12:44:31 | bauzas | gibi: well, why not testing it for bandwith allocations | |
| 12:44:46 | bauzas | gibi: the main issue is that we need also to check child allocations | |
| 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 | |