| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-26 | |||
| 17:47:21 | dansmith | sean-k-mooney: was that a fairly fat devstack config? like all the normal services? | |
| 17:48:54 | sean-k-mooney | yes an no ill past bin it | |
| 17:49:08 | sean-k-mooney | http://paste.openstack.org/show/802010/ | |
| 17:49:19 | sean-k-mooney | no swift or heat but i hav ecinder and horizon | |
| 17:49:58 | gmann | dansmith: sean-k-mooney nice. are you running it on fresh machine with/wihtout devstack-parallel or with/without unstack/stack ? | |
| 17:50:16 | sean-k-mooney | so nova,neutron,placement,cinder,glance,horizon,tempest with ml2/ovs | |
| 17:50:39 | dansmith | gmann: when I test, I run it with/without parallel on a "warmed up" machine, i.e. where /opt/stack already has the projects cloned, like gate | |
| 17:50:55 | dansmith | we could definitely parallelize the cloning of all the projects too | |
| 17:51:01 | sean-k-mooney | gmann: basically the same for my test | |
| 17:51:07 | sean-k-mooney | gmann: i stacked then unstack | |
| 17:51:09 | dansmith | sean-k-mooney: ack, okay mine is no cinder or horizin | |
| 17:51:18 | dansmith | right, stack/unstack/stack | |
| 17:51:28 | sean-k-mooney | then stacked again to get the baseline time unstackted. and stacked in parallel mode | |
| 17:51:49 | sean-k-mooney | so all the pacakge and repos should be cached or clonned | |
| 17:51:52 | gmann | yeah clone is not something to count in this | |
| 17:54:31 | sean-k-mooney | i did not have OFFLINE=True which i can do that would disable all package installs and clones but it should not really be a factor in my current testing | |
| 17:54:42 | sean-k-mooney | ill let ye both know how the fresh install goes | |
| 17:55:15 | dansmith | once the system is warmed up I don't think that would do much anyway, right? | |
| 17:56:11 | sean-k-mooney | it will prevent it even trying to do apt/dnf install i dont think it really affect pip however | |
| 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 | |