| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-09 | |||
| 13:09:17 | Luzi | efried, i wanted to restore the image encryption spec, but i don't have the restore button as it seems. Could you restore it for me? Thank you :) | |
| 13:09:31 | mriedem | Luzi: you have to re-propose it for ussuri anyway | |
| 13:09:38 | mriedem | and address feedback from the train spec | |
| 13:09:52 | mriedem | oh but i guess you want the same change id, | |
| 13:09:53 | mriedem | yeah sec | |
| 13:10:02 | mriedem | Luzi: got a link? | |
| 13:10:15 | mriedem | https://review.opendev.org/#/c/608696/ | |
| 13:10:17 | artom | mriedem, I thought we did - sean-k-mooney told me to use recheck, not check experimental | |
| 13:10:42 | mriedem | artom: if it's in the experimental queue you have to do "check experimental" since it's on-demand | |
| 13:10:44 | artom | mriedem, right, https://zuul.opendev.org/t/openstack/build/435aded2c1934212a87c6efcc3df0f44 | |
| 13:10:44 | mriedem | Luzi: done | |
| 13:10:53 | Luzi | mriedem, thank you :) | |
| 13:10:57 | artom | mriedem, I'm not sure how he set it up, but it ran and passed | |
| 13:11:12 | mriedem | artom: yeah but i don't think on the latest changes | |
| 13:11:26 | mriedem | Zuul experimentalSep 7 2:36 AM was the last run | |
| 13:11:45 | artom | mriedem, Sep 7 10:54 AM Hrmm maybe not | |
| 13:11:55 | mriedem | Artom Lifshitz Uploaded patch set 60. Sep 7 8:26 AM | |
| 13:11:58 | artom | mriedem, in any case, 'recheck' is definitely the thing to do on the DNM patches | |
| 13:12:19 | artom | Zuul | |
| 13:12:19 | artom | Sep 7 10:54 AM | |
| 13:12:20 | artom | Patch Set 1: Verified+1 | |
| 13:12:20 | artom | Build succeeded (check pipeline). | |
| 13:12:20 | artom | nova-nfv-multi-numa-multinode SUCCESS in 56m 56s | |
| 13:12:53 | mriedem | oh i guess it is in check https://review.opendev.org/#/c/680739/1/.zuul.yaml@573 | |
| 13:13:29 | artom | mriedem, and in case you missed it, I set up https://review.opendev.org/#/c/680806/ to run in the gate with the vcpu_pin_set configured, to give the new allocation_cpu_tuning stuff a smoke check | |
| 13:13:35 | mriedem | it also showed up in experimental which is why i was confused | |
| 13:13:54 | artom | It won't change allocation_cpu_pins because vcpu_pin_set is identical on both hosts, but it'll run through the code | |
| 13:25:02 | openstackgerrit | Ivaylo Mitev proposed openstack/nova master: VMware: Update flavor-related metadata upon instance resize https://review.opendev.org/681004 | |
| 13:25:35 | brinzhang | mriedem: https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/add-user-id-field-to-the-migrations-table | |
| 13:25:47 | brinzhang | mriedem: this patch can be merged in Train? | |
| 13:26:28 | mriedem | brinzhang: maybe, i have higher priority things to review first today | |
| 13:26:39 | brinzhang | mriedem: thanks | |
| 13:29:03 | sean-k-mooney | mriedem: the DNM test pataches have it in check with all other jobs disable so that it runs when i upload a patch and does not wast gate time by running all the other experimental jobs | |
| 13:29:13 | sean-k-mooney | mriedem: sorry for the confusion | |
| 13:30:12 | mriedem | yeah this is confusing https://review.opendev.org/#/c/680739/1/.zuul.yaml@629 | |
| 13:30:38 | sean-k-mooney | mriedem: im not really sure why the old lable works and the new one does not but im going update the base patch to use the old lable after the current jobs complete | |
| 13:30:51 | mriedem | brinzhang: can you rebase https://review.opendev.org/#/c/673485/12 on https://review.opendev.org/#/c/670790/8 ? | |
| 13:30:53 | mriedem | there is a merge conflict | |
| 13:32:25 | brinzhang | mriedem: Today, I was rebased it, now has a merge conflict? | |
| 13:33:05 | mriedem | it has to be rebased on the latest patch set of 670790 | |
| 13:33:25 | sean-k-mooney | mriedem: by the way i configured the jobs to run in expermental and perodic since we only have 1 provider but would you be open to adding it as non voting in check at some point. non voiting jobs dont break the pipeline if they cant run because the provider is down. | |
| 13:33:34 | brinzhang | mriedem: Okay, I will reabse it now. | |
| 13:33:44 | ganso | hello folks! I am trying to use "openstack usage list" which according to this commit https://review.opendev.org/#/c/639652/2/openstackclient/compute/v2/usage.py should be able to handle microversions 2.40, but using --debug I see it is always using 2.1. Is there any way to force openstack CLI to use nova microversions 2.40? My OpenStack CLI is version 3.19 | |
| 13:34:23 | mriedem | sean-k-mooney: maybe | |
| 13:34:29 | artom | ganso, openstack --help, you'll see an option named something like --os-compute-api-version | |
| 13:34:46 | artom | ganso, osc defaults to using the lowest possible microversion, aka 2.1 | |
| 13:35:01 | sean-k-mooney | mriedem: ok well im beign conservitve and wanted to get some confidence form the periodic job before proposing that. | |
| 13:35:01 | ganso | artom: thanks! | |
| 13:35:25 | artom | ganso, also, in the future, please direct similar questions to #openstack (see /topic) | |
| 13:35:32 | mriedem | the help on that osc command should be updated to mention using 2.40 or above for paging otherwise the user would have no way of knowing that w/o looking at code | |
| 13:36:16 | ganso | artom: will do! thank you very much! | |
| 13:36:18 | ganso | mriedem: +1 | |
| 13:37:41 | openstackgerrit | Brin Zhang proposed openstack/python-novaclient master: Microversion 2.79: Add delete_on_termination to volume-attach API https://review.opendev.org/673485 | |
| 13:38:41 | brinzhang | mriedem: Done of that reabased. | |
| 13:39:27 | luyao | dansmith: Hi Dan, could you have a look again at https://review.opendev.org/#/c/678447/ and https://review.opendev.org/#/c/678448/, about 'resource' db and object. I'll appreciate that . | |
| 13:55:52 | stephenfin | If I cold migrate an instance but don't confirm it, I should expect to see VCPU usage for the instance on both the source and destination, right? | |
| 13:56:48 | bauzas | stephenfin: what's your concern ? | |
| 13:56:53 | bauzas | allocations, you mean ? | |
| 13:57:00 | stephenfin | yeah | |
| 13:57:04 | stephenfin | allocations | |
| 13:57:04 | bauzas | if so, yeah | |
| 13:57:12 | stephenfin | an allocation for the instance, an allocation for the migration record | |
| 13:57:16 | bauzas | correct | |
| 13:57:23 | artom | stephenfin, you mean based on other existing behaviour? | |
| 13:57:35 | artom | I believe so - the instance is consuming resources on the source, the migration on the dest | |
| 13:57:41 | stephenfin | sweet | |
| 13:58:00 | bauzas | the original allocation is transformed to have the consumer to be the migration UUID instead of the instance | |
| 13:58:18 | bauzas | and then we create a new allocation for the instance | |
| 13:58:32 | bauzas | having the consumer be the instance UUID | |
| 13:58:45 | bauzas | artom: the other way | |
| 13:59:02 | artom | bauzas, I was talking about the old-school resources tracker | |
| 13:59:06 | stephenfin | next question: I thought by default a cold migration would never land on another host, but that's not what I'm seeing in functional tests | |
| 13:59:13 | artom | ... which I guess stephenfin no longer cares about? | |
| 13:59:24 | bauzas | artom: stephenfin: https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/migration-allocations.html | |
| 13:59:58 | artom | stephenfin, other way around, I think | |
| 14:00:11 | artom | By default it always goes to different host | |
| 14:00:19 | bauzas | correct ^ | |
| 14:00:20 | stephenfin | artom: yeah, sorry, never land on the _same_ host | |
| 14:00:27 | artom | And then if you set the allow_resize_to_same_host option, it can land on the same host | |
| 14:00:30 | bauzas | unless you modify an option $ | |
| 14:00:35 | bauzas | yeah what artom said | |
| 14:00:36 | artom | (Or whatever it's called) | |
| 14:00:50 | bauzas | artom: that is the correct option name | |
| 14:02:01 | stephenfin | weeird | |
| 14:02:11 | stephenfin | there must be something else going on here so | |
| 14:02:18 | artom | stephenfin, so, dunno if this is relevant, but while working on the the NUMA LM func tests, I noticed there was an issue in how you started computes with different fakelibvirt connections for each | |
| 14:02:26 | stephenfin | shoot | |
| 14:02:47 | artom | stephenfin, https://review.opendev.org/#/c/672595/45/nova/tests/functional/libvirt/base.py | |
| 14:03:14 | artom | Again, no idea if that's what's causing your thing now, but could be relevant | |
| 14:04:01 | stephenfin | oh, fun | |
| 14:12:55 | stephenfin | artom: The other approach is this one https://review.opendev.org/#/c/678470/24/nova/tests/unit/virt/libvirt/fakelibvirt.py | |
| 14:13:11 | stephenfin | which I think accomplishes much the same thing | |
| 14:13:35 | stephenfin | there are quite a few in-flight changes with those files atm :) | |
| 14:15:09 | openstackgerrit | Brin Zhang proposed openstack/nova master: Follow-up: Add delete_on_termination to volume-attach API https://review.opendev.org/680655 | |
| 14:15:28 | artom | stephenfin, and then you stub that connection into each compute manager I guess? | |
| 14:15:53 | artom | Oh, that's not your patch | |
| 14:15:54 | artom | Hrmm | |
| 14:17:02 | kashyap | aspiers: Any reason you know this method is in virt/hardware.py -- _get_flavor_image_meta()? It can be used by "non-hardware"-related features, too | |
| 14:17:15 | aspiers | kashyap: git blame? | |
| 14:17:17 | kashyap | Maybe a question for stephenfin, as he wrote that :-) | |