| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-14 | |||
| 18:54:20 | gmann | sean-k-mooney: I am testing with AZ case for force host. 'host', 'hostname' which use sch I am not testing currently | |
| 18:54:49 | gmann | AZ way is not deprecated right? | |
| 18:55:00 | sean-k-mooney | its stognly discuaged | |
| 18:55:01 | gmann | create server support both | |
| 18:55:13 | sean-k-mooney | its not deperecated and i dont think we want to extend its usage | |
| 18:55:26 | gmann | yeah discuaged but not deprecated | |
| 18:55:30 | sean-k-mooney | i would like to deprecated it | |
| 18:55:51 | gmann | I am just checking compatibility of uuid case | |
| 18:55:58 | sean-k-mooney | its replacement has been avaiable since train | |
| 18:57:18 | sean-k-mooney | gmann: well i gues my point is i dont think we should be supporting this the old way | |
| 18:57:55 | sean-k-mooney | im fine with project admins requesting a host using the info form the hypervior api to get the uuid | |
| 18:58:09 | sean-k-mooney | but im not sure they shoudl be able to force the host and bypass the schudler filters | |
| 18:59:17 | gmann | sean-k-mooney: sure. but in current proposed change I am checking uuid compatibility. But if we want to disallow the bypass the schudler filters that is separate behavior change or we can say 'bypass the schudler filters stop working with new rbac' | |
| 19:00:04 | sean-k-mooney | no i dont think that is really valid. | |
| 19:00:14 | sean-k-mooney | its an iterup issue | |
| 19:00:22 | sean-k-mooney | i cant tell if you are using the new rbac or not | |
| 19:00:34 | gmann | I think we can discuss this separately to deprecate/stop the 'bypass the schudler filters' case instead of mixing two | |
| 19:00:44 | sean-k-mooney | which is why i have argrued that any policy change should be a micorover bump | |
| 19:01:13 | sean-k-mooney | the old az format can work without any nova code changes right | |
| 19:01:19 | sean-k-mooney | with the uuid becaue it accpeted both | |
| 19:01:50 | gmann | yeah that is why I am kind of agree with dansmith concern of 'need of microversion bump' just testing also so that I am fully convinced on interop issue | |
| 19:02:21 | gmann | sean-k-mooney: let's see. i can add host way also in test | |
| 19:02:30 | sean-k-mooney | gmann: can you add a new tempest test to test with the other way to request it with out bypassign the filter | |
| 19:02:40 | gmann | sure | |
| 19:02:46 | sean-k-mooney | cool | |
| 19:03:24 | sean-k-mooney | in which case we would expect the uuid to be in host? or hypervisor_hostname? | |
| 19:03:42 | sean-k-mooney | or in hypervisor_uuid | |
| 19:04:05 | sean-k-mooney | which does not exsit today | |
| 19:04:30 | sean-k-mooney | dansmith: was this what you were poking at^ | |
| 19:05:08 | gmann | if new field then we need microverion bump for sure | |
| 19:05:59 | sean-k-mooney | if feels a little odd to me to do openstack hypervisors list and get the uuid and put it in hypervisor_hostname | |
| 19:06:53 | sean-k-mooney | and using host would feel equially odd since that is the host on which the compute service runs so for ironic that is not the same thing | |
| 19:07:15 | sean-k-mooney | so for the newer way i think weee need a hypervisor_uuid filed on server create to use this | |
| 19:07:51 | dansmith | I'm not so concerned about new field vs new behavior for existing field, | |
| 19:08:06 | dansmith | but it seems worthy of a microversion to me either way so we know if we can use it or not | |
| 19:08:25 | sean-k-mooney | dansmith: well with a new field the old filed behavior would not change | |
| 19:08:42 | dansmith | right but new field would mean microversion for sure | |
| 19:09:34 | gmann | yeah, only way to avoid microversion is existing field but that also seems difficult/not right | |
| 19:10:01 | dansmith | well, I was saying I don't even think you can avoid it then, because we won't know when we can or can't use it | |
| 19:10:31 | gmann | yeah.. | |
| 19:10:46 | gmann | now we are back to same issue on how to solve this for new rbac | |
| 19:11:07 | sean-k-mooney | if it was a uuid we would basicaly have to always check if there was a hypervior_hostname with the value or hypverviour_uuid with that value | |
| 19:11:29 | sean-k-mooney | assuming it was one filed | |
| 19:11:51 | sean-k-mooney | gmann: for new rbac i dont understant the problem | |
| 19:12:25 | sean-k-mooney | you just use the new microverion how those that affect things? | |
| 19:12:29 | gmann | sean-k-mooney: with project admin needs to know the hypervisor name to boot server on host | |
| 19:12:54 | sean-k-mooney | right which it cant get today without system_reader | |
| 19:13:06 | gmann | with new rbac and older microverison (than where we fix this), project admin would not be able to boot server on host specify | |
| 19:13:18 | sean-k-mooney | we dont | |
| 19:13:42 | sean-k-mooney | we only support this form the new microverion on | |
| 19:14:14 | sean-k-mooney | and if you want too supprot that for old microverion give them system_reader or create a custom policy role for hypervior list | |
| 19:15:57 | sean-k-mooney | so effectivly i belive we should just pretend that we are allowing proejct admins to spyify a host as a new feature in xena | |
| 19:16:07 | gmann | yeah so for older microversion they would not have choice than updating the policy. which is what issue we have today | |
| 19:16:26 | gmann | and with old rbac default they are able to do | |
| 19:17:16 | gmann | I think we need to think more on this. I am not hurrying it for Xena at the last min. | |
| 19:18:09 | sean-k-mooney | well let take a step back | |
| 19:18:37 | sean-k-mooney | the old polices for hypervior was admin api and the new one is system reader | |
| 19:18:40 | sean-k-mooney | correct | |
| 19:19:26 | sean-k-mooney | so up to now without custom policy you basically need to be an admin or have readonly admin right to list hostname via the hyperviors api | |
| 19:20:37 | sean-k-mooney | so even thoght project_admins could spefify a host https://github.com/openstack/nova/blob/master/nova/policies/servers.py#L177-L196 | |
| 19:21:00 | sean-k-mooney | in pratice they did not know the name unless an admin told them | |
| 19:21:06 | sean-k-mooney | so in practice they could not use this capablity | |
| 19:21:58 | sean-k-mooney | and the same is true of the non az way https://github.com/openstack/nova/blob/master/nova/policies/servers.py#L177-L225 | |
| 19:22:37 | gmann | sean-k-mooney: legacy project_admins can list hypervisor and specify host | |
| 19:22:53 | sean-k-mooney | gmann: there is no such thing a sa legacy project admin | |
| 19:22:56 | gmann | legacy admin | |
| 19:23:04 | sean-k-mooney | they are a fully admin | |
| 19:23:22 | gmann | yeah the old admin can do both operation | |
| 19:23:30 | sean-k-mooney | right | |
| 19:24:03 | sean-k-mooney | so i dont see why we have to try and support this before xena | |
| 19:24:23 | sean-k-mooney | we may have typed PROJECT_ADMIN on those policies | |
| 19:24:40 | sean-k-mooney | but in reality form an PROJECT_ADMIN point of view they could not use them | |
| 19:24:42 | gmann | PROJECT_ADMIN is new rbac policy | |
| 19:25:04 | sean-k-mooney | yes i know | |
| 19:25:29 | gmann | if we think with old admin way then they were allowed to list hypervisor and boot server on that. but with new rbac whatever admin system or project could not do | |
| 19:25:45 | sean-k-mooney | correct | |
| 19:25:55 | sean-k-mooney | althgouh system admin woudl fail for other reason | |
| 19:26:09 | sean-k-mooney | namely becaue it does not have a project uuid | |
| 19:27:18 | sean-k-mooney | so what im proposing is se simple document to use requested_destination with a uuid you need a new microverion and add a new hypervior_uuid filed to server create | |
| 19:27:57 | sean-k-mooney | in addion to that we can allow listing the hyperviors uuid via os-hypervior with project admin | |
| 19:28:51 | sean-k-mooney | that is consitent with our microverion gudieline as we are adding a new feautre to the api. booting with a hypervior uuid as a target host | |
| 19:28:57 | gmann | yeah we can do that always if we want to leave old microversion unsolved. but as discussed in xena PTG or since starting , first we are trying "how we can solve this problem without microversion" | |
| 19:29:00 | sean-k-mooney | and it enable the use case with the new rbac | |
| 19:29:28 | sean-k-mooney | gmann: right my anaser to "how we can solve this problem without microversion" is we should not | |
| 19:30:06 | sean-k-mooney | unless the resoltion is dont use RBAC with the old microverions | |
| 19:33:13 | gmann | one way is going back and allow hypervisor name to list for project-admin. but again it violate our new rbac goal | |
| 19:35:22 | melwitt | don't we already show real hypervisor hostname vs obfuscated one in the same field depending on whether admin or non today? how is allowing uuid as well any different? | |
| 19:35:46 | melwitt | that is, I don't see the problem with showing a uuid there without a microversion | |
| 19:36:03 | opendevreview | Merged openstack/nova stable/ussuri: guestfs: With libguestfs >= v1.41.1 decode returned bytes to string https://review.opendev.org/c/openstack/nova/+/787902 | |
| 19:40:08 | sean-k-mooney | melwitt: no i dont think we do | |
| 19:40:34 | mnaser | i know i'm not supposed to be mucking around with this, but besides request_specs in nova_api and instances.availiabiltiy_zone in nova.. is there anywhere else that leaves a reference to the az that an instance lives in? | |
| 19:41:16 | mnaser | i'm doing some very bad(tm) things and updating az column in instances worked for some instances but did not for some other ones, the api still reports the old az | |
| 19:41:23 | melwitt | sean-k-mooney: oh, you're right. there is a hostId field | |
| 19:41:34 | gmann | melwitt: showing uuid is fine but specifying that uuid in POST /servers leads to interop issue | |
| 19:42:08 | sean-k-mooney | yes we have hostId for normal users | |
| 19:42:24 | sean-k-mooney | and then OS-EXT-SRV-ATTR:hypervisor_hostname and OS-EXT-SRV-ATTR:host | |
| 19:42:26 | sean-k-mooney | for admins | |
| 19:42:29 | gmann | POST /servers which accept hostname today and start accepting host uuid is soemthing need microversion | |
| 19:43:27 | sean-k-mooney | mnaser: its in neutron and cinder also | |
| 19:43:38 | melwitt | oh, sorry, the details of this must have fallen out of my brain | |