| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-09 | |||
| 22:29:56 | openstack | bug 1862633 in OpenStack Compute (nova) "unshelve leak allocation if update port fails" [Medium,Fix released] https://launchpad.net/bugs/1862633 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 22:29:56 | openstackgerrit | Merged openstack/nova stable/stein: Reproduce bug 1862633 https://review.opendev.org/711626 | |
| 22:30:00 | openstackgerrit | Merged openstack/nova stable/stein: Clean up allocation if unshelve fails due to neutron https://review.opendev.org/711629 | |
| 22:37:01 | zigo | Each time I do some live-migration, nova-compute appears down after the migration round, until I restart it. | |
| 22:37:08 | zigo | There's something wrong going on ... | |
| 22:37:15 | zigo | Has this been detected and fixed? | |
| 23:39:47 | openstackgerrit | Merged openstack/nova stable/rocky: Add retry_on_deadlock to migration_update DB API https://review.opendev.org/711461 | |
| #openstack-nova - 2020-03-10 | |||
| 00:18:54 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add new default roles in os-volumes-attachments policies https://review.opendev.org/710190 | |
| 00:18:55 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add new policy to PATCH update volume API https://review.opendev.org/711194 | |
| 00:18:55 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add PATCH volume attachments api to os-volume_attachments https://review.opendev.org/693828 | |
| 00:18:56 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add functional tests for PATCH volume attachments API https://review.opendev.org/710965 | |
| 00:22:42 | brinzhang_ | johnthethubaguy: Rebased done https://review.opendev.org/#/c/710190/5, thanks | |
| 00:24:21 | brinzhang_ | gmann: How about this os-instance-actions failed test case? https://review.opendev.org/#/c/706470/ | |
| 01:50:50 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add PATCH volume attachments api to os-volume_attachments https://review.opendev.org/693828 | |
| 01:50:50 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add new default roles in os-volumes-attachments policies https://review.opendev.org/710190 | |
| 01:50:51 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add functional tests for PATCH volume attachments API https://review.opendev.org/710965 | |
| 01:50:51 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add new policy to PATCH update volume API https://review.opendev.org/711194 | |
| 03:02:13 | openstackgerrit | Merged openstack/nova stable/train: Fix hypervisors paginted collection_name. https://review.opendev.org/711664 | |
| 08:27:52 | gibi | lyarwood: thanks for volunteering for the stable liaison role | |
| 08:31:56 | gibi | alex_xu, brinzhang_: looking at the meeting slot ML thread, I see will be discriminated by the 16:00 UTC slot. So I'm thinking about possible solutions for you | |
| 08:32:31 | gibi | my current running assumption is to have a single 16:00 UTC meeting slot on every Thrusday | |
| 08:34:16 | gibi | and on Thrusday UTC 8:00 or 9:00 have a unofficial office hours for you to have a way to talk about issues you want to bring up on the team meeting | |
| 08:35:14 | gibi | this would be like a trial | |
| 08:35:20 | gibi | see if it works | |
| 08:36:06 | gibi | I will dedicate time on Thursday 8:00 UTC anyhow to myself to update the meeting agenda, so having an office hour like thing at the same time seems appropriate | |
| 08:41:44 | brinzhang_ | ok gibi, I will try to participate in 16:00 UTC Thrusday. If I ca n’t catch up, I will check the IRC meeting record. If there are any questions, I will ask at your office time. | |
| 08:41:44 | brinzhang_ | ok gibi, I will try to participate in 16:00 UTC Thrusday. If I ca n’t catch up, I will check the IRC meeting record. If there are any questions, I will ask at your office time. | |
| 08:41:56 | brinzhang_ | Similarly, if there is a problem that needs to be discussed, it will be sent to openstack-nova on Thursday 8: 00UTC or 9: 00UTC | |
| 08:42:37 | lyarwood | gibi: np | |
| 08:43:15 | gibi | brinzhang_: cool, thanks | |
| 12:14:26 | sean-k-mooney | gibi: o/ | |
| 12:14:56 | sean-k-mooney | gibi: im going to try and take another look at the provider.yaml stuff today and see how much i can get through | |
| 12:15:45 | sean-k-mooney | if you have no objection to https://docs.python.org/3/library/functools.html#functools.lru_cache i might swap to using that instead of the module cache. | |
| 12:16:07 | gibi | sean-k-mooney: o/ | |
| 12:16:35 | gibi | sean-k-mooney: I have no objection | |
| 12:16:51 | gibi | sean-k-mooney: ping me if my comments are not clear | |
| 12:16:57 | sean-k-mooney | sure will do | |
| 12:18:49 | sean-k-mooney | im not sure i fully follow what addtional semantic checks i need to add in the third patch | |
| 12:19:18 | sean-k-mooney | well i know we shoudl be deduping providers | |
| 12:19:39 | sean-k-mooney | based on by name vs by uuid vs by $COMPUTE_NODE | |
| 12:20:11 | sean-k-mooney | i just havent fully loaded enough of the code into my head to fully grapse that yet | |
| 12:20:23 | sean-k-mooney | but if i get stuck ill let ye know | |
| 12:21:15 | sean-k-mooney | on https://review.opendev.org/#/c/676522/41/nova/compute/resource_tracker.py@1730 is the exception for all compute nodes | |
| 12:21:34 | gibi | yeah, I think the core comment is about identifying the same provider 3 different ways | |
| 12:22:20 | sean-k-mooney | so one thing that confused me a bit is why to we error in that case instead of merging | |
| 12:22:43 | sean-k-mooney | e.g. if i do both by name and by uuid | |
| 12:23:02 | sean-k-mooney | and add different providers/inventories in each it should be fine right | |
| 12:23:21 | gibi | both behavior could be acceptable but I guess the spec said every RP should be mentioned only once | |
| 12:23:37 | gibi | let me look i tup | |
| 12:23:39 | sean-k-mooney | ok ya well im not going to change it | |
| 12:24:02 | sean-k-mooney | no its fine i was just wondering if there was a fundemental reason i missed | |
| 12:25:14 | gibi | "In the event that a resource provider is identified by both explicit UUID/NAME and $COMPUTE_NODE, only the UUID/NAME record will be used." | |
| 12:25:19 | gibi | https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html | |
| 12:25:37 | sean-k-mooney | right that make sense | |
| 12:25:51 | sean-k-mooney | but it does sate what happens if you use both UUID and NAME right | |
| 12:26:36 | gibi | I did not found any reference about that case yet | |
| 12:26:54 | sean-k-mooney | anyway its not an issue right now. if we want to support that in the future we can | |
| 12:27:05 | gibi | # same value is used more than once across all provider configs for name | |
| 12:27:05 | gibi | "The consuming nova-compute service will error and fail to start if the" | |
| 12:27:08 | gibi | # or uuid. | |
| 12:27:21 | sean-k-mooney | ah ok perfect | |
| 12:27:59 | sean-k-mooney | im not sure why we chose that but i also dont partically care enough to argure that its too limiting | |
| 12:28:39 | sean-k-mooney | i suspect most people will just use the name | |
| 12:29:04 | gibi | yeah, name for computes, uuid for ironic nodes | |
| 12:29:26 | sean-k-mooney | isnint the ironic node RP name also the uuid | |
| 12:30:10 | sean-k-mooney | the name has to be unique so that what i would have done to make it as simple as possible but uuid for ironic makes sense | |
| 12:31:34 | gibi | yes, for ironic name and uuid are the same in placement | |
| 12:41:53 | openstackgerrit | Merged openstack/nova stable/rocky: libvirt: Ignore DiskNotFound during update_available_resource https://review.opendev.org/711278 | |
| 13:15:55 | mordred | smcginnis: https://review.opendev.org/#/c/710214/ | |
| 13:16:06 | mordred | smcginnis: that would be the patch that broke that test | |
| 13:22:29 | mordred | jkulik: https://review.opendev.org/#/c/710214/ caused a behavior change and broke SDK's functional tests | |
| 13:23:52 | gibi | mordred: did you depend on the HTTP 500 from nova? or what was the exact behavior change that broke the SDK? | |
| 13:24:17 | mordred | the opposite - we were getting NotFound before when trying to delete something by name | |
| 13:24:24 | mordred | and now we're getting BadRequest | |
| 13:24:49 | mordred | to be fair - there's ALSO a bug in SDK which this has shown | |
| 13:25:54 | gibi | can nova do something to help SDK out? the only thing I can imagine is to revert https://review.opendev.org/#/c/710214/ and re-propose it with a microversion bump on the API | |
| 13:26:06 | gibi | would that help? | |
| 13:26:07 | mordred | which is that we were accepting a name_or_id argument to our delete method and then it looks like we're passing taht straight on - which will never have worked | |
| 13:26:50 | mordred | gibi: I'm not sure - I keep going back and forth about whether the behavior change is one of those "someone might break but that person was already broken" times | |
| 13:27:16 | gibi | yeah, I'm hesitant too | |
| 13:27:18 | mordred | I think the more I talk out loud about it - the more I'm coming to think it's actually all a bug on our side that this just showed | |
| 13:32:47 | gibi | if SDK is need to be changed anyhow then I would not jump on the revert | |
| 13:33:04 | gibi | but I can be convinced otherwise | |
| 13:38:36 | mordred | gibi: yeah - I just pushed up https://review.opendev.org/712068 - we had a layer that was erroneously passing name_or_id. we weren't noticing the change because we trapped for ResourceNotFound and then returned False (saying we didn't delete it) - so we _were_ telling the user it wasn't working ... but we can do better there and delete by name (with a GET first) if they pass us a nane | |
| 13:46:28 | jkulik | mordred: I'm sorry, that this caused you problems. Any way I could have checked for this? | |
| 13:47:33 | mordred | jkulik: well - maybe we should consider running sdk functional tests on nova changes | |
| 13:47:57 | mordred | other than that - it was really just uncovering a latent bug on our side - so I think it's a good breakage :) | |
| 13:48:07 | brinzhang | gibi, lyarwood: I find some patch always failed by nova-live-migration task, sometimes we recheck it, that it can be passed, but sut still fails | |
| 13:48:27 | brinzhang | gibi, lyarwood:such as https://review.opendev.org/#/c/706897/ and https://review.opendev.org/#/c/700072/ | |
| 13:49:28 | brinzhang | From their zuul log, I am not find some useful message caused by live migration failed, or I missing something | |
| 13:50:44 | brinzhang | I think we should find why it always failed, IMO, that always a hidden danger | |
| 13:54:05 | brinzhang | lyarwood: I saw you want to migrate nova-live-migration job https://review.opendev.org/#/c/711604/3, that can fix this issue? I will check together :) | |
| 13:57:17 | openstackgerrit | Monty Taylor proposed openstack/nova master: Run sdk functional tests on nova changes https://review.opendev.org/712092 | |
| 13:57:26 | sean-k-mooney | brinzhang: i dont think that lyarwood new job will fix it | |
| 13:57:34 | sean-k-mooney | brinzhang: but it will make it less complex | |
| 13:57:45 | sean-k-mooney | so that might help us determin why its failing | |
| 13:58:01 | mordred | gibi, jkulik, smcginnis: ^^ sake of argument patch to run sdk functional tests over here | |
| 13:58:24 | brinzhang | sean-k-mooney: cool, that good | |
| 13:59:28 | brinzhang | sean-k-mooney: maybe lyarwood wants to migrate this job to zuulv3 | |
| 14:00:28 | brinzhang | I remembered he looks for that migrate v3 documents the day before yesterday | |