Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-22
10:17:03 openstackgerrit Sylvain Bauza proposed openstack/nova master: Wallaby 22.0.0 prelude section https://review.opendev.org/c/openstack/nova/+/782172
10:17:16 bauzas gibi: first round of prelude ^
10:17:21 gibi bauzas: on it :) thank you
10:17:23 bauzas I need to dad taxi
10:17:40 bauzas gibi: do we have deprecations or removals this cycle ? AFAIK, nope
10:22:44 gibi bauzas: I will check that but I don't remember any deprecation
10:28:53 lyarwood gibi / bauzas ; do workarounds count?
10:42:01 gibi lyarwood: it is in context of the reno prelude. If this is an important to highlight in the prelude then lets do that
10:42:54 lyarwood gibi: it already has it's on releasenote so I wouldn't bother tbh, I just wasn't sure what the criteria was for the prelude
10:43:32 gibi I think there are no hard criterias
10:51:08 MrClayPole Hi, We are looking to start regular "apt" patching in our test environment we a view of pushing to production. Currently we are running on Ubuntu 18.04.1 with OSA Rocky in test. Is there anything we need to be aware or look at first before we start testing from a Nova prospective? I believe there may have been some issue is the past with live migration? Is that still an issue?
10:53:13 gibi MrClayPole: I suggest to read https://docs.openstack.org/nova/latest/user/upgrade.html
10:53:30 MrClayPole Thanks I'll take a look
10:53:52 gibi MrClayPole: and also suggest to read the relese notes related to the version you are upgrading to https://docs.openstack.org/releasenotes/nova/
12:32:43 gibi bauzas: left feedback in the reno prelude
13:53:16 lyarwood elod / melwitt / bauzas ; some stable/victoria changes ready for review if anyone has time btw - https://review.opendev.org/c/openstack/nova/+/773320 https://review.opendev.org/c/openstack/nova/+/772480 https://review.opendev.org/c/openstack/nova/+/773320 https://review.opendev.org/c/openstack/nova/+/773321/
13:53:37 lyarwood if there's anything I can review in return let me know!
14:00:57 elod lyarwood: ack, will try to review some
14:31:19 gibi cores, as far as I see we have a sort of rule that only admin can list deleted instances. What about soft-delete instances? As far as I see today only admins can list soft-delete instances. So a user knows the uuid of its accidentally deleted server then they can restore it but if they only know the name of the server then there is no way for the user to list the soft-delete instances to find out
14:31:25 gibi which one they want to restore
14:34:05 gibi so if I know the uuid then I can show it and restore it, but if I only know the name then there is no way I can find the uuid
14:43:09 gibi we do not list soft-delete vms by default https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/db/sqlalchemy/api.py#L1557 and a filter like vm_state=soft-delete does not change this
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

Earlier   Later