| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-05 | |||
| 16:56:09 | gmann | yeah with switching the CONF.encorce_scope to false first and then true | |
| 17:06:47 | dansmith | gmann: yeah, index:get_all_tenants and index are in the same boat :/ | |
| 17:08:47 | gmann | dansmith: you mean with the new direction or existing scope_type? | |
| 17:09:08 | gmann | but in both case anyone allow to do index:get_all_tenants should be allow to do index right? | |
| 17:09:15 | dansmith | gmann: I mean checking index before index:get_all_tenants and failing the scope check | |
| 17:09:32 | dansmith | gmann: that's not the problem | |
| 17:09:34 | gmann | but both are same scope_type | |
| 17:09:58 | gmann | oh no, sorry | |
| 17:09:58 | dansmith | gmann: the problem is that both aren't allowed for system:* but we'll fail on the first one before we get to the second one, even if we set the check_str=* | |
| 17:10:30 | dansmith | it's not actually a problem because as you mention, their scope restriction will be the same, it's just a matter of verification in the tests | |
| 17:10:39 | gmann | yeah | |
| 17:10:43 | dansmith | let me propose a change to common_policy_check and see what you think | |
| 17:10:51 | gmann | +1 | |
| 17:15:33 | gibi | bottom line: ospurge works and can be used but it does not handle default security group yet. | |
| 17:15:37 | gibi | hups | |
| 17:15:47 | gibi | wrong window | |
| 17:37:26 | opendevreview | Dan Smith proposed openstack/nova master: WIP: Allow per-context rule in error messages https://review.opendev.org/c/openstack/nova/+/816865 | |
| 17:37:32 | dansmith | gmann: ^ | |
| 17:37:54 | dansmith | gmann: that lets me pass a function that will decide if we should fail on index or index:get_all_tenants | |
| 17:38:37 | dansmith | it means that we don't actually pass the parent check to make sure the child check is the one that fails, but only in the case where the scope_types= is what causes us to fail | |
| 17:39:02 | dansmith | (in the case where we have overridden the parent check to be @) | |
| 17:43:20 | gmann | dansmith: can you give some example of rule_name in this ^^ case? | |
| 17:45:14 | dansmith | gmann: https://termbin.com/0w1b | |
| 17:47:43 | dansmith | that's snips from multiple places, hopefully that makes sense | |
| 17:48:12 | dansmith | I would push up my actual test changes, but they are a TOTAL mess atm :) | |
| 17:49:44 | gmann | dansmith: so in case of project scoped context they will fail on all-tenant as it will index policy | |
| 17:50:06 | gmann | and for system reader case, it will fail on index but we want to skip that and test all-tenant right? | |
| 17:51:07 | dansmith | for project member, it will fail index:get_all_tenants | |
| 17:51:12 | dansmith | for project admin, it will succeed | |
| 17:51:32 | dansmith | for system * it will fail on index (because of scope check requiring project) | |
| 17:51:50 | dansmith | the callable makes sure we assert the right rule name in the error message for system:* and project:member | |
| 17:52:04 | gmann | yeah for system* so how you will test index:get_all_tenants when index will fail first | |
| 17:52:22 | dansmith | well, that's my point.. we won't :) | |
| 17:52:32 | gmann | yeah | |
| 17:52:41 | dansmith | in reality, it doesn't matter because they will be stopped there (operator can't override scope_types in their config file) | |
| 17:53:10 | dansmith | if you think we really need to, then we have to do something more complicated | |
| 17:53:41 | dansmith | your NOTE in there about rule_name=None, however, seems intended for this purpose, but is less specific than what I have there | |
| 17:54:39 | gmann | dansmith: no, I was thinking from operator perspective. so index policy has to be system+project scoped so yeah test passing/failing on system for all-tenant is ok | |
| 17:55:30 | gmann | dansmith: by this "for system * it will fail on index (because of scope check requiring project)" do you mean you will modify index policy to project scoped only? | |
| 17:57:25 | gmann | if so then we need to to little magic in multi-policy like if system scoped token then check all-tenant policy only and not index-policy. | |
| 17:57:50 | dansmith | gmann: yeah that's what I'm doing, working on making those project-only again | |
| 17:58:18 | dansmith | I think for these cases, enforce_scope=project will handle that for us | |
| 17:59:35 | gmann | so we want system user to do only 1. get all tenant instances and 2. get single tenant instances with all-tenant=true but NOT 3. get specific tenant instances directly | |
| 17:59:38 | gmann | ? | |
| 18:00:08 | dansmith | gmann: what we discussed on wednesday (and before) is that system users don't get to see project resources, so they can never list instances | |
| 18:00:09 | gmann | as filtering instances of single tenant-id is only allowed with all-tenant parameter | |
| 18:00:35 | gmann | dansmith: ^^ this is one way to do for them in nova imementation | |
| 18:00:58 | gmann | we may want to change that in that case | |
| 18:02:51 | dansmith | gmann: okay I'm confused | |
| 18:02:58 | gmann | dansmith: may be I am confusing with current and newthings. system I mean domain admin who will be allowed to do all-tenant instances | |
| 18:03:00 | dansmith | I'm working on https://review.opendev.org/c/openstack/governance/+/815158/7/goals/selected/yoga/consistent-and-secure-rbac.rst line 144 | |
| 18:03:16 | dansmith | gmann: ah, no I'm talking about system:* specifically :) | |
| 18:03:46 | gmann | dansmith: ohk, so new-system as per our discussion | |
| 18:03:54 | dansmith | yeah | |
| 18:04:33 | gmann | dansmith: say with doamin-admin, we want index to be project+domain or just project ? | |
| 18:05:03 | gmann | because we have to think on filter instance by tenant also in this case | |
| 18:05:05 | dansmith | gmann: yeah I think it'll be domain+project at that point | |
| 18:05:12 | gmann | ohk, +1 | |
| 18:05:31 | gmann | that will make sense. that what i was asking but sorry confused with system | |
| 18:05:43 | dansmith | all good, it's all very confusing :) | |
| 18:05:58 | gmann | so now onwards we talk on new things on old way:) | |
| 18:06:03 | gmann | I make note of that | |
| 18:06:14 | gmann | s/on/not | |
| 18:07:19 | dansmith | heh | |
| 18:07:27 | gmann | dansmith: I am sure these multi-policy testing stuff will be more conflicted in the 'GET server with additional attributes' | |
| 18:07:45 | dansmith | okay, I haven't gotten to that yet | |
| 18:07:53 | gmann | there are many embedded confusing policy there | |
| 18:08:36 | dansmith | yeah | |
| 18:11:59 | dansmith | gmann: I wish I had thought of this before I started the refactor, | |
| 18:12:20 | dansmith | but I also think these tests should provide just the list of who can do a thing, and have it subtract those from the all_contexts lists, and assert which ones can't | |
| 18:12:32 | dansmith | it would make things a lot less verbose and easier to read I think, | |
| 18:12:48 | dansmith | and since you assert that auth+unauth==all, I don't think you lose anything by making it less verbose | |
| 18:16:00 | gmann | dansmith: yeah, and I am realizing now asserting on actual scope_type (for multi-policy API) can give us more clarity on 'who can do a thing' so that we fix the mulit-policy things on scope_type if there is under or over -permission | |
| 18:17:01 | gmann | I am thinking not to skip/mock scope_type checks for multi-policy API, skip/mock scope_type only when different APIs policy need to be skipped for testing separate operation on same resoruce | |
| 18:18:09 | dansmith | gmann: I think I know what you mean, and I think I agree :) | |
| 18:20:01 | gmann | dansmith: are you handing the server-boot-on-specific-host case also? this one- https://review.opendev.org/c/openstack/nova-specs/+/793011 | |
| 18:20:46 | gmann | if not then I can re-spin the spec as it need microversion bump also. I think we have clear direction now as per wed discussion. | |
| 18:20:52 | dansmith | gmann: not yet | |
| 18:21:12 | dansmith | gmann: I'll skip that one in what I'm doing for now then | |
| 18:21:20 | gmann | ok | |
| 18:31:20 | EugenMayer | is there any way to open a serial tty on the terminal when using nova? | |
| 18:34:50 | EugenMayer | I would like to have this on the terminal so c&p is integrated | |
| 18:36:26 | dansmith | gmann: I'm still failing flavor policy but I think I'm going to clean up what I have a little and push it up to get some read on it before I delve into another module | |
| 18:36:45 | dansmith | (failing flavorextraspecs because they depend on server policy to be clear) | |
| 18:45:01 | gmann | dansmith: ohk, in that case can we just set_override CONF.enforce_scope=false for server request and then enable before flavorextraspecs ? | |
| 18:45:55 | gmann | or you mean 'os_compute_api:os-flavor-extra-specs:index' policy | |
| 18:46:13 | sean-k-mooney | EugenMayer: you can specify addtion serial port | |
| 18:46:22 | sean-k-mooney | in the image propertiese | |
| 18:46:44 | sean-k-mooney | the first will be use for the console but the rest could be used for host comumnication it that is what you wanted | |
| 18:47:05 | dansmith | gmann: I mean those tests appear to do things like servers/detail before/after flavor extra specs work and fail with contexts that don't work anymore | |
| 18:47:20 | dansmith | gmann: I will clean then up, or hack around in the first patch, but I'm about out of steam for the week | |
| 18:47:26 | dansmith | and want to get something up that is close | |
| 18:49:34 | gmann | dansmith: with new direction, this policy needs to be made more granular now. 1. for flavor API showing extraspecs for system user 2. flavor extraspecs in GET servers for porject users | |
| 18:50:00 | dansmith | ah, right because of the nested flavors right? | |
| 18:50:04 | gmann | yeah | |
| 18:50:08 | sean-k-mooney | gmann: personally i think even project reader shoudl be able to see extra specs | |
| 18:50:23 | sean-k-mooney | you cant really choose between flavor properly without seing them | |
| 18:51:04 | gmann | sean-k-mooney: so indexing the flavor extra specs are system+project things but having extraspec in GET response if only project things | |
| 18:51:31 | sean-k-mooney | im not sure what you meen by indexing flagor extra specs | |
| 18:51:37 | gmann | dansmith: we might need such granularity in more policy as we de-coupling the system form project resources but need to check case by case | |