Earlier  
Posted Nick Remark
#openstack-nova - 2022-05-19
09:39:37 gibi do you mean the CLI issue?
09:40:39 Uggla gibi, yes I introduced a param unpin-az to avoid issues with --availability-zone None --> None treated as a string "None".
09:41:50 gibi I assume if we come up with an API semantic that is accepted then will be able to map that to a meaningful CLI some way
09:42:09 Uggla gibi, so client as 3 param --availability-zone, --host, --unpin-az --> API only 2 --availability-zone and host.
09:42:15 gibi and in the CLI we can have extra params like unpin-az if we need it
09:42:26 gibi yep, CLI is easy :D
09:43:14 Uggla gibi, yes but it could be tricky without the mutually exclusive stuff.
09:43:57 Uggla gibi, ex on the cli user could request --availability-zone nova --unpin-az --> with is not possible.
09:44:13 gibi yepp, that we can catch that on the client side
09:44:14 Uggla s/with/which/
09:44:37 gibi --availability-zone and --unpin-az is mutually exlisive on the client side
09:45:10 Uggla gibi, today all params are mutually exclusive. So no pb.
09:46:24 Uggla gibi, and this is the case on the CLI and API.
09:48:06 Uggla gibi, btw so we ended up to not support pin of an az via unshelve ?
09:49:18 gibi that is how I read bauzas above
09:50:24 Uggla gibi, to be honest it is unclear to me. :)
09:51:22 gibi but I think dansmith had other opinion
09:51:30 gibi "I agree, it's very confusing to sometimes provide an AZ and pin and other times not. That seems like something we should avoid."
09:52:16 Uggla gibi, should we try to put that point to today meeting agenda ?
09:53:00 gibi if you can ask the proper questions, then yes we can try
09:54:35 opendevreview Brin Zhang proposed openstack/nova master: Replace os-simple-tenant-usage with os-simple-project-usage https://review.opendev.org/c/openstack/nova/+/842476
10:10:02 Uggla gibi, I put the question in the agenda. If you want to have look.
10:14:40 opendevreview John Garbutt proposed openstack/nova master: Ironic: retry when node not available https://review.opendev.org/c/openstack/nova/+/842478
10:23:16 gibi bauzas: Uggla: left a comment to the unshelve spec pointing to an extended table in the etherpad
10:48:02 sean-k-mooney gibi: looks like the resize patch was hit by infra issue again
10:48:21 sean-k-mooney im seeing some mysql failures
10:56:24 gibi something is going on I saw mysql issues on other tempest patches this week
10:58:28 sean-k-mooney gibi: i think dan would prefer if the value provided for the az paramater is unconditionally used to update the request spec
10:58:45 sean-k-mooney so if its not provide we dont update
10:58:46 gibi yes I think so
10:59:02 sean-k-mooney if you provide a sentenal proably {} we woudl set it to python None
10:59:14 sean-k-mooney any string value jsut gets set in the request spec
10:59:33 sean-k-mooney actully we could use null
11:00:04 sean-k-mooney unqutated as in the json value null for python None that is the write sentenial
11:00:43 sean-k-mooney im ok with taht as it provides a way to pin and unpine and its simple to reason about
11:01:07 sean-k-mooney that just meas we get rid of the idea of az and host being mutally exclucive
11:02:07 gibi sean-k-mooney: have you checked the new table in https://etherpad.opendev.org/p/unshelve-to-host#L102 ? I think this is now in sync with what you wrote and what Dan suggested
11:02:15 sean-k-mooney so az unset means use current requstspec value, az=null means update to python None az="any string" means update to that stirng
11:02:42 sean-k-mooney i have it open but have not read it yet was reading the scrollback here
11:03:21 gibi sean-k-mooney: yepp
11:03:33 sean-k-mooney so the only delta is im being explict about types
11:03:50 sean-k-mooney so we are not reserving the string None to by python None
11:04:09 sean-k-mooney we are using the json value null
11:04:24 gibi also the previous proposal did not pin when no AZ (boot) -> AZ (unshelve) was requested
11:04:34 gibi but the new one pins
11:04:39 gibi as per dansmith's point
11:05:38 sean-k-mooney why is no unpinning allow if the host is requested
11:06:11 sean-k-mooney would it not be simplet to jsut entirly decoule the two paramters
11:06:47 gibi sean-k-mooney: do you mean L182?
11:06:50 gibi L128
11:06:57 sean-k-mooney yes
11:07:24 gibi I think it can lead to contradiction
11:07:40 sean-k-mooney i dont think so
11:07:41 gibi no AZ host1 -> pin to the AZ of host1
11:08:03 gibi but AZ=None host1 -> not pin due to AZ=None or pin due to host1?
11:08:20 sean-k-mooney no your miss understanding what i was suggesting
11:08:46 sean-k-mooney i was suggesting there is no implict change to az by passign host
11:08:58 sean-k-mooney so if the host is in a differnt az it will fail
11:09:23 sean-k-mooney if you dont care about the az but just want the host then
11:09:32 sean-k-mooney az=null host=host-1
11:09:48 gibi so you would change both L127 and 128 but keep L130?
11:09:56 kashyap Zuul blessed this, can anyone just put this through: https://review.opendev.org/c/openstack/nova/+/838926 (libvirt: Add a workaround to skip compareCPU() on destination)
11:10:29 sean-k-mooney gibi: yes i think so
11:10:42 sean-k-mooney gibi: if the aim is to simplfy i think we shoudl remove all the magic
11:11:08 sean-k-mooney so there is no implict updates of the az
11:11:20 gibi the question is then what happens today if the instance is booted with --availability-zone :host1 (so no AZ but host provided)
11:11:39 gibi do we pin today to the AZ of host1? if not then I agree with you
11:11:41 sean-k-mooney gibi: i dont think that si vaild
11:11:54 gibi let me try
11:11:56 sean-k-mooney i think to use the host via the az an az is required
11:19:36 opendevreview Stephen Finucane proposed openstack/nova master: neutron: Unbind remaining ports after PortNotFound https://review.opendev.org/c/openstack/nova/+/842528
11:20:12 opendevreview Stephen Finucane proposed openstack/nova master: neutron: Unbind remaining ports after PortNotFound https://review.opendev.org/c/openstack/nova/+/842528
11:20:44 gibi sean-k-mooney: "--availability-zone :gibi-devstack-aio" is allowed and it forces the host
11:20:59 sean-k-mooney that is not documented anywhere that im aware of
11:21:03 sean-k-mooney i would have filed a bug for that
11:21:16 gibi but does not set the AZ in the request spec
11:21:37 sean-k-mooney so your saying this feature is alreay supported
11:21:56 sean-k-mooney well we dont allow host for unshleve in the az
11:21:56 gibi we can force the host without pinning to the AZ of the host
11:22:10 sean-k-mooney gibi: well you can force and pin too
11:22:15 sean-k-mooney by passing the correct az
11:22:15 gibi yepp
11:22:19 stephenfin sean-k-mooney: gibi: That's a dead simple nova/neutron patch for whenever you've time ^
11:22:36 gibi stephenfin: ack
11:22:38 sean-k-mooney ack
11:23:20 gibi sean-k-mooney: so based on this I think it is OK to decouple the host from AZ in unshelve too
11:23:21 sean-k-mooney that reminds me we dont currently unbind port when we shelve offload. we really shoudl fix that
11:23:57 sean-k-mooney i summareised my toughs "again" on line 139+
11:24:10 gibi sean-k-mooney: just not blinding unbind but keep the device_id set and check with neutron that this keeps the port reserved
11:24:19 gibi sean-k-mooney: thanks
11:24:23 sean-k-mooney Uggla: rememebr when we said this was a simple non contoversial spec
11:24:56 sean-k-mooney gibi: unbinding never touches the device_id
11:24:59 sean-k-mooney that woudl be a detach
11:25:14 sean-k-mooney unbinding is just resetting the binding:host-id
11:25:41 sean-k-mooney and possible you could clear the port_profile bits
11:25:59 sean-k-mooney but ya we shoudl keep device_id set when unbinding for shelve_offload
11:26:06 sean-k-mooney to keep the port owned by the vm
11:27:32 sean-k-mooney stephenfin: i was going to ask why the continue but i sse wew try and use the port profile later
11:27:41 sean-k-mooney ya this looks correct to me.
11:28:27 stephenfin Yeah. I'm not too sure about that second exception handler (if we can't fetch the port, I'm not sure how much we will fare with updating it) but that's a problem for another day ;-)

Earlier   Later