| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-02 | |||
| 19:28:59 | sean-k-mooney | ill review it in detail tomorow but initall feedback is i would proably expect 2 extra_spec argument one to specify the tpm verion and another for the backend type. other then that it would be nice to support this via the image metadata too but after 5 mins skiming it it seams resonable | |
| 19:29:55 | sean-k-mooney | i seam to recall form the PTG there were some live migration requirements too which i did not see explcitly in the spec. if so proabley a good idea to add them | |
| 19:33:59 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: Fail count in API https://review.openstack.org/607352 | |
| 19:34:13 | artom | dansmith, mriedem, ^^ really easy spec about the fail count discussion earlier | |
| 19:35:05 | dansmith | hmm | |
| 19:35:16 | bauzas | artom: I thought we said to deprecate os-hypervisors API ? | |
| 19:35:22 | bauzas | at least not adding more to it | |
| 19:35:31 | artom | bauzas, seriously? I had no idea. | |
| 19:35:48 | artom | Nothing in the api-ref about it | |
| 19:35:51 | dansmith | and that fail count is an internal value that can change | |
| 19:36:05 | mriedem | artom wasn't at the ptg when os-hypervisors was discussed... | |
| 19:36:09 | dansmith | so I'm kinda meh about exposing it and having people make up beliefs about what it means | |
| 19:36:09 | artom | I mean, I'm not looking for +W fast track here :) | |
| 19:36:21 | artom | So if there are legit issues, destroy at will | |
| 19:36:50 | artom | We could find other ways of indicating the same information, if y'all agree the basic idea is worthwhile | |
| 19:37:09 | bauzas | can't we just emit a notification ? | |
| 19:37:21 | bauzas | stupid idea maybe | |
| 19:37:25 | artom | And if y'all don't, I'm cool as well, NUMA live migration is quite enough for me ;) | |
| 19:51:48 | cfriesen | sean-k-mooney: thanks. to allow it in the image we'd have to use the "trait" as specified in the alternatives section. I'd be fine with that too, I just went with a resource because Eric Fried suggested it. :) | |
| 19:54:46 | cfriesen | sean-k-mooney: live migration is fine, and cold migration is covered in the spec | |
| 19:55:01 | artom | bauzas, notifications I don't think are very useful, but logs would definitely work | |
| 19:55:16 | artom | To be honest, not sure why I didn't go there in the first place | |
| 19:56:11 | cfriesen | artom: probably cause mriedem was talking about the os-hypervisors API this morning | |
| 19:56:56 | artom | mriedem, see, totally your fault. | |
| 19:57:43 | bauzas | I wasn't looking at the IRC discussion this 'US' morning | |
| 19:57:53 | bauzas | what was the point ? | |
| 19:58:12 | artom | The hell, we already log weighed hosts | |
| 19:58:15 | sean-k-mooney | cfriesen: cool am i would have to read the spec properly to understand traits vs reousce comment but ill take your word for it. i had assumed we could have HW_VTPM_TYPE=emulated HW_VTPM_VERSION=2.0 image property pair and have nova construt the resouce request form that but perhaps there is a reason that would not work that i missed | |
| 19:59:16 | mriedem | "(11:27:58 AM) artom: Btw, this would be a think we should probably expose in the hypervisors API or something" | |
| 19:59:28 | artom | mriedem, sshh, let me have this | |
| 19:59:41 | sean-k-mooney | bauzas: the context was artom was trying to recreate the "vm spawns with multiples" issue and injected a fault which resulted in all his instances landing on a host he was not expecting | |
| 20:00:46 | openstackgerrit | Merged openstack/nova stable/ocata: Fix instance evacuation with PCI devices https://review.openstack.org/605881 | |
| 20:00:52 | openstackgerrit | Merged openstack/nova stable/ocata: Update nova network info when doing rebuild for evacuate operation https://review.openstack.org/605882 | |
| 20:00:53 | sean-k-mooney | bauzas: idea was to help debuging perhaps expose it via hyperviors api but i would guess a debug level weigher log might be better in this case | |
| 20:01:09 | artom | Ah, we just log the final sorted list, not the individual weights, nor the per-filter weights | |
| 20:01:15 | bauzas | could we just have alaski back here and just him and me +2/+W a change deprecating multiple-create API ? | |
| 20:01:55 | mriedem | oh god why would we allow attaching volumes to a resized server before it's confirmed/revert | |
| 20:01:57 | mriedem | *reverted | |
| 20:02:01 | mriedem | that's just asking for trouble | |
| 20:02:33 | sean-k-mooney | mriedem: because we did not think that is what we were allowing at the time the code merged ? | |
| 20:03:19 | melwitt | bauzas: users love the multi-create API | |
| 20:03:39 | sean-k-mooney | mriedem: i cound half of the issue with the multiple port bindingings thing by the way. ill file a bug and upload a patch tomorow | |
| 20:03:42 | mriedem | there is a forum session about the multi-create api | |
| 20:03:47 | sean-k-mooney | *found | |
| 20:03:57 | artom | mriedem, I feel like attaching anything to anything that isn't ACTIVE is asking for trouble | |
| 20:04:18 | artom | Like, we should wrap the instance decorator around any method that as 'attach' in its name. | |
| 20:04:28 | artom | *instance state decorator | |
| 20:04:49 | sean-k-mooney | melwitt: do the love the multi create api or multi create support in the client/sdk/osc | |
| 20:05:38 | sean-k-mooney | artom: i think the vm is active in this case on the dest | |
| 20:05:44 | melwitt | mriedem: is it under a more broad topic? I don't see it | |
| 20:05:45 | sean-k-mooney | artom: we just have not confimed it | |
| 20:06:02 | artom | sean-k-mooney, it's still in VERIFY_RESIZE in the API tho | |
| 20:06:07 | artom | I think is what mriedem means | |
| 20:06:10 | melwitt | sean-k-mooney: the API, I think. | |
| 20:06:17 | cfriesen | sean-k-mooney: I'd be open to something like that if people are looking for additional flexibility. making the version explicit would at least protect us if qemu ever supported a newer version | |
| 20:07:05 | sean-k-mooney | cfriesen: you can always default it to 2.0 initally so its optional | |
| 20:07:22 | mriedem | bauzas: melwitt: https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22840 | |
| 20:08:10 | bauzas | melwitt: I'm not against something elsewhere but not in the API :) | |
| 20:08:28 | bauzas | that said, now the ship has sailed... | |
| 20:08:44 | bauzas | I'm pretty sure we'd get lots of arguments if we deprecate it :) | |
| 20:08:52 | sean-k-mooney | mriedem: i would assume the answer to there first quest is ther is no sla followed by there is no test coverage for that usecase | |
| 20:09:32 | mriedem | i tested how you can kill the scheduler https://review.openstack.org/#/c/507918/ | |
| 20:09:34 | mriedem | if that helps | |
| 20:10:11 | sean-k-mooney | thats a lot of red from the ci | |
| 20:10:29 | mriedem | it's an experiment | |
| 20:10:33 | mriedem | not meant to run tempest | |
| 20:11:31 | melwitt | cool experiment. I wonder could the oslo.messaging heartbeat be leveraged in this way? | |
| 20:11:50 | sean-k-mooney | to kill the schduler proably | |
| 20:11:57 | mriedem | yes, | |
| 20:12:05 | mriedem | it passed once i set the rpc_response_timeout to 300 | |
| 20:12:18 | mriedem | the timeout stuff with the select_destinations rpc call likely needs to use the long_rpc_timeout | |
| 20:12:35 | mriedem | because if it times out, today we retry the rpc call up to max_attempts | |
| 20:12:42 | mriedem | so it just compounds the problem | |
| 20:13:01 | melwitt | yeah, sorry, I saw you increased the timeout and that worked -- that's why I asked. I wondered if we could use the heartbeat to help here | |
| 20:14:06 | mriedem | i think yes, do that and drop the old retry_select_destinations decorator | |
| 20:14:58 | melwitt | ++ | |
| 20:33:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Cross-cell resize https://review.openstack.org/603930 | |
| 20:43:44 | openstackgerrit | Merged openstack/nova stable/ocata: unquiesce instance after quiesce failure https://review.openstack.org/605884 | |
| 21:10:19 | openstackgerrit | sean mooney proposed openstack/nova master: propagate vnic_type and profile on create port bindings https://review.openstack.org/607365 | |
| 21:15:37 | sean-k-mooney | mriedem: im goint to repropose ^ later as a bug as i would like to backport it + some other related changes just and fyi but that will partly fix macvtap sriov. | |
| 21:18:32 | sean-k-mooney | mriedem: this patch in partcalar is not super high on my list for the macvtap but per our PTG conversation ther are some other minor bug fixed need to make the codbase actully supprot what we said it would in the rocky release notes | |
| 21:19:43 | sean-k-mooney | s/for the macvtap/for backporting but/ | |
| 21:20:17 | mriedem | ok | |
| 21:20:26 | openstackgerrit | Merged openstack/nova stable/queens: nova-manage - fix online_data_migrations counts https://review.openstack.org/605839 | |
| 21:22:19 | bauzas | mriedem: heh, good news, the inventory reshape works | |
| 21:22:39 | bauzas | mriedem: now, I'm testing the allocations move | |
| 21:22:50 | mriedem | works in...functional tests? | |
| 21:22:53 | mriedem | or a real env? | |
| 21:23:09 | bauzas | mriedem: works on my devstack running on a physical machine :) | |
| 21:23:38 | mriedem | le woot | |
| 21:25:17 | bauzas | mriedem: http://paste.openstack.org/show/731303/ | |
| 21:26:12 | melwitt | that reminds me, did someone create a catchall blueprint for all of the "closing the gaps with nested resource providers" work yet? | |
| 21:26:16 | bauzas | oh oops, now you know my secret machine :p | |
| 21:26:43 | bauzas | melwitt: I already have a vgpu-rocky BP that tracks all of the VGPU effort | |
| 21:26:48 | mriedem | melwitt: probably this https://blueprints.launchpad.net/nova/+spec/use-nested-allocation-candidates | |
| 21:27:18 | bauzas | mriedem: use-nested-alloc-candidates is only one of the gaps but meh | |
| 21:27:33 | mriedem | i'll butt meh you | |
| 21:27:37 | melwitt | ok, thanks. I'm looking to collect the related blueprints and make them dependencies for the vgpu theme | |
| 21:27:56 | mriedem | you can't allocate against vgpu child providers without gibi's bp to get the scheduler stuff to work | |
| 21:28:19 | bauzas | melwitt: mriedem: btw. I reproposed an approved spec for vgpu-stein https://review.openstack.org/#/c/602474/ | |