| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-05 | |||
| 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 | sean-k-mooney | we dont filter | |
| 18:58:48 | dansmith | okay | |
| 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 | |
| 19:01:58 | gmann | flavor API will be same so no change | |
| 19:02:11 | dansmith | gmann: yes, because you can get these either through servers or flavors, | |
| 19:02:16 | gmann | yeah | |
| 19:02:21 | dansmith | yeah | |
| 19:03:41 | sean-k-mooney | i cant find it but i tought we had a policy for if this si shown in server detail by the way | |
| 19:03:52 | sean-k-mooney | maybe re never added it | |
| 19:05:26 | sean-k-mooney | i guess ya we just have this one policy https://github.com/openstack/nova/blob/master/nova/policies/flavor_extra_specs.py#L76 | |
| 19:08:27 | gmann | yeah, this one | |
| 19:27:08 | lyarwood | melwitt: FWIW the nova-next change to noVNC from source did actually fail on a novnc test with the latest run https://zuul.opendev.org/t/openstack/build/f626656bc01b4cb7aee847e21f3b4b4c - I don't have the energy to look into it now but will take a look on Monday. | |
| 19:35:17 | sean-k-mooney | is openstack server restore undelete? | |
| 19:35:33 | sean-k-mooney | i tought it was restore form backup but i guess not | |
| 19:37:08 | lyarwood | https://docs.openstack.org/api-ref/compute/#restore-soft-deleted-instance-restore-action - yup it restores soft deleted instances | |
| 19:37:38 | sean-k-mooney | ok in my head i put backup and restore together | |
| 19:38:55 | lyarwood | sean-k-mooney: I thought you just spawned a new instance from the backup image? | |
| 19:39:15 | sean-k-mooney | you do a rebuild | |
| 19:39:31 | sean-k-mooney | well it depend on why you are doing it | |
| 19:40:04 | sean-k-mooney | infra failure then sure but if its just to roleback guest state tehn rebuild | |
| 19:50:13 | melwitt | lyarwood: ack, I'll look and see if anything stands out to me | |
| 19:58:00 | opendevreview | Lee Yarwood proposed openstack/nova master: DNM - Test tempest-integrated-compute-centos-8-stream https://review.opendev.org/c/openstack/nova/+/799996 | |
| 20:39:26 | opendevreview | melanie witt proposed openstack/nova master: nova-next: Deploy noVNC from source instead of packages https://review.opendev.org/c/openstack/nova/+/816738 | |
| #openstack-nova - 2021-11-06 | |||
| 06:23:52 | opendevreview | melanie witt proposed openstack/nova master: nova-next: Deploy noVNC from source instead of packages https://review.opendev.org/c/openstack/nova/+/816738 | |
| 09:15:03 | EugenMayer | With openstack, are there only web-based consoles? I would like to have a terminal based serial console so c&p works. Any hints on how to get this working? | |
| 10:33:05 | lyarwood | EugenMayer: https://docs.openstack.org/nova/queens/admin/remote-console-access.html#serial-console I thought this produced a connection URI you could use from a cli ? | |
| 10:55:38 | EugenMayer | lyarwood asking myself, which client can be used on the cli | |
| 10:56:13 | lyarwood | it's actually a websocket so something like this should work | |