Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-22
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".
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 -ll to ensure its no longer active?
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: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
17:55:51 sean-k-mooney did you have a patch to move that to v3? or am i just wishing you did
17:56:18 sean-k-mooney ah https://review.opendev.org/c/openstack/nova/+/778885
17:56:47 sean-k-mooney is ^ going to happen this cycle?
18:19:49 ricolin stephenfin, hi about https://review.opendev.org/c/openstack/nova/+/781210
18:21:35 ricolin I update some logs in comments, for what I can tell it only happen to bionic environment from aarch64. it disappear once I moved to focal
18:32:44 openstackgerrit Merged openstack/nova stable/victoria: Add config parameter 'live_migration_scheme' to live migration with tls guide https://review.opendev.org/c/openstack/nova/+/781211
18:36:34 stephenfin ricolin: That looks like a bug. Can you open a bug on launchpad and I'll take a look tomorrow?
18:36:52 stephenfin ricolin: Referring to this http://paste.openstack.org/show/803788/
18:47:20 ricolin stephenfin, thanks I will open one for both errors I found
19:06:36 sean-k-mooney that a python2 vs python3 issue i think
19:07:06 sean-k-mooney ricolin: master is not intended to run on bionic by the way
19:07:36 sean-k-mooney it might be compatiable but its not part of the offical testing runtimes anymore
19:08:04 sean-k-mooney we have 1/2 jobs that use it for reasons but the arm jobs should be on focal
19:09:08 sean-k-mooney ricolin: ussuri was the last release to use bionic

Earlier   Later