| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-11 | |||
| 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 | |
| 11:04:09 | stephenfin | bauzas: You're misstating what I asked. I suggested adding type hints, but I was very clear that they weren't mandatory | |
| 11:04:28 | bauzas | anyway, I'm adding them | |
| 11:04:37 | stephenfin | Please don't say I'm forcing you into anything wrt mypy because it's not true | |
| 11:04:57 | bauzas | ack | |
| 11:05:35 | stephenfin | "Code itself is fine, but I do question the wisdom of throwing these into the utils modules and I don't like reinventing the wheel and doing something neutronclient appears to support. The -1 is for the latter. I'd also like to see type hints and have provided them for you, but I can't force than on you of course 😄" | |
| 11:05:45 | stephenfin | from https://review.opendev.org/c/openstack/nova/+/773976/5 | |
| 11:06:30 | bauzas | oki, then I'm trying to use the neutron client method | |
| 11:06:32 | stephenfin | And we did discuss this at a PTG and as gibi said, there was no consensus. We said we could add them if we wanted but they weren't mandatory | |
| 11:06:47 | bauzas | which is a good call | |