| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-14 | |||
| 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 | |
| 19:56:06 | sean-k-mooney | and you cna migrate within that | |
| 19:56:26 | mnaser | but in my case, lets imagine it was set to default_schedule_zone=foobar and now we're trying to clean it up to be all inside `nova` | |
| 19:56:41 | sean-k-mooney | mnaser: right that is not supported | |
| 19:56:49 | mnaser | hence the bad things(tm) | |
| 19:56:50 | sean-k-mooney | so your in for pain | |
| 19:56:55 | sean-k-mooney | yep | |
| 19:57:13 | sean-k-mooney | operator do tend to do that form time to time i have noticed | |
| 19:57:15 | mnaser | i expect to be told collect the broken pieces on my own if it breaks :) | |
| 19:57:24 | sean-k-mooney | so maybe there should be a way to do that at some point | |
| 19:57:40 | mnaser | i think its cause operator feel that az's are not very 'heavy' constraints | |
| 19:57:53 | mnaser | and then many years go by and you're like oh wait this isn't straight forward... | |
| 19:58:32 | sean-k-mooney | right AZ are thigns you set up once and never touch as its user facing | |
| 19:58:47 | sean-k-mooney | host aggrartes you can change to your hearts delight as they are not | |
| 19:59:45 | sean-k-mooney | you proably know as well as anyone that openstack AZ are not like aws AZ where each maps to a different datcenter/fault domain | |
| 20:00:04 | sean-k-mooney | but in terem of thinking about changing them you shoudl treat them that way | |
| 20:01:05 | mnaser | yeah but im saying host aggregates seem flexible, az's are hard set | |
| 20:01:16 | mnaser | the mix of both probably gives the impression that one is just as flexible as the other | |
| 20:01:39 | sean-k-mooney | yep and the fact that an az is just a metadata tag on a hsot aggreate probly does not help | |
| 20:02:55 | sean-k-mooney | i never want to write this but i could see someine writing a nova manage command or something that would move a host or vms betwen azs but realticly that will better live out of tree | |
| 20:04:08 | sean-k-mooney | there are far to many choices to make on what to do. do you jsut update the AZ in the db or do you move vm to other node in the az they requested if set and move the other or one that are in a specifed az to the new az | |
| 20:04:53 | mnaser | yeah the combination of possible scenarios is .. a lot | |
| 20:06:01 | sean-k-mooney | and likely will be defferent for each operator/case | |
| 20:06:15 | sean-k-mooney | which is why we have never stdardised a tool to do this in nova | |