| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-09 | |||
| 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 | sean-k-mooney | gmann: we cant remove it | |
| 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: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 | 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: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: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 | |
| 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 | |