Posted	Nick	Remark
#openstack-nova - 2019-09-24
00:22:04	openstackgerrit	Merged openstack/nova master: Functional reproduction for bug 1844993 https://review.opendev.org/683947
00:22:05	openstack	bug 1844993 in OpenStack Compute (nova) "migrate a server with qos port with compute RPC pinned to 5.1 fails and leaves the qos port in an inconsistent state" [High,In progress] https://launchpad.net/bugs/1844993 - Assigned to Balazs Gibizer (balazs-gibizer)
00:28:39	openstackgerrit	Sundar Nadathur proposed openstack/nova-specs master: Re-proposed Nova Cyborg interaction specification. https://review.opendev.org/682637
00:28:40	openstackgerrit	Sundar Nadathur proposed openstack/nova-specs master: Updated Nova-Cyborg interaction spec. https://review.opendev.org/684151
02:36:23	openstackgerrit	Merged openstack/nova master: Add librsvg2* to bindep https://review.opendev.org/683003
02:41:12	openstackgerrit	Takashi NATSUME proposed openstack/nova stable/rocky: Replace glance command with openstack command https://review.opendev.org/637060
08:13:41	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Reject migration with QoS port from conductor if RPC pinned https://review.opendev.org/683948
08:49:14	openstackgerrit	Arthur Dayne proposed openstack/nova master: Fix block disk attachment failure https://review.opendev.org/682772
08:49:53	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Remove upgrade specific info from user facing exception text https://review.opendev.org/684253
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.

Earlier   Later