| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-24 | |||
| 16:11:04 | bauzas | not the service version we discover based on the pin | |
| 16:11:09 | stephenfin | *the '_ver' method | |
| 16:11:40 | bauzas | the _ver method is temporary | |
| 16:12:00 | bauzas | just to avoid reproducing dumb checks | |
| 16:12:38 | bauzas | that's the pattern we used in the past bumps and I shamelessly reproduced it | |
| 16:13:08 | dansmith | patterns are good :) | |
| 16:13:16 | bauzas | provided people understand them. | |
| 16:14:06 | dansmith | stephenfin: you also want to change the client signature to use flavor too, I'm sure | |
| 16:14:20 | stephenfin | I don't think so. Not yet | |
| 16:14:26 | stephenfin | Keep it small | |
| 16:14:27 | dansmith | why? | |
| 16:14:42 | stephenfin | That's v. easy fix in a follow-up | |
| 16:15:02 | stephenfin | I mean I can but it's more test damage | |
| 16:15:07 | bauzas | right | |
| 16:15:10 | dansmith | well, that's the point here | |
| 16:15:15 | bauzas | some methods pass kwargs | |
| 16:15:27 | bauzas | then, you're dommed | |
| 16:15:29 | bauzas | doomed* | |
| 16:15:32 | dansmith | either we're going for consistency or we aren't right? | |
| 16:18:12 | stephenfin | *eventual consistency | |
| 16:18:22 | stephenfin | I can change the other things whenever. I can only change this right now | |
| 16:18:42 | stephenfin | and I have the follow-up ready. I just don't think it's wise to merge it right now since it's huge | |
| 16:21:07 | dansmith | well, my opinion is that this is all just naming and not useful for paying down any real debt (like deprecated parameters) so I'd vote to just punt on it anyway | |
| 16:24:21 | bauzas | the other problem I see is with the gate | |
| 16:24:37 | bauzas | getting at least a grenade-multinode result | |
| 16:24:57 | dansmith | for sure we need to see and scrutinize a grenade-multinode result at least | |
| 16:25:13 | bauzas | the good thing is that both prep_resize and resize_instance() are tested IIRC | |
| 16:31:45 | bauzas | I have to stop now as I need to taxi my daughter to some doctor's appointment | |
| 16:31:53 | bauzas | but I can be back later on in the evening | |
| 16:36:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: DNM: Rename 'instance_type' parameter https://review.opendev.org/c/openstack/nova/+/782804 | |
| 16:48:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: rpc: Rename 'instance_type' client argument https://review.opendev.org/c/openstack/nova/+/782825 | |
| 16:48:49 | stephenfin | dansmith: A'ight, there's the client change ^ Pretty simple after all. I think I'd still keep it separate but we could squash it in if we wanted to | |
| 16:49:40 | stephenfin | Also, for the previous patch, there doesn't appear to have been a test for backleveling of 'prep_resize' so we might want to adding that as a follow-up even if we don't do this (it seems to be working fine, thankfully, based on the test) | |
| 16:50:55 | stephenfin | I realize it doesn't ultimately matter, but when it's this easy I really do think we should be including this. It'd mean we're just left with some DB/o.vo references to instance types. I could live with those | |
| 17:57:55 | stephenfin | oh, lovely http://paste.openstack.org/show/803882/ | |
| 17:58:11 | stephenfin | creating a resource provider on placement with a duplicate name results in a HTTP 5xx | |
| 17:59:27 | melwitt | amazed that hasn't been hit until now | |
| 17:59:52 | stephenfin | You and me both. That's super dumb | |
| 18:00:21 | melwitt | hehehe | |
| 18:00:58 | stephenfin | I won't be able to work on it today, but if anyone else has time the simple reproducer is to use microversion 1.20 and create a resource provider specifying only the name | |
| 18:01:24 | stephenfin | nope, don't even need the microversion | |
| 18:01:38 | stephenfin | $ openstack resource provider create foo; openstack resource provider create foo | |
| 18:01:46 | stephenfin | delightful | |
| 18:01:52 | melwitt | :) | |
| 18:02:31 | melwitt | that'd be easy to add to the gabbits I think | |
| 18:05:11 | stephenfin | for sure | |
| 18:05:16 | stephenfin | I'll take a look tomorrow, no doubt | |
| 18:05:24 | melwitt | kewl | |
| 18:55:27 | sean-k-mooney | we defintly have hit duplicte RPs before | |
| 18:55:41 | sean-k-mooney | but i tough that gave you a 4XX error | |
| 18:56:09 | sean-k-mooney | you get this if you rename a compute node and change its hostname or you delete the compute service and its created with a different uuid | |
| 18:56:34 | sean-k-mooney | sorry only the later case has the name conflcit | |
| 18:56:55 | sean-k-mooney | where you keep the same compute node hostname but delete the compute service and let it get recteated | |
| 18:57:10 | sean-k-mooney | the compute service uuid change but the RP name will be the same | |
| 18:58:54 | sean-k-mooney | stephenfin: melwitt we have test for that in placment already i think https://github.com/openstack/placement/blob/master/placement/tests/functional/gabbits/resource-provider-duplication.yaml | |
| 18:59:11 | sean-k-mooney | https://github.com/openstack/placement/blob/master/placement/tests/functional/gabbits/resource-provider-duplication.yaml#L30-L37 | |
| 18:59:19 | sean-k-mooney | same name different uuid | |
| 18:59:32 | sean-k-mooney | stephenfin: it shoudl return a 409 ^ | |
| 18:59:49 | sean-k-mooney | stephenfin: those test are 4 years old too | |
| 19:00:06 | sean-k-mooney | so something else is going on | |
| 19:00:45 | sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1693349 | |
| 19:00:49 | openstack | Launchpad bug 1693349 in OpenStack Compute (nova) "trying to create a resource provider with an already in use uuid causes misleading error" [Low,Fix released] - Assigned to Chris Dent (cdent) | |
| 19:02:17 | sean-k-mooney | stephenfin: fixed by https://review.opendev.org/c/openstack/nova/+/468928/ | |
| 19:02:31 | sean-k-mooney | stephenfin: where did you get that failure form ? | |
| 19:03:22 | sean-k-mooney | it was fixxed in nova in queens before placment was split out | |
| 20:41:05 | openstackgerrit | Erik Olof Gunnar Andersson proposed openstack/nova stable/rocky: Use subqueryload() instead of joinedload() for (system_)metadata https://review.opendev.org/c/openstack/nova/+/761813 | |
| 21:26:47 | melwitt | lyarwood: can't remember if I've linked you this gate bug I opened semi recently so if I didn't, fyi https://bugs.launchpad.net/openstack-gate/+bug/1919920 | |
| 21:26:49 | openstack | Launchpad bug 1919920 in OpenStack-Gate "volume related tests sometimes fail with "Could not open '/dev/sdb': Permission denied" on stable/(ussuri|train|stein)" [Undecided,New] | |
| 21:27:10 | melwitt | seeing it on stable | |
| #openstack-nova - 2021-03-25 | |||
| 00:18:49 | openstackgerrit | Ghanshyam proposed openstack/nova master: DNM: testing tempest scenario manager refactoring https://review.opendev.org/c/openstack/nova/+/782798 | |
| 01:22:12 | openstackgerrit | melanie witt proposed openstack/nova master: Add --task-log option to nova-manage db archive_deleted_rows https://review.opendev.org/c/openstack/nova/+/780395 | |
| 05:26:20 | openstackgerrit | Merged openstack/nova master: [Arm64][libvirt] Fix read bytes from json files https://review.opendev.org/c/openstack/nova/+/782634 | |
| 07:03:25 | openstackgerrit | melanie witt proposed openstack/nova master: Add --task-log option to nova-manage db archive_deleted_rows https://review.opendev.org/c/openstack/nova/+/780395 | |
| 07:42:07 | pawan-gupta_ | Hi, I am trying to use `adminPass` option in NOVA and using Train release. I have tried setting all options in NOVA.CONF related to this e.g. `inject_password`, `enable_instance_password`, etc. The Create Server API returns a adminPass but I am not able to login via that. When I logged into the instance via SSH key, I could see there is nothing for root password in `/etc/shadow` file as well. I am using | |
| 07:42:07 | pawan-gupta_ | `KVM` hypervisor. However, I am able to set the root password via `user-data ( cloud-init)` but I want to use this feature. I am not sure, what am I missing. Any help in this regard will be highly appreciated. I am using python 2.7.5 | |
| 09:00:37 | bauzas | stephenfin: honestly, thanks for working on the flavor modifications | |
| 09:01:10 | bauzas | but, I'm a bit sad we discuss this now while today is RC1 but KK, will squash all of your changes | |
| 09:01:59 | bauzas | so, we hold the major API version just because of flavor/instance_type, fair enough but I would have loved to get those comments before | |
| 09:06:20 | gibi | bauzas: does it mean we won't have rpc 6.0 in wallaby? or just that we do a last minute update on the bump patch but we still intended to land it today? | |
| 09:06:32 | bauzas | gibi: I don't know what to say | |
| 09:06:53 | bauzas | stephenfin got me a -1 because of the instance_type thing | |
| 09:07:14 | bauzas | and he worked on some DNM FUP so I could squash | |
| 09:07:32 | bauzas | I'm happy to see the first DNM be accepted by Zuul and the multinode job | |
| 09:07:49 | bauzas | but the second DNM got timeout issues on the integrated compute job | |
| 09:08:12 | bauzas | so the situation is, either we accept the patch as it is, but we will keep instance_type until 7.0 | |
| 09:08:40 | bauzas | or, we really want it and then we need to provide a new revision with the check pipeline to run again today | |
| 09:09:04 | gibi | the new revision would be the squash is it? | |
| 09:09:08 | bauzas | yup | |
| 09:09:25 | bauzas | but there is still an open question about the squashed changes | |
| 09:09:31 | bauzas | ideally, I'd squash the three | |
| 09:09:40 | bauzas | as we also need to amend the client | |
| 09:10:14 | bauzas | so I'm grateful for stephenfin's work and we're fortunate that we don't really check the argument keywords | |
| 09:10:23 | bauzas | that was one of my main concerns | |
| 09:10:53 | bauzas | but we're putting the API bump at risk while we're so close to the RC1 branching | |
| 09:11:31 | bauzas | honestly, I don't wanna rush into merging things | |
| 09:11:34 | gibi | so the server side rename is green and the client side rename is red due to timeout | |
| 09:11:44 | bauzas | -ish but yeah | |
| 09:12:05 | gibi | do we need to land the client side rename together with the 6.0 bump in W? or is it something that can be done later in X? | |
| 09:12:48 | bauzas | that's the client side | |
| 09:12:58 | bauzas | but we still have computes who use this client side, right? | |