| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-22 | |||
| 14:47:42 | sean-k-mooney | "Show deleted items only. In some circumstances deleted items will still be accessible via the backend database, however there is no contract on how long, so this parameter should be used with caution. 1, t, true, on, y and yes are treated as True (case-insensitive). Other than them are treated as False. | |
| 14:47:44 | sean-k-mooney | This parameter is only valid when specified by administrators. If non-admin users specify this parameter, it is ignored. | |
| 14:47:54 | sean-k-mooney | so ya admin only in the api ref too | |
| 14:48:32 | gmann | yes, for v2 or v2.1, deleted instances are admin only | |
| 14:48:47 | gibi | and I agree that we cannot garantee data about deleted instances | |
| 14:48:55 | gibi | so there admin onlyness is OK to me | |
| 14:49:05 | sean-k-mooney | yep same | |
| 14:49:19 | gibi | but soft-delete instances are always kept in the db so there we could return them to the owner | |
| 14:49:19 | sean-k-mooney | soft delete is not even guarentted by the api | |
| 14:49:48 | sean-k-mooney | well isnt soft delete resoration an admin only api too | |
| 14:49:56 | gibi | no | |
| 14:50:00 | gibi | soft delete is allowed to owner | |
| 14:50:15 | gmann | yeah admin-or-owner | |
| 14:50:27 | gibi | Policy defaults enable only users with the administrative role or the owner of the server to perform this operation | |
| 14:50:30 | gibi | yepp | |
| 14:50:33 | sean-k-mooney | ah https://docs.openstack.org/api-ref/compute/?expanded=list-servers-detail,restore-soft-deleted-instance-restore-action-detail#restore-soft-deleted-instance-restore-action | |
| 14:51:02 | sean-k-mooney | Policy defaults enable only users with the administrative role or the owner of the server to perform this operation. | |
| 14:51:06 | gibi | also GET /servers/<uuid> returns the soft-delete instance for the owner | |
| 14:51:28 | gibi | just GET /servers doesn't | |
| 14:51:37 | gibi | and GET /servers/details | |
| 14:51:39 | sean-k-mooney | i mean i guess it would be oke to list your soft-deleted instances | |
| 14:51:46 | gibi | yeah I feel the same ^^ | |
| 14:52:13 | sean-k-mooney | { | |
| 14:52:15 | sean-k-mooney | "restore": null | |
| 14:52:16 | gmann | as long as they know uuid they can get it via GET /servers/<uuid> | |
| 14:52:17 | sean-k-mooney | } | |
| 14:52:27 | gibi | yes | |
| 14:52:36 | gibi | if you know the uuid you can restore it | |
| 14:52:36 | sean-k-mooney | ... this looks like another case where we force null instead of allowing restore: {} | |
| 14:53:13 | gmann | sean-k-mooney: that inconsistency is in our most of the action APIs | |
| 14:53:53 | sean-k-mooney | gmann: yep im hoping we fix that sooner rather then later and allow {} everhwere null is allowed today | |
| 14:54:09 | sean-k-mooney | to correct the regression we intoduced a few years ago in this regard | |
| 14:54:14 | gmann | yeah | |
| 14:54:41 | sean-k-mooney | thats said customer have not completed about it so low priority | |
| 14:54:53 | gmann | gibi: sean-k-mooney +1 on returning soft deleted instances in GET /servers GET /servers/detail | |
| 14:56:14 | gibi | gmann: thanks | |
| 14:56:28 | sean-k-mooney | gmann: does changing the policy rule require a microverions | |
| 14:56:40 | gmann | sean-k-mooney: no. | |
| 14:56:41 | sean-k-mooney | or can it be made admin_or_owner | |
| 14:56:48 | sean-k-mooney | ok | |
| 14:56:52 | gmann | sean-k-mooney: this is code check not policy | |
| 14:57:04 | sean-k-mooney | well yes | |
| 14:57:14 | gmann | https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/api/openstack/compute/servers.py#L265 | |
| 14:57:18 | sean-k-mooney | but we should still be limiting it to admin_or_owner right | |
| 14:57:34 | sean-k-mooney | e.g. i should not be able to list your deleted instances | |
| 14:57:46 | gmann | but it is same things, we are just opening the permission here. no new filed added in response or return code change | |
| 14:57:52 | sean-k-mooney | so we should likely remove the code check and contol it via policy | |
| 14:58:06 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452 | |
| 14:58:12 | gmann | sean-k-mooney: exactly. hard code is_admin are not so good | |
| 14:58:25 | bauzas | gibi: rebased the compute RPC API change https://review.opendev.org/c/openstack/nova/+/761452 | |
| 14:58:37 | gibi | bauzas: ack, looking | |
| 14:59:24 | gmann | sean-k-mooney: and that is one of the next step after new secure rbac, to remove all is_admin hard coded checks from everywhere(API or DB etc) | |
| 15:04:24 | sean-k-mooney | yep makes sense | |
| 15:06:47 | stephenfin | melwitt: Can you look at https://review.opendev.org/c/openstack/osc-placement/+/743976 again today? Looks like gibi is waiting on you to spin back around to it first | |
| 15:07:58 | melwitt | stephenfin: yes, sorry, I had meant to look at that friday but didn't :( I will look today | |
| 15:08:06 | stephenfin | All good. Thanks! | |
| 16:28:13 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Wallaby 23.0.0 prelude section https://review.opendev.org/c/openstack/nova/+/782172 | |
| 16:28:33 | bauzas | dansmith: gibi: thanks for looking at the prelude, updated ^ | |
| 16:29:05 | bauzas | arf, just saw stephenfin's comments | |
| 16:29:34 | sean-k-mooney | stephenfin: melwitt coul ye take a look at the discussion at https://review.opendev.org/c/openstack/nova/+/769614/2//COMMIT_MSG#18 again | |
| 16:29:50 | stephenfin | will do | |
| 16:30:38 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Wallaby 23.0.0 prelude section https://review.opendev.org/c/openstack/nova/+/782172 | |
| 16:32:09 | sean-k-mooney | stephenfin: melwitt now that we are passed FF and i have a littel brain power back i have 3 bugs i would like to make progress on https://review.opendev.org/c/openstack/nova/+/769614, https://review.opendev.org/c/openstack/nova/+/777679 and https://review.opendev.org/c/openstack/nova/+/602432 | |
| 16:33:47 | melwitt | sean-k-mooney: I have been watching the discussion but not really understanding what's going on. all I know is experts on numa are disagreeing :) and I was thinking with discussion maybe a new option that yall agree would be possible | |
| 16:34:58 | sean-k-mooney | melwitt: ack, my view is the proported optimisation was never valid or functional in any meaningful way and it was broken by design | |
| 16:35:54 | sean-k-mooney | i think alex agreed with the design part in his last comment but was unsure if the optimiasation acutlly provided a performance imporment | |
| 16:36:20 | manuvakery1 | Hi. what could be a acceptable load average on compute host. I can see its consistently between 30-40 when i stress the vm with same no of cores as compute host | |
| 16:36:38 | sean-k-mooney | and stephenfin was concerend about a regression in functionality and belive the optimisation may have been valid in some cases | |
| 16:37:16 | melwitt | ah, ok | |
| 16:37:35 | sean-k-mooney | if you have 40 cores then a load average of 40 means you are fully utilising the system and not over stressing the cpus | |
| 16:37:45 | sean-k-mooney | manuvakery1:^ | |
| 16:38:02 | sean-k-mooney | so a load average fo <= number of cores meens you are below or at capasity | |
| 16:38:19 | manuvakery1 | its a 48 core host | |
| 16:38:25 | sean-k-mooney | if you exceed it it means there is contention between prcoess to execute cpu instrucutions | |
| 16:38:39 | sean-k-mooney | manuvakery1: 30-40 is prefectly accpable in that case | |
| 16:38:52 | manuvakery1 | thanks sean-k-mooney | |
| 16:39:11 | sean-k-mooney | if the load avergae exceed core count it means the vms are under perferoming because they are cpu starved | |
| 16:39:36 | sean-k-mooney | that may or may not matter depening on your use case but i would not be concerned with your current values | |
| 16:43:58 | manuvakery1 | that means when using cpu over commit, I can expect high load average and my vms can under perform when all are trying to gather cpu . I am ok if my vms are performing little slow but don't want my host machine to be non responsive | |
| 16:43:59 | kashyap | stephenfin: I take it that when you move content, you're _only_ moving content -- or are you also mixing in little fix-ups? | |
| 16:44:13 | kashyap | stephenfin: E.g. I'm looking at the SEV guide | |
| 16:44:35 | stephenfin | I might fix spellings and messed with the structure but it general the content is the same. I tried to keep major reworks separate | |
| 16:44:41 | sean-k-mooney | manuvakery1: we generally recommend confinging the guest to run on a subset of host cores | |
| 16:44:54 | kashyap | Right; I see that you've also added hyperlinks where you can | |
| 16:45:06 | sean-k-mooney | manuvakery1: using vcpu_pin_set before train or cpu_share_set and cpu_dedicated_set after train | |
| 16:45:07 | kashyap | E.g. on line-17 I see you've added the link to _deploying-sev-capable-infrastructure | |
| 16:45:18 | sean-k-mooney | manuvakery1: that way you can ensure that the host os never locks up | |
| 16:45:24 | kashyap | stephenfin: Okay; figured as much - major rework separate. Thx | |
| 16:45:49 | sean-k-mooney | manuvakery1: our general recommendateion is to reserve at least the first core from each numa node or for the OS to use | |
| 16:46:15 | manuvakery1 | sean-k-mooney: ok. I will try that | |
| 16:46:31 | kashyap | stephenfin: Err, thinko above: it's not a link, but an "anchor". | |
| 16:46:58 | sean-k-mooney | manuvakery1: so assuming you have 2 sockets each wtih 12 cores and 24 hypertreads you weroul ideally reserved cores 0,12,24,36 | |
| 16:48:19 | sean-k-mooney | manuvakery1: before train that would be done with vcpu_pin_set=1-11,13-23,25-35,37-47 | |
| 16:48:50 | sean-k-mooney | after train cpu_shared_set=1-11,13-23,25-35,37-47 | |
| 16:49:37 | sean-k-mooney | vcpu_pin_set was in the [DEFAULT] sechtion and cpu_*_set are in the [compute] section of the nova.conf, this need to be set on each compute node | |
| 16:50:46 | manuvakery1 | sean-k-mooney: I am using train. I will see to it. Thanks for your response | |
| 17:18:39 | MrClayPole | We are troubleshooting and issue with our Openstack backup provider (Trilio) and our Storage vender/cinder driver (Zadara). As part of this troubleshooting we've been asked to disable iSCSI multipathing. I can see that this installed as part of the nova deployment in Openstack ansible from the mutipath-tools package. Is it OK to just stop and disable the multipathd services. Then run mutipath -F. Then check with multipath | |
| 17:18:39 | MrClayPole | -ll to ensure its no longer active? | |
| 17:34:09 | openstackgerrit | Merged openstack/osc-placement master: Include usage in 'inventory list', 'inventory show' https://review.opendev.org/c/openstack/osc-placement/+/743976 | |
| 17:55:29 | sean-k-mooney | lyarwood: whats the status of nova-grenade-multinode | |