| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-22 | |||
| 14:43:28 | sean-k-mooney | gibi: im not sure that only admin can list deleted instance or at least all info about them | |
| 14:43:44 | sean-k-mooney | gibi: what im thinking about is the simple tenant usage api | |
| 14:44:05 | sean-k-mooney | where the interval will include the usage for deleted instancen that were active in that interval | |
| 14:44:30 | sean-k-mooney | we may or may not require admin for listing them normally, havent check the api ref | |
| 14:44:44 | gibi | sean-k-mooney: https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/api/openstack/compute/servers.py#L268 | |
| 14:44:47 | sean-k-mooney | but normal teant shave at least limited awarenes | |
| 14:45:42 | gibi | so GET /servers does not return deleted instances to non admins | |
| 14:45:44 | sean-k-mooney | gibi are you sure that takes effect if you use v2 | |
| 14:46:07 | sean-k-mooney | i guess it should | |
| 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 | sean-k-mooney | soft delete is not even guarentted by the api | |
| 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: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 | sean-k-mooney | ... this looks like another case where we force null instead of allowing restore: {} | |
| 14:52:36 | gibi | if you know the uuid you can restore it | |
| 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". | |