| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-14 | |||
| 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 | |
| 19:44:07 | sean-k-mooney | mnaser: we set the az in the device_owner field in the neutron port bindings and i think in the cinder volumlue attachments | |
| 19:44:38 | mnaser | sean-k-mooney: right.. in this case those are purposely non-bfv systems so no cinder attachments, now neutron is a good point | |
| 19:44:51 | mnaser | but still.. nova api reports old az still, not sure where to change | |
| 19:45:11 | mnaser | looks for instance_extra and instance_system_metadata | |
| 19:45:35 | sean-k-mooney | ya one of those would be likely but maybe this is nin the api db somewhere | |
| 19:45:54 | sean-k-mooney | we had a list at onepoint | |
| 19:46:47 | mnaser | build_requests has nothing, i already updated nova_api.request_specs.spec | |
| 19:46:51 | mnaser | maybe its cached at this point | |
| 19:48:00 | melwitt | yeah, you might be getting https://github.com/openstack/nova/blob/master/nova/availability_zones.py#L195-L211 | |
| 19:48:41 | mnaser | ahhh so it is cached | |
| 19:49:37 | sean-k-mooney | do you know where we block you removing host form az if it has instnaces | |
| 19:49:59 | sean-k-mooney | the commit that blocked that has a list of all the places where az are stored i think too | |
| 19:50:42 | mnaser | yeah i think in my case it's more of the cache getting the host az to present via the api | |
| 19:51:19 | melwitt | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/services.py#L281-L284 | |
| 19:52:05 | sean-k-mooney | https://github.com/openstack/nova/commit/8e19ef4173906da0b7c761da4de0728a2fd71e24 | |
| 19:52:10 | sean-k-mooney | there we go ^ | |
| 19:52:59 | mnaser | ok so melwitt theory that i'm hitting the case where the az for the compute node != az for instance record, and then its just getting the compute node one | |
| 19:53:34 | melwitt | maybe. I didn't look deep into it | |
| 19:54:01 | sean-k-mooney | mnaser: did you rename the az or move the compute node | |
| 19:54:18 | mnaser | sean-k-mooney: neither.. i am trying to cold migrate to another az :X | |
| 19:54:28 | sean-k-mooney | ah ya that breaks things | |
| 19:54:41 | sean-k-mooney | gibi: and bauzas were working on that recently | |
| 19:54:42 | mnaser | in theory it all works but just the scheduler is not happy | |
| 19:54:44 | sean-k-mooney | one sec | |
| 19:55:14 | sean-k-mooney | mnaser: well if the vm requeted an az in the first place you are nota llowed to migrate to another az | |
| 19:55:23 | mnaser | melwitt: that was it, removing the compute node (that was disabled) out of the host aggregate that was setting the az made to go back to hte db value | |
| 19:55:24 | sean-k-mooney | if it did not yes it can work | |
| 19:55:40 | mnaser | sean-k-mooney: but what if you use default_schedule_zone=nova :) | |
| 19:55:59 | sean-k-mooney | then it will populate that in the request spec | |