Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-01-26
20:46:37 lbragstad actually - not if enforce_scope=True
20:47:21 gmann lbragstad: yeah usage API use only reader right
20:48:06 gmann if enforce_scope=True then scope_type will care as existing scope is system for admin API
20:51:37 gmann only use case i see is if enforce_scope=False , enforce_new_defaults=True but technically there is no new default for admin APIs its admin only right
21:12:39 openstackgerrit melanie witt proposed openstack/nova stable/ussuri: compute: Lock by instance.uuid lock during swap_volume https://review.opendev.org/c/openstack/nova/+/758732
23:16:07 openstackgerrit Merged openstack/nova master: db: Compact Juno database migration https://review.opendev.org/c/openstack/nova/+/758395
23:56:40 sean-k-mooney lbragstad: gmann im going to stop reviewing the palcemnt series until ye have a chance ot responed regarding defineing SYTEM_ADMIN as a dict and preferably in oslo policy eventually
23:58:00 sean-k-mooney i really think that SYSTEM_ADMIN should be a common shared defintion across all poject and not something that can vary between cloud or services.
23:59:19 gmann sean-k-mooney: lbragstad stephenfin replied on https://review.opendev.org/c/openstack/placement/+/760240/21/placement/policies/base.py#20
23:59:41 gmann sean-k-mooney: we can move to common place but there are few challenge in doing that
#openstack-nova - 2021-01-27
00:00:44 gmann https://review.opendev.org/c/openstack/oslo.policy/+/766536
00:02:03 gmann if we want to support 4th scenario I mentioned in that review then yes we can have otherwise there is no change with SYSTEM_ADMIN and what we have currently
00:03:14 sean-k-mooney well i was suggesting that at a minium we define SYSTEM_ADMIN as
00:03:16 sean-k-mooney SYSTEM_ADMIN = {
00:03:18 sean-k-mooney 'check_str':'role:admin and system_scope:all',
00:03:21 sean-k-mooney 'scope_types': ['system']
00:03:23 sean-k-mooney }
00:03:34 sean-k-mooney but i do prefer having real objects for the personas
00:07:07 sean-k-mooney i am not convice that these shoudl be handeled as a rule based on reading https://review.opendev.org/c/openstack/oslo.policy/+/766536
00:07:43 sean-k-mooney gmann: the thing i want to avoid is SYSTEM_ADMIN meaning differnt things on different clouds.
00:07:57 sean-k-mooney if they want to customis there personsa i think they shoudl defien entirely new ones
00:08:44 gmann challenge in that we cannot add deprecation rule in that which we need at service side
00:09:11 gmann so we can define it as constant for check_str
00:09:15 sean-k-mooney we can make a copy and add deprecations
00:09:29 sean-k-mooney this https://github.com/openstack/nova/blob/3a6c1cbc3a07814b3fecfdc23f28da9294779bcc/nova/policies/migrate_server.py#L35
00:09:35 sean-k-mooney to me is a pug in nova
00:09:53 gmann yeah that is one use case
00:09:58 sean-k-mooney that api is neither systme admin or project admin
00:10:29 sean-k-mooney its realy a union of both
00:10:35 gmann its system admin by default and allow operator to override for project users
00:10:48 sean-k-mooney no its not
00:11:02 sean-k-mooney its defiend right now as project admin or system admin
00:11:21 gmann https://github.com/openstack/nova/blob/3a6c1cbc3a07814b3fecfdc23f28da9294779bcc/nova/policies/migrate_server.py#L27
00:11:51 gmann scope_type both means it allow both scoped token but check_str is what controlling it
00:12:08 sean-k-mooney which is 'rule:system_admin_api
00:12:14 gmann with special string in check_str
00:12:29 sean-k-mooney which becomes rule:admin_api
00:13:00 gmann system_admin_api is 'role:admin and system_scope:all',
00:13:32 sean-k-mooney wher eis that defiend
00:13:42 sean-k-mooney i was looking at https://github.com/openstack/nova/blob/3a6c1cbc3a07814b3fecfdc23f28da9294779bcc/nova/policies/base.py#L16
00:13:45 gmann https://github.com/openstack/nova/blob/3a6c1cbc3a07814b3fecfdc23f28da9294779bcc/nova/policies/base.py#L104
00:14:04 sean-k-mooney oh here https://github.com/openstack/nova/blob/3a6c1cbc3a07814b3fecfdc23f28da9294779bcc/nova/policies/base.py#L103-L108
00:14:04 gmann this one ^^
00:14:26 sean-k-mooney see this is already a problem in that the definiton are different beteen nova and placment
00:14:57 gmann placement has already scope_type so current change for ADMIN-SYSTEM_ADMIN is not needed as such, that is my point on that review
00:15:35 sean-k-mooney ii know its not needed but i dont think we should have default RBAC personcs unless they are the same across all services
00:18:18 gmann ok for consistency if we want to have same default then I am ok. then we can do same in in aggregate API too https://review.opendev.org/c/openstack/placement/+/760235/10/placement/policies/aggregate.py#52
00:18:32 gmann let's see what lbragstad and stephenfin prefer.
00:20:48 sean-k-mooney keystone has the same definiton for system reader as nova for what its worth
00:20:50 sean-k-mooney https://github.com/openstack/keystone/blob/a98f006f854be02e5682390012d8bb917f4f3940/keystone/common/policies/base.py#L48
00:23:35 gmann like base rule we have in nova it is easy for operator to only override the 4-5 base rule only in policy file to make changes for all the policy instead of 200 rules override. that is why we defined thee as rule instead of string
00:24:04 sean-k-mooney so with my downstrem had on im in two minds
00:24:11 sean-k-mooney first we dont support custom policy
00:24:24 sean-k-mooney so our customer are not able to override any fo them
00:24:56 sean-k-mooney on the other had if they where i would have to check the policy difeintion when looking at api issue or suggesting what steps they could take for there given cloud
00:25:38 sean-k-mooney so while i understand its useful for operators to quickly redfien things in reality it will make debug ing much harder
00:26:03 sean-k-mooney e.g. if we have upstream bug reports or they are working with a vendor
00:26:30 sean-k-mooney the interop part of me is schreaming policy is config diriven api behavior
00:26:38 sean-k-mooney which is bad
00:27:12 sean-k-mooney its componded by the fact as a client i have no way of determining what i am alowed to do
00:27:22 sean-k-mooney there is no policy endpoin i can query to figure it out
00:27:55 sean-k-mooney so for me if we have default RBAC personas across multipel project they shoudl be imutable
00:28:52 sean-k-mooney we could provide a way to simpley replce SYSTEM_ADMIN with CUSTOM_SYSTEM_ADMIN via policy.yaml but i think that hsould be the excption rahter then what we expect people to do
00:29:29 sean-k-mooney lbragstad: gmann that is the main context around my view on this and why i think we should have shared constants for the personas
00:31:40 gmann sean-k-mooney: yeah i agree on common persona which provide much needed consistency but we need to see if those should be as constant or rule or rule-with-set-method to add deprecated rule
00:32:28 gmann may be best way is to proceed with constant string. that is one of the possible option we discussed in policy meeting last week
00:34:45 brinzhang_ nightmare_unreal> ack, add to my list, after done my things I will try to fill this issue
00:34:49 brinzhang_ gmann: thanks ^
01:05:25 openstackgerrit Wenping Song proposed openstack/nova master: Replace all_tenants with all_projects in List Server APIs https://review.opendev.org/c/openstack/nova/+/765311
01:05:26 openstackgerrit Wenping Song proposed openstack/nova master: Replaces tenant_id with project_id from Rebuild Server API https://review.opendev.org/c/openstack/nova/+/766380
01:05:26 openstackgerrit Wenping Song proposed openstack/nova master: Replaces tenant_id with project_id from List SG API https://review.opendev.org/c/openstack/nova/+/766726
01:18:19 sapd1_x bauzas, Hi, do we need RHEL for vGPU feature? in the supported matrix, they dont mention Ubuntu or CentOS (https://docs.nvidia.com/grid/latest/product-support-matrix/index.html)
01:19:40 sapd1_x we are running Ubuntu + KVM.
02:09:43 mnaser sean-k-mooney: sorry for the late reply, been dealing with a lot of stuff (move and puppy)
02:10:08 mnaser sean-k-mooney: we run it daily because we noticed when we don't, too many records accumualte and we end up with a near impossible to clean state
02:10:21 mnaser sapd1_x: it should work fine without rhel
02:14:49 openstackgerrit Merged openstack/nova master: libvirt: Drop support for UML https://review.opendev.org/c/openstack/nova/+/743230
02:33:25 lbragstad sean-k-mooney gmann fwiw - i'm fine with constant strings somewhere if that helps move things along
02:35:45 lbragstad i agree having the common personas represented as objects would be ideal
07:28:57 openstackgerrit Wenping Song proposed openstack/os-traits master: remove babel.cfg https://review.opendev.org/c/openstack/os-traits/+/772634
08:44:01 MrClayPole admin0 & lyarwood Thanks for both you help recently. We were able to trace it through to a possible issue with our storage cinder driver.
09:04:14 lyarwood MrClayPole: awesome, np!
09:28:17 bauzas sapd1_x: you're unfortunately absolutely correct
09:47:43 openstackgerrit Wenping Song proposed openstack/os-traits master: remove babel.cfg https://review.opendev.org/c/openstack/os-traits/+/772634
10:25:50 stephenfin bauzas: If you have time this week, there are a couple of DB compaction patches that still need a final +2, starting here https://review.opendev.org/c/openstack/nova/+/758397/
10:26:18 stephenfin Lower priority than gibi's series, but it would still be nice to close that out in Wallaby so I can work on getting alembic integrated (assuming we decide to do that)
10:27:49 bauzas stephenfin: ack, currently reviewing gibi's series
10:28:08 bauzas even if I have to look at https://review.opendev.org/c/openstack/nova/+/769942/
10:28:13 bauzas mypy my love <3
10:35:27 stephenfin bauzas: don't you dare diss mypy
10:36:06 bauzas I love cakes
10:36:12 bauzas but surely it's not mypy
10:36:20 stephenfin boo this man
10:36:22 stephenfin boooooo
10:37:05 bauzas emojis are for the others
13:13:33 lyarwood https://review.opendev.org/q/topic:bug/1909120 & https://review.opendev.org/q/topic:bug/1908075 could use reviews from cores if anyone has time in the coming weeks, simple enough bugfixes.
13:20:24 lyarwood elod / bauzas ; https://review.opendev.org/c/openstack/nova/+/764611 & https://review.opendev.org/c/openstack/nova/+/764612 - can I get stable reviews on these please?
13:20:50 bauzas ack, will try
13:22:36 elod lyarwood: looking
13:24:19 lyarwood many thanks both

Earlier   Later