| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-14 | |||
| 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 | |
| 20:08:32 | sean-k-mooney | mnaser: https://review.opendev.org/c/openstack/nova/+/798145 for https://bugs.launchpad.net/nova/+bug/1934770 | |
| 20:08:44 | sean-k-mooney | mnaser: that is proably of interset to you | |
| 20:09:32 | sean-k-mooney | mnaser: your migrate issue might be similar | |
| 20:10:56 | sean-k-mooney | mnaser: we could consider allowing cross az live/cold migrate explcitly in the api as a new fature at somepoint | |
| 20:11:34 | sean-k-mooney | mnaser: that would allow you to move host between az by live migrating the vms to the new az and then when the host is empty just remove it form one and add it to the other | |
| 20:12:19 | sean-k-mooney | spcifying an az to live/cold migrate woudl have to update the request spec and other db filed with the new az but it could be done | |
| 20:12:27 | sean-k-mooney | althogh not this cycle at this point | |
| 20:12:42 | sean-k-mooney | anyway i need to call it a day | |
| 23:01:53 | opendevreview | Ghanshyam proposed openstack/nova master: DNM: testing https://review.opendev.org/c/openstack/nova/+/794863 | |
| #openstack-nova - 2021-07-15 | |||
| 01:31:28 | opendevreview | Ghanshyam proposed openstack/nova master: DNM: testing https://review.opendev.org/c/openstack/nova/+/794863 | |
| 02:28:45 | opendevreview | Takashi Kajinami proposed openstack/nova master: Fix request path to query a resource provider by uuid https://review.opendev.org/c/openstack/nova/+/800855 | |
| 03:33:17 | zhangtongjian | songwenping__:hi | |
| 03:34:10 | zhangtongjian | songwenping__: hello | |
| 08:06:08 | bauzas | hola folks | |
| 08:09:09 | bauzas | just reading a few things | |
| 08:10:17 | bauzas | mnaser: never ever play with default_schedule_zone=nova ;) see the big warning quote in red on our upstream docs : https://docs.openstack.org/nova/latest/admin/availability-zones.html | |