Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-02-11
16:36:06 lyarwood gmann: how clean is it on stable/victoria ?
16:36:49 lyarwood gmann: I personally don't mind if it gives us a passing branch in-line with the later releases tbh, my only concern would be if we need to fixup more code across the tree to land it
16:36:50 gmann lyarwood: basically fixing the hacking 4.0.0 checks. so some code style change
16:37:12 lyarwood gmann: yeah if they are limited to the same or just a few more then I'm fine
16:37:29 dansmith also seems okay to me.. we don't want to be bumping the requirements on stable, but this is just for our own tooling/testing I think,
16:37:43 dansmith and distros really have to do their own version mappings anyway
16:37:58 dansmith gmann: how about a reno to highlight the change and reasoning?
16:38:05 dansmith in the backport
16:38:35 gmann ok, that make sense. usually we do not need to bump hacking in stable but these version conflict made us to do
16:54:37 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: Fix l-c job and move to latest hacking 4.0.0 https://review.opendev.org/c/openstack/placement/+/775214
16:57:25 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: Fix l-c job and move to latest hacking 4.0.0 https://review.opendev.org/c/openstack/placement/+/775214
17:02:20 elod gmann: ++ \o/
17:04:55 gibi lyarwood: I have feedback in https://review.opendev.org/c/openstack/os-traits/+/759878
17:05:16 lyarwood stephenfin: re https://review.opendev.org/c/openstack/nova/+/772271 - stupid question, that didn't replace the instance.name, just the instance.hostname right?
17:05:37 stephenfin lyarwood: correct. Display name isn't affected
17:05:53 lyarwood kk well dansmith has voted now anyway so we can close this out
17:06:22 lyarwood gibi: looking
17:07:08 dansmith lyarwood: what about what I said is related to display vs hostname?
17:08:36 lyarwood dansmith: nothing but the arguments you put forward suggested that you thought the impact of this landed outside of just instance.hostname that AFAIK is something we only expose through the metadata API
17:12:41 lyarwood ah nvm it's in our show server response, ignore me if you weren't already
17:15:35 openstackgerrit Lee Yarwood proposed openstack/os-traits master: Add COMPUTE_EPHEMERAL_ENCRYPTION tratis https://review.opendev.org/c/openstack/os-traits/+/759878
17:16:53 openstackgerrit Merged openstack/os-traits master: Add COMPUTE_SOCKET_PCI_NUMA_AFFINITY trait https://review.opendev.org/c/openstack/os-traits/+/771705
17:24:32 openstackgerrit Merged openstack/os-traits master: Add a trait for UEFI Secure Boot support https://review.opendev.org/c/openstack/os-traits/+/770570
17:33:36 dansmith lyarwood: heh okay
17:33:59 dansmith lyarwood: it's still visible to the user of the instance in a variety of ways, not just the API, but yeah
17:34:35 dansmith lyarwood: back to that volumes quota thing, were you asserting that the qemu monitor reset was related to the inability to create a volume on the glance side?
17:36:41 lyarwood dansmith: no just that the QEMU monitor issue was unrelated to the actual test failure that failed the overall job
17:37:41 lyarwood dansmith: iirc it's a ipv6 test spawned that instance and it looks like the monitor issue was during cleanup and ignored
17:37:52 lyarwood ipv6 test that spawned*
17:38:49 dansmith ah okay I filed separately because they were separate, so you're just saying that's a known problem? I've seen it before obviously, but haven't in a while and since it was stable rescue, I thought maybe it was related to disk attachments
17:41:20 lyarwood dansmith: I've not seen an EOF from the monitor while detaching a nic recently
17:41:47 lyarwood dansmith: and again to be clear, that trace and the failed test are separate
17:42:08 dansmith yeah I get that
17:42:32 lyarwood kk well we can use this bug for the monitor part as you already have one for the quota bit
17:42:50 dansmith right, gibi commented on the monitor bug saying it was being tracked in the quota bug
17:43:02 lyarwood oh really?
17:43:08 dansmith so just wanted to makes ure
17:43:31 lyarwood ah cool I see sorry
17:43:31 dansmith oh, sorry sorry, you're just saying I called out the wrong test, I see
17:44:20 lyarwood yup indeed, AttachInterfacesTest is what we want to list, I've updated the subject
17:44:25 dansmith in my mind I had moved past that with the quota bug and fix, but i see what you mean about the title on the other.. the trace is the important thing
17:44:26 dansmith yep, gotcha
17:54:48 lyarwood dansmith: ah weird, so it looks like something didn't wait for the nic to detach before deleting the instance
17:55:15 dansmith ah, I guess that would explain the lack of fail
17:55:29 lyarwood dansmith: the EOF monitor error comes out of a request to handle a network-vif-deleted:064543b1-709d-445f-b852-98b59f977aed event from neutron
17:55:34 dansmith kinda sucks to barf something that serious into the logs if we're just nuking the instance underneath
17:55:41 lyarwood dansmith: and right after that n-api gets a DELETE request for the server
17:55:53 dansmith maybe we could ignore if the instance is deleted when we get that error?
17:56:08 dansmith or log.warn instead of EXPLODE
17:58:15 lyarwood dansmith: https://github.com/openstack/nova/blob/fec44e5d38baa0232bf41367303b82dc332eb512/nova/compute/manager.py#L7778-L7790 looks like we try to log at DEBUG in that case but didn't in this instance
17:58:43 lyarwood oh because it's looking at the exception and not checking if the instance is around still
18:00:46 dansmith yeah, so it probably does that right if we triggered the NotFound as a result of pulling up info on the instance,
18:01:04 dansmith but if we failed because its been nuked, we should refresh our world view before we decide who to wake up
18:01:50 dansmith although it's logging a trace, but I don't see it passing the exc_info there
18:03:48 lyarwood need to run and help put a baby to bed, I'll try and finish writing this up before I call it for the day
18:11:55 openstackgerrit Merged openstack/python-novaclient master: Uncap PrettyTable https://review.opendev.org/c/openstack/python-novaclient/+/775143
18:12:05 openstackgerrit Merged openstack/python-novaclient master: requirements: Remove simplejson https://review.opendev.org/c/openstack/python-novaclient/+/775144
20:34:30 sean-k-mooney lyarwood: can you take a look at https://review.opendev.org/c/openstack/nova/+/759522 and https://review.opendev.org/c/openstack/nova/+/759151
20:35:09 sean-k-mooney elod: if you could take a look too that would be great that has to go back to train
20:35:48 sean-k-mooney victoria is merged so ussuri is up next
20:36:19 sean-k-mooney there are a few people askinf for this on the bug https://bugs.launchpad.net/nova/+bug/1888395
20:36:22 openstack Launchpad bug 1888395 in OpenStack Compute (nova) ussuri "live migration of a vm using the single port binding work flow is broken in train as a result of the introduction of sriov live migration" [High,In progress] - Assigned to Billy Olsen (billy-olsen)
20:55:26 openstackgerrit Merged openstack/nova master: db: Compact Stein database migrations https://review.opendev.org/c/openstack/nova/+/759090
20:58:28 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: Fix l-c job and move to latest hacking 4.0.0 https://review.opendev.org/c/openstack/placement/+/775214
20:58:37 elod sean-k-mooney: sure, added to my TODOs, will look into it tomorrow
23:01:40 openstackgerrit Dan Smith proposed openstack/nova master: Make a couple test jobs run async devstack https://review.opendev.org/c/openstack/nova/+/775293
23:22:30 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: Fix l-c job and move to latest hacking 4.0.0 https://review.opendev.org/c/openstack/placement/+/775214
#openstack-nova - 2021-02-12
01:03:48 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: DNM: testing https://review.opendev.org/c/openstack/placement/+/775303
01:24:55 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: DNM: testing https://review.opendev.org/c/openstack/placement/+/775303
01:37:32 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: Fix l-c job and move to latest hacking 4.0.0 https://review.opendev.org/c/openstack/placement/+/775214
02:34:41 openstackgerrit melanie witt proposed openstack/nova master: Add regression test for bug 1914777 https://review.opendev.org/c/openstack/nova/+/775307
02:34:42 openstackgerrit melanie witt proposed openstack/nova master: WIP Differentiate between InstanceNotFound and ConstraintNotMet https://review.opendev.org/c/openstack/nova/+/775309
02:34:42 openstackgerrit melanie witt proposed openstack/nova master: Handle instance = None in _local_delete_cleanup https://review.opendev.org/c/openstack/nova/+/775308
02:34:42 openstack bug 1914777 in OpenStack Compute (nova) "Possible race condition between n-cpu and n-api when deleting a building instance" [High,In progress] https://launchpad.net/bugs/1914777 - Assigned to melanie witt (melwitt)
02:52:19 gmann dansmith: lyarwood elod gibi placement stable/victoria is green now, added releasenote also for backporting the pep8 changes- https://review.opendev.org/c/openstack/placement/+/775214
02:52:56 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: Update TOX_CONSTRAINTS_FILE for stable/victoria https://review.opendev.org/c/openstack/placement/+/754671
10:52:06 bauzas gibi: stephenfin: while I'm on things I call unnecessary but asked, I tho wonder how to say "it's an UUID parameter" and not just "it's a string" ?
10:52:31 bauzas context : https://review.opendev.org/c/openstack/nova/+/773976/5/nova/network/neutron.py@3491 for the neutron_id
10:54:13 gibi bauzas: network_id is a uuid printed to as string. If it would be an instance of uuid.UUID from the standard lib then you can say network_id: uuid.UUID
10:54:48 gibi bauzas: think about it as C++ type. if there you have a string that contains a uuid you still use the type string for it
10:54:51 bauzas meh
10:55:30 gibi bauzas: it is nova's decision to pass around string instead of uuid.UUID objects internallyt
10:55:43 bauzas I love python for some stuff, and the fact that we wouldn't need to tell 'heh, it's a string'
10:56:30 bauzas https://realpython.com/lessons/duck-typing/
10:57:12 bauzas if it looks like a UUID, and if you use it for a UUID, then it's a UUID
10:58:14 gibi what we pass around is a string representation of an UUID . If some code would threat it as uuid.UUID and call .fields on it, the code will fail with AttributeError
10:58:43 gibi python still enforce types :)
10:59:48 bauzas that's the reason why we have code reviews and docstrings... but the ship sailed eitherway
11:00:31 bauzas I'm just a bit sad we hadn't discussed it in a PTG session
11:00:32 gibi and we still have code review and doc string in the future, mypy just help with that review by automating some part of it
11:00:44 bauzas before telling to use mypy
11:00:49 gibi bauzas: we discussed it in some point and was no consensus
11:01:02 gibi so as a nova project we don't tell you that you have to use mypy
11:01:11 gibi it is stephenfin who asks it
11:01:14 bauzas well, here I'm asked to do it :)
11:01:50 gibi can I forbid stephenfin to ask such thing? No I don't think so
11:02:12 gibi what I can say that it is not mandatory to add mypy type hint to your patch
11:02:22 gibi as we never decided to make it mandatory
11:02:23 bauzas do we also want to use type hints for private methods ?
11:03:59 gibi in my eyes the benefit of mypy (if any) applies equally on private and public too

Earlier   Later