Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-09
18:28:07 sean-k-mooney not really
18:28:23 mnaser because right now in some of those bigger vms, nova-compute reports down as it goes through the restart that takes ~6m
18:28:27 sean-k-mooney we could but we have to wait for them all to complete
18:29:09 sean-k-mooney so if we dispatch them to a tread pool we will get more paralium but we will the fill the pool and have to wait for it to complete
18:29:33 sean-k-mooney plugging form a nova side shoudl not take that long in general
18:29:45 sean-k-mooney with the native driver its much much faster
18:30:17 mnaser ok i guess thats' probably going to be my next step to see how that improves it
18:30:19 sean-k-mooney as its not spawnting multiple shells via privsep in that process
18:31:32 mnaser sean-k-mooney: seems valid, i'll check it out and report and let you know what sort of improvement i see :)
18:31:34 sean-k-mooney putting it in a tread pool would basically just increase the batch size at the cost of memroy during start up.
18:32:17 sean-k-mooney cool there would be a speed up form a thread pool but not as much as using the native driver
18:50:33 openstackgerrit Merged openstack/nova master: virt: Remove 'get_per_instance_usage' API https://review.opendev.org/749318
18:51:22 lyarwood \o/
18:59:50 sean-k-mooney lyarwood: was that for the removal ^
19:00:10 sean-k-mooney oh because something finally merged in the gate :P
19:00:21 sean-k-mooney both are good
19:36:21 dansmith hmm, on focal the ceph devstack plugin tells me I'm on an unsupported distro
19:36:30 dansmith lyarwood: any idea about that?
19:37:52 lyarwood dansmith: no idea, I thought it was there?
19:37:55 lyarwood # git grep f32
19:37:57 lyarwood devstack/lib/ceph: if [[ ! ${DISTRO} =~ (focal|bionic|xenial|f31|f32) ]]; then
19:38:27 dansmith hmm, I nuked opt/stack but maybe I've got residue somewhere
19:38:33 dansmith it's checking against a list that doesn't include focal
19:38:53 dansmith heh, doh
19:38:54 dansmith enable_plugin devstack-plugin-ceph /home/dan/devstack-plugin-ceph
19:59:32 sean-k-mooney oh your using your local copy
19:59:44 sean-k-mooney got an old version checked out
19:59:49 dansmith yeah, I nuked /opt/stack and then it cloned it right back there for me :P
20:00:17 sean-k-mooney yep i do that intentionally for the most part and put all my repos in /opt/repos
20:00:32 sean-k-mooney just so it does not clone over itself
20:05:21 sean-k-mooney gmann:is there a spec or something covering the use of token scopes with nova. i dont see anythin after the ussuri spec https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/policy-defaults-refresh.html
20:05:44 sean-k-mooney that does nto cover the domains
20:06:06 sean-k-mooney the 4 scopes in https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/policy-defaults-refresh.html#use-cases make sense to me
20:06:41 sean-k-mooney but i dont see a defeintion for system_member, project_admin, domain_(reader, member or admin)
20:07:36 sean-k-mooney we have some interset down stream in supporting a 3*3 matix (reader, memeber, admin) *( project, domain, system)
20:08:38 sean-k-mooney but i dont recall ever disscuing domains or proejct admin and system memebr in the context of nova upstream
20:09:52 sean-k-mooney https://review.opendev.org/#/c/698397/14/etc/rbac-persona-accounts.yaml.sample has entries for all 9 roles
20:10:31 sean-k-mooney but given we have not had any specs or cross project session on this im having a hard time relateing that to how we would support this in nova
20:10:50 sean-k-mooney gmann: i know there was a pop up team but any pointers on where this might have been discussed
20:12:55 sean-k-mooney melwitt: johnthetubaguy any input on ^
20:16:21 gmann sean-k-mooney: we have project_admin in nova for case like creating server with host specify but system_member is not there as not needed from current policy rules
20:16:41 gmann also domain scope (it's three pesona)
20:16:56 sean-k-mooney do you have docs for this
20:17:06 sean-k-mooney there were only 4 included in the spec
20:17:12 sean-k-mooney project_admin was not one of them
20:17:17 gmann yeah, I updated policy doc for that
20:18:04 sean-k-mooney ok because form a spec point of vew we only ever approved system_admin, project_memeber system_reader and project_reader
20:18:32 gmann sean-k-mooney: this does not include what all combination nova support but give an idea on new policy - https://docs.openstack.org/nova/latest/configuration/policy-concepts.html
20:18:33 sean-k-mooney so since this is an api cahnge im kind of confused why we dont have a spec for supporting other scopes and ropels in nova
20:19:23 melwitt yeah, that ^ is the doc I was searching for wrt the support in nova
20:19:24 gmann sean-k-mooney: project_admin came up during implementation only and that is for create server with specific request (like force host, zero disk flavor etc) on;y
20:19:45 sean-k-mooney ok but are we actully using it in code
20:20:10 sean-k-mooney https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/policy-defaults-refresh.html is the only spec that exist for this so really without a spec to add it we should not be useing in the api right
20:20:58 gmann as part of policy defaults yes but we do not change token in nova right? whatever token is used for API access will be validated against the policy values
20:21:45 sean-k-mooney my concern is really for domains im concerend that a domain member may not have a project
20:21:56 gmann sean-k-mooney: I am not sure about supporting other scopes. if we want domain scope control in nova then we need to see what all nova API operations are domain level and system level.
20:22:01 sean-k-mooney maybe they do but if they dont then that will break our api assumtions
20:22:11 gmann i never thought of domain in nova.
20:22:28 sean-k-mooney its come up downstream my responce is right now we dont support it
20:22:38 gmann and they use domain member user to access nova API ?
20:22:49 sean-k-mooney well its not a thing yet
20:23:06 sean-k-mooney we have a request to supprot RBAC for osp 17 which will be based on wallaby
20:23:15 melwitt yeah, my understanding is that we now have the code needed to handle scoped tokens in nova, so the way that they get used is someone (a user) has to request scoped tokens and use them when they call nova and then policy can validate the token against the policy
20:23:18 gmann ok, in that case they can assign admin/member/reader role on required project
20:23:27 sean-k-mooney but since domain was never discussed upstream i wanted to push back to just the 4 roles we intended to support
20:24:17 sean-k-mooney melwitt: right but we need to agree what scopes and roles are required for each endpoint
20:24:32 sean-k-mooney and what each scope/roles allows you to do
20:24:40 gmann sean-k-mooney: these are combination we support currently - https://github.com/openstack/nova/blob/master/nova/policies/base.py#L48-L54
20:25:00 gmann sean-k-mooney: i can add these in policy doc so that we do not need to point these to code
20:25:20 sean-k-mooney project admin is the only one im not expecting since we nver approved that in a spect
20:25:46 sean-k-mooney the rest make sense to me
20:26:33 sean-k-mooney for example we discussed in the ptg that prject admisn shoudl not be aware of the hosts vms run on
20:26:41 gmann sean-k-mooney: also html policy doc mention the scope of each policy/API as part of oplicy documentation - https://docs.openstack.org/nova/latest/configuration/policy.html
20:26:45 sean-k-mooney but you mentioned that one of the usecase was allowing them to boot on a host
20:26:53 gmann yeah
20:27:10 sean-k-mooney have we released with project_admin yet
20:27:15 gmann you remember in PTG we discuss about it
20:27:35 sean-k-mooney i rememebr the one two weeks ago
20:29:18 gmann my initial thought while adding PROJECT_ADMIN was that this is temp and TODO will remove this - https://github.com/openstack/nova/blob/45e8fa3ade54313754fbea245ad546097150486d/nova/policies/servers.py#L179
20:29:35 sean-k-mooney i kind of which there was a spec for projecft admin because i really ame not sure that the current usaged in the api are valid
20:29:59 gmann but as we discussed in PTG, I think it make sense to keep it and ask users to assign appropriate role to let users to boot on specific host
20:29:59 sean-k-mooney gmann: we cant remove it
20:30:14 sean-k-mooney well not without a microverion
20:30:48 gmann this is policy default change so microversion not required if we change any of these
20:30:52 sean-k-mooney making it sys_admin i think make sense
20:31:10 sean-k-mooney from an interoperablity point of view im not sure i agree
20:31:30 sean-k-mooney for this case since i kind fo want to revert this out and make it system_admin im happy to agree
20:31:30 gmann sean-k-mooney: that is the things we discussed in PTG. my proposal was sys_admin and take project_id as request param.
20:32:07 sean-k-mooney that is a different usecase
20:32:14 gmann but with sys_adm, project_id needs to be passed for which sys admin want to create server for
20:33:07 sean-k-mooney yes so that is the actuall cloud admin creating a server in a project in responce to a supprot request or something
20:33:29 sean-k-mooney that is differnet for giving a customer a project adminsitarto role and allowign them to do it in a self service manner
20:33:39 sean-k-mooney that is what project_admin role would mean
20:34:04 sean-k-mooney gmann: im fine with the sysadmin doing what your proposing
20:34:38 sean-k-mooney but ithe proejct_admin persona im describing i dont think shoudl have any awareness of hosts
20:35:39 sean-k-mooney gmann: anyway thanks ill review the docs you linked.
20:36:05 gmann that was my thought while proposing this but johnthetubaguy melwitt point was it is asking cloud admin to give extra role to user (project_admin or system_reader to know host info) to allow users to boot on specific host
20:36:55 sean-k-mooney so that is something i think we need to actully discuss if we are every to use those poices by default in code
20:37:01 sean-k-mooney vai a spec
20:37:29 sean-k-mooney becaue you are fundimentally change the way the api works allowing operation to work for a different set of users

Earlier   Later