| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-15 | |||
| 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? | |
| 12:30:37 | sean-k-mooney | ya althoeugh we have an open question of how to we kill long running task that will timeout due to a down cell | |
| 12:30:46 | sean-k-mooney | mriedem: yes | |
| 12:31:02 | mdbooth | mriedem: Let me clarify 'we didn't', btw: the eventlet band-aid thing didn't break it, it was already broken. | |
| 12:31:11 | mdbooth | I believe them that it's broken, though. | |
| 12:32:16 | mdbooth | mriedem: Yes. We discussed it at PTG and the feeling was that we'd address it later. However, I think that was when we believe we'd applied an effective band-aid already. | |
| 12:32:19 | sean-k-mooney | if we dont have a path forward with melwitt's serise we might want to consider reverting the scater gatehr stuff temporally and dropping eventlets | |
| 12:32:42 | mdbooth | sean-k-mooney: Also worthy of discussion. | |
| 12:36:41 | sean-k-mooney | so looks like https://review.opendev.org/#/c/657750/1 is the last patch in that series and it passing ci but i think we are currently stuck on the open question in https://review.opendev.org/#/c/650172/14 | |
| 12:37:49 | sean-k-mooney | is the startx issue seperate for teh amqp issue reported on the mailing list | |
| 12:38:14 | sean-k-mooney | http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005822.html | |
| 12:42:38 | mdbooth | Thanks for the reminder, sean-k-mooney | |
| 12:54:46 | mriedem | tssurya: we need a novaclient release before osc can use the locked reason stuff https://review.opendev.org/#/c/659124/ | |
| 13:01:12 | mriedem | i'll propose a release | |
| 13:06:30 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Cap sphinx for py2 to match global requirements https://review.opendev.org/659202 | |
| 13:14:30 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Cap sphinx for py2 and drop keyring dependency https://review.opendev.org/659202 | |
| 13:19:04 | mriedem | the requirements-check job is happy with ^ now if someone wants to approve so we can get that into the novaclient release i'm pushing | |
| 13:22:17 | mdbooth | mriedem: Thanks. | |
| 13:25:02 | mdbooth | Incidentally, MySQL's repeatable read isolation level (which we use), is seriously obtuse when trying to handle concurrency. If I hadn't had to handle it when we were working on this code previously I would never have believe anybody would have intentionally created this behaviour. However, MySQL goes to great lengths to be broken. | |
| 13:25:27 | mdbooth | They apparently see value in it. | |
| 13:28:48 | mriedem | job security | |
| 13:29:43 | dansmith | kashyap: I'm entirely against (a) nova automatic scheduling based on perceived threats from vulnerabilities and (b) putting traits in placement about which vulnerabilities the host has, has been patched for, or has enabled/disabled. Hopefully that clears it up. | |
| 13:30:53 | kashyap | Sure, I don't care about these things much at all; I wanted to put in a missing thing in traits and move on. | |
| 13:31:10 | kashyap | dansmith: Also: you write "perceived threats" -- they're not. | |
| 13:31:30 | kashyap | You can _choose_ to take a policy stance, as "this is out of scope". That's perfectly fine :-) | |
| 13:31:30 | sean-k-mooney | the add the pcid and 1ghugepage tratis and drop the other form the patch | |