| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-15 | |||
| 09:27:47 | bhagyashris | Ok then in my case what will be the all_cpus value | |
| 09:27:50 | sean-k-mooney | then the inventory will be PCUP total 4 reserved 0 | |
| 09:27:56 | sean-k-mooney | no | |
| 09:28:13 | sean-k-mooney | we will only be reporting the consumable cpus to placement | |
| 09:28:19 | sean-k-mooney | not all the cpus on the plathform | |
| 09:28:25 | bhagyashris | ok | |
| 09:29:08 | sean-k-mooney | let me just double check the spec to ensure that is correct but i belive that is what we settled on | |
| 09:29:36 | bhagyashris | ok check and let me help to understand | |
| 09:30:07 | bhagyashris | Sorry help me to understand | |
| 09:30:12 | sean-k-mooney | looks like that has not been updated yet https://review.opendev.org/#/c/555081/28/specs/train/approved/cpu-resources.rst@201 | |
| 09:30:37 | sean-k-mooney | ill leave a comment | |
| 09:30:54 | sean-k-mooney | stephenfin: ^ is the above correct | |
| 09:31:55 | bhagyashris | I am still confuse what will be the all_cpus value | |
| 09:32:12 | sean-k-mooney | there wont be one | |
| 09:32:35 | bhagyashris | if you check the Upgrade section there they have mentioned the formula | |
| 09:32:38 | sean-k-mooney | at least i dont think there shoudl be | |
| 09:32:53 | bhagyashris | To calculate the reserved hot | |
| 09:32:59 | bhagyashris | Host cpu* | |
| 09:33:24 | sean-k-mooney | that is not present in the current verion as far as i can see | |
| 09:34:12 | bhagyashris | http://logs.openstack.org/81/555081/28/check/openstack-tox-docs/6314f69/html/specs/train/approved/cpu-resources.html#configuration-options | |
| 09:34:19 | bhagyashris | Here they have mentioned | |
| 09:35:51 | bhagyashris | sean-k-mooney: ^^ | |
| 09:36:11 | sean-k-mooney | ya i think that is in correct. this was one of the part of the spec that i really disliked but we still need to get agreement on that | |
| 09:36:54 | bhagyashris | Yeah and there I am still unclear what will be the all_cpus value | |
| 09:37:08 | sean-k-mooney | i am suggstion there should not be one | |
| 09:37:40 | sean-k-mooney | i think it is incorrect to track cpus that cant be consumed in placement | |
| 09:37:58 | sean-k-mooney | it give an incorrect assement of your capastity | |
| 09:39:59 | bhagyashris | yeah | |
| 09:41:13 | bhagyashris | Then how will calculate the reserved value | |
| 09:41:35 | sean-k-mooney | we dont we always set it to 0 when creting the rp | |
| 09:42:48 | bhagyashris | Okay mean for both the PCPU and VCPU resource class inventory it will be 0 | |
| 09:42:55 | sean-k-mooney | yes | |
| 09:43:08 | bhagyashris | But didn't get why this is added in spec | |
| 09:43:11 | sean-k-mooney | that is not what the spec says but i think we shoudl updated it to say that | |
| 09:43:29 | bhagyashris | As I am implementing the spec so it's till bit confusing to me | |
| 09:43:58 | sean-k-mooney | well we have changed the design a bit form last cycle | |
| 09:44:18 | sean-k-mooney | this was one of the point that there was still some disagrement on | |
| 09:45:01 | bhagyashris | Ohh ok. | |
| 09:46:05 | bhagyashris | stephenfin: Hi, do you give me some suggestion and opinion about it | |
| 09:46:25 | sean-k-mooney | i think the UX of what was prosped in the spec is incrroect and i fully expect to get bug report because of it which is why i wanted to change it | |
| 09:46:34 | bhagyashris | Regarding the reserved_host_cpu calculation | |
| 09:47:50 | bhagyashris | sean-k-mooney: Yeah , still waiting for final decision how will be the reserved value for cpus | |
| 09:47:59 | stephenfin | sean-k-mooney: Yeah, that's a mistake that should be updated | |
| 09:48:37 | stephenfin | reserved = 0 by default since we already have a way to "reserve" CPUs (by not including them in either mask) | |
| 09:48:45 | sean-k-mooney | stephenfin: are we going to merge the spec as is and fix it in a follow up patch | |
| 09:48:56 | stephenfin | sean-k-mooney: Yeah, I'd prefer that, personally | |
| 09:49:03 | stephenfin | I'll draft the follow-up now | |
| 09:49:08 | sean-k-mooney | so whould i to finaly get it merged | |
| 09:49:17 | stephenfin | 'zactly | |
| 09:49:39 | stephenfin | bhagyashris: Does that make sense/ | |
| 09:49:41 | stephenfin | *? | |
| 09:50:49 | bhagyashris | sean-k-mooney, stephenfin: yes , so for both the VCPU and PCPU resource class inventory the reserved value will be 0 and will deprecate the configuration option anyways right? | |
| 09:53:18 | sean-k-mooney | yes we are deprecating resrved_host_cpus and sured really raise an error if its used with the new cpu_dedicated_set also set in the config | |
| 09:54:26 | bhagyashris | sean-k-mooney, stephenfin: okay | |
| 09:54:47 | bhagyashris | sean-k-mooney, stephenfin: Thank you for your inputs :) | |
| 09:56:31 | openstackgerrit | Matthew Booth proposed openstack/nova master: Fix retry of instance_update_and_get_original https://review.opendev.org/658845 | |
| 10:07:22 | NewBruce | howdy all - as i mentioned last night, ive been digging into a few other issues in the migration process - hitting a wall, thinking about a bug report but figure its best to get a second opinion before doing so | |
| 10:08:43 | NewBruce | live migrations with volumes and volume-snapshots are failing - two errors | |
| 10:08:44 | NewBruce | 1. 'serial' is deprecated, please use the corresponding option of '-device’ instead | |
| 10:08:44 | NewBruce | 2. Could not open backing file: Could not open '/var/lib/nova/mnt/… : Permission denied: | |
| 10:09:51 | NewBruce | in the first, an error due to deprecation is odd, but also according to libvirt docs, serial is only deprecated for type block and we have type ‘file’ in the domain xml | |
| 10:16:04 | openstackgerrit | Merged openstack/os-vif master: Fix Kuryr-Kubernetes job name https://review.opendev.org/656492 | |
| 10:27:58 | openstackgerrit | Hamdy Khader proposed openstack/nova master: [WIP] OVS DPDK port representors support https://review.opendev.org/658785 | |
| 10:35:16 | openstackgerrit | Hamdy Khader proposed openstack/os-vif master: [WIP] OVS DPDK port representors support https://review.opendev.org/658786 | |
| 12:11:34 | aarents | Hi there, can some one check relevance of this please https://review.opendev.org/#/c/659054/ ? | |
| 12:12:55 | sean-k-mooney | mdbooth_: ^ seams to be something you coudl weigh in on | |
| 12:14:09 | sean-k-mooney | aarents: the image cache code is rather arcane | |
| 12:14:44 | mdbooth_ | sean-k-mooney: It is stretched beyond all reasonable limits. | |
| 12:15:05 | sean-k-mooney | aarents: hardcoding size for the disk is not a good approch | |
| 12:15:37 | sean-k-mooney | oh that is the test code... | |
| 12:15:48 | aarents | :) | |
| 12:16:29 | sean-k-mooney | so the change is just to pass the size parmater to the copy from host | |
| 12:16:41 | aarents | yep that's all | |
| 12:17:17 | aarents | if not the qemu img disk have the size of backing file | |
| 12:17:51 | sean-k-mooney | so size in this case is the flavor root disk | |
| 12:17:59 | aarents | yes it is | |
| 12:18:55 | sean-k-mooney | well we are passing it like 10 lines above so it seams sane | |
| 12:21:31 | sean-k-mooney | but honestly i dont really know the full implication but at first glance it looks like an apporpiate fix for the bug you reported | |
| 12:24:08 | mdbooth | Could somebody hit https://review.opendev.org/#/c/658845/ for me, please? It has 1.5 +2s. It's the db retry bug. | |
| 12:24:23 | aarents | sean-k-mooney: ok thks, it fixs the issue in my environment | |
| 12:24:56 | mdbooth | mriedem: I merged the comment you asked for you at the request of stephenfin, btw. | |
| 12:25:17 | sean-k-mooney | aarents: it also passed ci so it dose not break the happy path although i dont think we have a function or tempest test that validates teh behavior | |
| 12:25:54 | mriedem | mdbooth: yeah looking | |
| 12:26:00 | mdbooth | mriedem: Thanks | |
| 12:26:04 | sean-k-mooney | mdbooth: oh this is the modifyicion of input parmaters thing you sent to the mailing list | |
| 12:26:11 | mdbooth | sean-k-mooney: Yeah. | |
| 12:27:17 | mriedem | sean-k-mooney: the sriov live migration blueprint isn't closed yet b/c surely there are docs updates to be made, right? | |
| 12:27:25 | mriedem | at least this https://docs.openstack.org/neutron/latest/admin/config-sriov.html#known-limitations | |
| 12:27:46 | mriedem | melwitt: are you ready for https://blueprints.launchpad.net/nova/+spec/count-quota-usage-from-placement to go back into a runway slot? | |
| 12:28:07 | sean-k-mooney | that in neutreon but yes i should go update that. | |
| 12:28:18 | mriedem | mdbooth: coreycb: btw, starlingx is saying since we merged the eventlet thing on stable/stein that they are broken ow | |
| 12:28:19 | mriedem | *now | |
| 12:28:21 | mriedem | so that's fun | |
| 12:28:38 | mriedem | https://bugs.launchpad.net/nova/+bug/1829062 | |
| 12:28:39 | openstack | Launchpad bug 1829062 in StarlingX "nova placement api non-responsive due to eventlet error" [Critical,New] - Assigned to Bruce Jones (brucej) | |
| 12:29:09 | sean-k-mooney | mriedem: dpending on how its run there were issues with some rabbitmq timeouts or somthing right | |
| 12:29:13 | mriedem | granted if starlingx moves to extracted placement in stein they won't have to deal with eventlet | |
| 12:29:16 | mdbooth | mriedem: Yeah, we're seeing similar downstream. However, I'm pretty sure we didn't. | |
| 12:29:58 | mdbooth | mriedem: Honestly what I really want to do is prioritise un-eventleting the multi-cell instance list code, and let them switch eventlet off. | |
| 12:30:37 | mriedem | which is mel's series isn't it? | |