| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-09 | |||
| 15:34:27 | Sundar | gibi: Sure, of course. Just wanted to see if you are ok with my response. I'll wait for your reviews. Thanks! | |
| 15:34:49 | gibi | Sundar: yeah, I'm OK with your response regarding the Fixture | |
| 15:35:30 | gibi | Sundar: I will try to do the review tomorrow | |
| 15:41:46 | openstackgerrit | Merged openstack/nova master: trivial: Use 'from foo import bar' https://review.opendev.org/710235 | |
| 16:05:08 | openstackgerrit | Jason Anderson proposed openstack/nova master: Use fair locks in resource tracker https://review.opendev.org/711528 | |
| 16:34:28 | melwitt | gibi: if you're around, would like to know your thoughts on the above patch ^ re: test coverage. there doesn't seem to be a great way to verify the addition of fair=True to the synchronized decorators ... wondering if there is a good way to test it that you might know and if not, what do you think about accepting the patch without any test coverage for that? | |
| 16:36:09 | gibi | melwitt: could you please link the patch again, I missed the link during a client restart | |
| 16:37:13 | melwitt | gibi: oops sorry, here https://review.opendev.org/711528 | |
| 16:39:25 | gibi | melwitt: so basically the test should enforce that all the utils.synchronized decorators in nova are created with fair=True ? | |
| 16:40:48 | gibi | I think I can hack someting up for that. But if we want to be selective about when to use fair=True then that might be a harder problem | |
| 16:40:55 | sean-k-mooney | does it make sense to set fair=false? | |
| 16:41:13 | melwitt | gibi: not all in nova but only the ones in nova/compute/resource_tracker.py and yes, I was thinking something that checks whether any use of it is with fair=True. I tried for awhile to mock patch the decorator as a wrapper and check the args but it failed miserably because there was something I was missing | |
| 16:41:36 | sean-k-mooney | melwitt: gibi mabye a hacking check would be better | |
| 16:41:53 | gibi | hacking could be a way if this rule is module specific | |
| 16:42:23 | gibi | sorry I have to drop off but I will look back tomorrow morning | |
| 16:42:31 | melwitt | thanks gibi | |
| 16:43:36 | melwitt | gibi: fwiw I am ok with accepting the patch without testing (I mention in a comment on the review) and wanted to get more opinion | |
| 18:17:45 | openstackgerrit | Merged openstack/nova master: Validate id as integer for os-aggregates https://review.opendev.org/710214 | |
| 18:17:54 | openstackgerrit | Merged openstack/nova master: nit: Fix NOTE error of fatal=False https://review.opendev.org/711794 | |
| 18:44:52 | openstackgerrit | Merged openstack/nova stable/train: Recalculate 'RequestSpec.numa_topology' on resize https://review.opendev.org/708340 | |
| 18:44:57 | openstackgerrit | Merged openstack/nova master: libvirt: don't log error if guest gone during interface detach https://review.opendev.org/610727 | |
| 19:19:01 | openstackgerrit | Lee Yarwood proposed openstack/nova master: images: Move qemu-img info calls into privsep https://review.opendev.org/706897 | |
| 19:19:02 | openstackgerrit | Lee Yarwood proposed openstack/nova master: virt: Pass request context to extend_volume https://review.opendev.org/706899 | |
| 19:19:02 | openstackgerrit | Lee Yarwood proposed openstack/nova master: images: Allow the output format of qemu-img info to be controlled https://review.opendev.org/706898 | |
| 19:19:03 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Correctly resize encrypted LUKSv1 volumes https://review.opendev.org/706900 | |
| 20:31:27 | elod | lyarwood: thanks for volunteering for Nova Stable Liaison :) feel free to ping me anytime if you need some help with that :) | |
| 21:19:18 | openstackgerrit | Merged openstack/nova stable/stein: libvirt: Ignore DiskNotFound during update_available_resource https://review.opendev.org/711277 | |
| 22:29:49 | openstackgerrit | Merged openstack/nova stable/train: Set instance CPU policy to 'share' through image property https://review.opendev.org/703393 | |
| 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? | |