| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-05 | |||
| 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 | |
| 18:51:42 | opendevreview | Dan Smith proposed openstack/nova master: WIP: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206 | |
| 18:51:48 | dansmith | gmann: ack | |
| 18:52:24 | gmann | sean-k-mooney: i mean this '/flavors/{flavor_id}/os-extra_specs/' | |
| 18:52:43 | sean-k-mooney | i think that should really be readable by everyone | |
| 18:53:02 | sean-k-mooney | i know there are reason to hide it in some cases but in general by default i think it shoudl be open | |
| 18:53:24 | sean-k-mooney | and i think the same really shoudl be true of the server show | |
| 18:54:28 | dansmith | sean-k-mooney: what kinds of things could be in flavor extra specs that would be sensitive? | |
| 18:54:41 | dansmith | topology of the instance isn't really sensitive if you can see the rest of the instance, IMHO | |
| 18:54:47 | dansmith | trying to think of what else could be in there though | |
| 18:54:53 | sean-k-mooney | dansmith: non standard extra spec used for filters | |
| 18:55:00 | sean-k-mooney | that about it | |
| 18:55:32 | dansmith | something they passed during create to cause it to be scheduled in some way right? | |
| 18:55:34 | sean-k-mooney | we could exclude un namescased extra specs and the filter ones by default for non admin | |
| 18:55:42 | dansmith | that's not really something we should show to member but hide from reader | |
| 18:56:06 | dansmith | (which I think is your point) | |
| 18:56:59 | sean-k-mooney | yes | |
| 18:57:07 | sean-k-mooney | we likely would want to hide https://github.com/openstack/nova/blob/master/nova/api/validation/extra_specs/aggregate_instance_extra_specs.py#L53 | |
| 18:57:28 | sean-k-mooney | anything prefixed with aggregate_instance_extra_specs: or that is not namespaced | |
| 18:57:33 | sean-k-mooney | form member and reader | |
| 18:57:56 | sean-k-mooney | but hw:mem_page_size=large e.g. this flavor use hugepages is proably relevent to memebers | |
| 18:58:01 | dansmith | do we hide that today? | |
| 18:58:35 | sean-k-mooney | i dont know what the default is since im almost alwasy admin when i interact but its contoled by poligy | |
| 18:58:40 | sean-k-mooney | *policy | |
| 18:58:45 | sean-k-mooney | however its all or nothing | |
| 18:58:48 | dansmith | okay | |
| 18:58:48 | sean-k-mooney | we dont filter | |
| 18:59:12 | dansmith | but regardless, I think you point (which I agree with) is that there doesn't likely need to be any that we distinguish between project member and reader | |
| 18:59:15 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/policies/flavor_extra_specs.py | |
| 18:59:19 | dansmith | and that's kinda the point of reader, AIUI | |
| 18:59:23 | gmann | it is reader by default currently | |
| 18:59:28 | sean-k-mooney | PROJECT_READER_OR_SYSTEM_READER | |
| 18:59:32 | sean-k-mooney | yep | |
| 18:59:43 | dansmith | ++ | |
| 19:00:49 | sean-k-mooney | gmann: i toght you were suggestign changing that | |
| 19:01:36 | gmann | sean-k-mooney: no, i mean we need to make it granular for GET servers so that we can remove system_reader from GET server as they cannot GEt server right | |
| 19:01:38 | sean-k-mooney | flavor unless you use the flavor access api to me are system resouces | |