| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-26 | |||
| 17:56:18 | sean-k-mooney | so when its primmed no not really | |
| 17:56:33 | dansmith | ack, but apt should mostly just say "yeah already got that" | |
| 17:56:39 | dansmith | minor improvement maybe but nothing major | |
| 17:56:43 | dansmith | in the noise I expect | |
| 17:56:47 | sean-k-mooney | yep it just has to check the index is up to date | |
| 17:57:41 | sean-k-mooney | also i have gigabit networking at home so its going to be pretty fast considing i sit less then 2 miles form where the irish henet mirrors are hosted | |
| 17:58:04 | sean-k-mooney | there hosted in the university i live beside | |
| 17:59:42 | sean-k-mooney | 64 bytes from ftp-node-prod-bl-01.heanet.ie (193.1.193.10): icmp_seq=1 ttl=58 time=7.50 ms | |
| 18:01:13 | sean-k-mooney | vs 64 bytes from 172.20.4.244: icmp_seq=15 ttl=62 time=3.41 ms to my vm :) | |
| 18:58:12 | sean-k-mooney | looks like my clean fedora run is going to fail because the cirros download is hanging | |
| 18:58:29 | sean-k-mooney | so ill just post my old results and node details to the devstack review | |
| 19:12:21 | openstackgerrit | Merged openstack/nova master: Move query param generation to RequestGroup o.vo https://review.opendev.org/c/openstack/nova/+/756894 | |
| 19:33:01 | gmann | stephenfin: lbragstad should not placement_policy.reset() take care of cleaning all default or registered rules? https://review.opendev.org/c/openstack/placement/+/772508/1/placement/tests/unit/policy_fixture.py#36 | |
| 19:33:39 | gmann | I am not completely understanding how it is causing the issue with placement_policy.reset() in test. though i agree on fixing it on oslo policy side | |
| 19:34:05 | gmann | or something i am missing here | |
| 19:58:59 | dansmith | sean-k-mooney: thanks | |
| 20:15:19 | gmann | lbragstad: before I proceed on other patches in that series, one comment about SYSTEM_ADMIN https://review.opendev.org/c/openstack/placement/+/760240/21/placement/policies/base.py#20 | |
| 20:15:56 | gmann | I think we do not need SYSTEM_ADMIN in placement as such | |
| 20:16:40 | gmann | and this way is better and avoid rule deprecation - https://review.opendev.org/c/openstack/placement/+/760235/10/placement/policies/aggregate.py#52 | |
| 20:45:07 | lbragstad | gmann i think that's true with the exception of the usage api since it supports project and system scope? | |
| 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 | |