| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-24 | |||
| 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_ | `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 | |
| 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 | |
| 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? | |
| 09:13:34 | bauzas | a deployment with mixed Xena and Wallaby computes couldn't know about the rpc changes | |
| 09:13:44 | bauzas | at least for the W computes | |
| 09:13:48 | bauzas | but, | |
| 09:13:58 | bauzas | this is for prep_resize and resize_inst() | |
| 09:14:10 | bauzas | AFAIK, only conductors are using this rpc client | |
| 09:15:10 | bauzas | honeslty, I'm a bit afraid of rushing RPC bits based on our confidence | |
| 09:15:38 | bauzas | so, I'd say, punt this RPC bump to Xena | |
| 09:15:41 | bauzas | alas. | |
| 09:27:45 | gibi | bauzas: I guess besides the risk of late change, we also short on time to let the squash goes through the check queue today | |
| 09:27:59 | bauzas | that's my point | |
| 09:28:18 | bauzas | if we squash, we enter the odds of the check pipeline | |
| 09:28:42 | gibi | if we only merge the 6.0 as is today, then the rename needs to wait for 7.0 I guess | |
| 09:28:53 | bauzas | but I certainly understand stephenfin's point and dansmith had another argument about not supporting 5.0 | |
| 09:29:18 | bauzas | so, either we say we accept the current change, or we punt to Xena honestly | |
| 09:29:32 | bauzas | I'm not paid by any customer | |
| 09:29:39 | bauzas | so I can leave it die | |
| 09:51:17 | stephenfin | bauzas: There has been two runs of the client change. Between the two every test passed so that's good | |
| 09:51:29 | stephenfin | so let's just squash and approve? | |
| 09:51:39 | stephenfin | that gives us the day to get it merged | |
| 09:53:09 | bauzas | we need to branch RC1 today EOB | |
| 09:54:38 | stephenfin | then we'd want to get moving :) | |
| 09:56:05 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/782935 | |
| 09:56:23 | stephenfin | like that (different change ID) | |
| 09:58:47 | stephenfin | I don't think worrying about the check queue is a good way to think about it. We're going to have the exact same issue if it fails the gate, which is quite possible based on current trends | |
| 09:59:45 | bauzas | stephenfin: then, we need two pairs of eyes | |
| 09:59:52 | stephenfin | gibi: ^ ? | |
| 09:59:55 | bauzas | gibi: can you look at the DNM ? | |
| 10:00:14 | bauzas | also, we need to also squash the rpc client | |
| 10:00:15 | gibi | I've looked at the two extra patches. | |
| 10:00:26 | gibi | I don | |
| 10:00:28 | gibi | I don | |
| 10:00:39 | gibi | I don't know how big of risk we take | |
| 10:00:57 | stephenfin | bauzas: Obviously if you want to do the squash that's okay with me. Just doing this in case it helps to move things along | |
| 10:01:11 | stephenfin | What's the risk? That it won't make RC1? | |
| 10:01:55 | gibi | that what we have today will be RC1 and it means we have ~0 days to let the rpc bump sit on master and get feedback if it breaks someting unexpected | |
| 10:02:16 | gibi | sure we have 2 weeks to provide RC2 | |
| 10:04:14 | gibi | I remember the accel_uuid RPC break that we discovered weeks later after merge | |
| 10:05:15 | gibi | but meh, whathever we merge today it will not have time to sit on master before it becomes stable/wallaby | |
| 10:05:53 | gibi | I did not see anything obviously wrong in the two extra patches but that is just me. | |
| 10:06:03 | stephenfin | I think this is an issue we've to deal with regardless of which patches go in | |
| 10:06:05 | bauzas | gibi: we can't merge it for RC2 | |
| 10:06:12 | gibi | bauzas: I know | |
| 10:06:20 | gibi | it is either today or Xena | |
| 10:06:25 | bauzas | yup | |
| 10:06:40 | bauzas | b/c we can't backport it down to stable/wallaby after today | |
| 10:07:03 | gibi | does Dan reviewed the two extra patches? | |
| 10:07:04 | bauzas | and this is not a regression | |
| 10:07:11 | bauzas | gibi: nope, I don't think | |
| 10:07:22 | stephenfin | He did yeah | |
| 10:07:30 | bauzas | we need to doublecheck the jobs we use | |
| 10:07:48 | stephenfin | he gave me feedback on fixing the client too | |
| 10:07:51 | bauzas | IIRC, grenade-multinode calls the resize API | |
| 10:08:09 | bauzas | stephenfin: again, you were fortunate we don't pass kwargs | |
| 10:08:18 | stephenfin | I know, but we don't so it's okay | |
| 10:08:37 | bauzas | because you're passing something named instance_type to something awaiting to get flavors | |
| 10:08:57 | bauzas | so maybe dansmith could have concerns with this | |
| 10:09:09 | stephenfin | the name of args doesn't matter | |
| 10:09:15 | stephenfin | it's only kwargs that matter | |
| 10:09:18 | stephenfin | standard Python | |
| 10:09:40 | stephenfin | I could call it my_terrible_terrible_awful_variable_name if I wanted to and things would be rost | |
| 10:09:42 | stephenfin | *rosy | |