Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-11-09
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
20:37:38 gmann which make sense to me too after PTG discussion. so from nova API side we say 'sustem_reader is role you need to know host info' and 'project_admin is role to boot instance on requested host' so you can assign those based on users req
20:38:30 sean-k-mooney ya although i think there are more details to be worked out
20:38:32 gmann sean-k-mooney: right, for migrating to new policy, cloud provider needs to change the existing users token
20:39:02 sean-k-mooney like shold a project admin be allowed to do a live migration?
20:39:30 sean-k-mooney shoudl they see the host in the server show (based on the above no unles they have system_reader)
20:40:42 gmann sean-k-mooney: as default policy no but live migration case we opened for system as well as project scope also. in case use case is to allow users to perform live migration.
20:40:46 sean-k-mooney giving the proejct admin system reader also feels slightly wrong
20:41:18 gmann sean-k-mooney: let me propose doc update what we agreed in PTG and then we can see how it looks like. it is too much asking to providers or ok.
20:41:19 sean-k-mooney e.g. im not sure you should have readonly access to everything
20:41:53 sean-k-mooney gmann: well im trying to gague the impact to us downstream from a support point of view
20:43:10 gmann If provider want to allow any users to boot on requested host then giving system_reader to them not bad so that they can access host info.
20:43:43 sean-k-mooney gmann: tehy could also acess other info right
20:43:51 sean-k-mooney e.g. list all servers
20:43:59 sean-k-mooney or all keypairs
20:44:09 sean-k-mooney for all users
20:44:15 gmann yeah that is one issue.
20:44:25 sean-k-mooney that makes it a non starter for me
20:44:42 sean-k-mooney system reader is basically full admin but readonly right
20:45:06 sean-k-mooney so i could use it to find the fix ips of other tenants insntances
20:45:43 sean-k-mooney if it was not scoped to noava i could hten list the security groups to find open ports and try connecting to them
20:45:47 gmann well with override policy they can restrict, like list server for all is controlled with separate policy. list keypairs can be restricted with user_id
20:46:15 sean-k-mooney ok
20:46:21 sean-k-mooney but im worried about the support matrix
20:46:24 gmann but i agree that is open things for them which was point in PTG also
20:46:49 sean-k-mooney e.g. use agreeing to support anythong other then the nova default by default with our custoemrs
20:47:12 gmann may be admin need to carefully select such users and trust them if they are allowed to boot on requested host ?
20:47:35 sean-k-mooney maybe but that basically to me say we can never enabel this by default
20:47:43 sean-k-mooney well
20:47:54 sean-k-mooney no its the use fo system_reader that is too heavy here
20:48:16 sean-k-mooney i kind fo would liek if we could use the tenant isolation aggreate info
20:48:31 sean-k-mooney so that with project_admin you coudl list hosts and only see those hosts
20:48:41 sean-k-mooney so no system reader
20:48:54 sean-k-mooney needed to boot to a host you are allowed to boot too
20:49:28 sean-k-mooney if you are not limited to an aggreate i guess that would list all hosts
20:49:30 gmann but host is not project level info right
20:49:38 sean-k-mooney it kind of is
20:49:48 sean-k-mooney we supprot assocating tenats/project to aggreates
20:50:00 sean-k-mooney via either a placment prefilter or a schduler post filter
20:50:04 gmann but project_admin is our special case. means no where else it is being used
20:50:41 sean-k-mooney that the thing i see it potally being a thing in other services too
20:50:53 gmann ah yeah
20:51:36 sean-k-mooney i can totally see project admins being allowed to create users for a project in there project only via keystoen for example
20:51:50 sean-k-mooney or managing a subset of roles with in a porject
20:52:12 sean-k-mooney e.g. givie a user project_reader, porject_admin or project member
20:52:22 sean-k-mooney for that project
20:52:23 gmann also i think neutron might have when they do new policy like attr level policy rule etc
20:52:56 sean-k-mooney right i could see requiring proejct_admin to create shared networks for example
20:53:06 sean-k-mooney or better example
20:53:09 gmann so both options (sys reader or project admin) have pros and cons.
20:53:13 sean-k-mooney adding a qos policy to a network
20:53:37 melwitt I'm not 100% following this convo but wanted to mention I think it's normal and expected that users will have to request and use appropriate tokens (and have appropriate roles) for individual APIs and that if we try to fit everything a user can possibly want to do to fall under one token scope/role then we're going back toward the "admin does everything" direction, trying to make everything fit into one box again
20:53:38 sean-k-mooney to make proejct_admin work we woudl need other code changes
20:54:52 sean-k-mooney melwitt: multiple tokens totally makes sense but i dont think system_reader is approcate for anyoen that you dont fully trust
20:55:13 sean-k-mooney so i can see system reader ever be appliable for a tenant of a vexhost cloud
20:55:22 sean-k-mooney that did not work at vexhost
20:55:26 gmann melwitt: yeah. project_admin was really a temp think with assumption that system scope users to allow creating server for projetcs
20:56:22 sean-k-mooney the main usecasue for system_reader is for audits right
20:56:44 sean-k-mooney so by default you would want system_reader to be able to read across multipel projects
20:57:04 sean-k-mooney where as proejct_reader would be the same fucntion for a singel project
20:57:13 sean-k-mooney and domain is inbetween
20:57:22 sean-k-mooney read only access to all proejct in a domain
20:57:30 sean-k-mooney *project resouces
20:59:19 sean-k-mooney if you require something more the system_reader for inter proejct server list then it kind of breakes its orginal usecause
20:59:46 sean-k-mooney anyway its late and im hungry so ill call it a night
20:59:55 sean-k-mooney gmann: thanks for the info o/
21:00:21 gmann but if any users is allowed to boot on requested host then it is special user right.
21:00:56 gmann sean-k-mooney: sure. take rest. We can discuss tomorrow.
22:30:20 itsjg Hello! Could someone help point me in the right direction, I can't get a machine to migrate off an old host due to the "No valid host found for cold migrate (HTTP 400)" error. I have tried setting every debug logging level to maximum but can't get any further details as to why nova-scheduler is not moving the VM to a different host. I have plenty of capacity across the whole cluster, checked all compute services across the whole cluster, etc. I guess f
22:30:20 itsjg an easy way to see why the scheduler throws an error, is there some place to look that I'm missing?
23:32:26 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Improve policy doc for supported scope info https://review.opendev.org/762013
23:33:12 gmann sean-k-mooney: melwitt johnthetubaguy ^^ adding nova supported scope & roles into doc
23:34:42 melwitt ack
23:51:47 openstackgerrit Merged openstack/nova master: rbd: Only log import failures when the RbdDriver is used https://review.opendev.org/761762
#openstack-nova - 2020-11-10
00:31:53 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Improve policy doc for supported scope info https://review.opendev.org/762013
00:44:02 openstackgerrit MaAoyu proposed openstack/os-traits master: bump py37 to py3 in tox.ini https://review.opendev.org/757432
01:09:43 openstackgerrit Merged openstack/nova stable/victoria: Update pci stat pools based on PCI device changes https://review.opendev.org/761700
04:52:40 openstackgerrit jichenjc proposed openstack/nova master: Print more helpful info when qemu validation failed https://review.opendev.org/762035
06:28:08 openstackgerrit Xinran WANG proposed openstack/nova-specs master: SRIOV Enabled Nic Support Specification https://review.opendev.org/742785
07:03:47 openstackgerrit Xinran WANG proposed openstack/nova-specs master: SRIOV Enabled Nic Support Specification https://review.opendev.org/742785
09:05:34 bauzas good morning Nova
09:41:07 lyarwood Morning
10:38:48 gibi o/
11:22:35 gibi "Delay in Elastic Search: Up to date"
11:22:44 gibi hm, did infra cleared the 144 hours of queue?
11:32:48 stephenfin lyarwood, gibi, kashyap: Could you folks cast your eye over https://review.opendev.org/#/q/topic:bp/smarter-usb-devices this week?
11:34:10 gibi added to my list, but it is now behind the cyborg shelve/unshelve patch where I'm really late already.
11:35:34 kashyap stephenfin: On a phone; will queue, sir
12:04:41 sean-k-mooney lyarwood: is "libvirt.libvirtError: internal error: missing block job data for disk 'vda'" something that is currently happening on bionic
12:05:22 sean-k-mooney it looks like that is what is calling the grenade multi node job to fail during a paused live migratrion
12:07:54 lyarwood sean-k-mooney: yeah https://bugs.launchpad.net/nova/+bug/1901739 - I should move this back to open
12:07:54 openstack Launchpad bug 1901739 in OpenStack Compute (nova) " libvirt.libvirtError: internal error: missing block job data for disk 'vda'" [High,Fix released] - Assigned to Lee Yarwood (lyarwood)
12:09:17 lyarwood updated
12:09:51 sean-k-mooney ok do w ehave a workaround e.g moving master to focal for grenade
12:10:06 sean-k-mooney victoria should have been focal anyway right
12:10:10 lyarwood sean-k-mooney: correct
12:10:24 lyarwood sean-k-mooney: and we are going to backport moving these jobs to focal to stable/victoria AFAIK
12:11:09 lyarwood brb
12:16:49 sean-k-mooney oh you removed the parent of the grenade job by mistake but https://review.opendev.org/#/c/742056/ corrects it and movs to v3

Earlier   Later