| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-21 | |||
| 19:34:01 | sean-k-mooney | the neutron port bidning api seems to only work if you interact with it exactly as they expect with no auto recovery if we delete or update things | |
| 19:34:39 | sean-k-mooney | the spec didnt say we were allowed to interact with it in thos other ways so its fair but likely it could be made more robust | |
| 19:34:47 | mriedem | yeah maybe, i'd accept that if i opened a neutron bug and that was the response | |
| 19:35:00 | mriedem | or if mlavalle said that was the case | |
| 19:36:17 | sean-k-mooney | i also would not expect much push back if we specified the set of addtion behavior we intuitivly expect to work and proposed them as an extention | |
| 19:36:37 | mriedem | i don't really care about making those edge cases work, | |
| 19:36:45 | mriedem | i'd just like clarity on the api, since it's not documented in the api-ref | |
| 19:37:05 | mriedem | so maybe that's the neutron bug is just lack of docs | |
| 19:37:32 | sean-k-mooney | right i more or less keep going back to the spec to determin what the expected behavior is | |
| 19:37:47 | sean-k-mooney | my guess is what happening is becasue of https://specs.openstack.org/openstack/neutron-specs/specs/ocata/portbinding_information_for_nova.html#effects-on-existing-apis | |
| 19:38:01 | sean-k-mooney | Update Port with host_id will still re-trigger port binding for a host. The difference will be update_port() will only action on the active binding. | |
| 19:38:11 | mriedem | "The difference will be update_port() will only action on the active binding." | |
| 19:38:12 | mriedem | yeah | |
| 19:38:18 | mriedem | and if the active binding doesn't exist.... | |
| 19:38:29 | mlavalle | mriedem: has the src inactive binding benn deleted when you try to go back? | |
| 19:38:39 | mriedem | mlavalle: no | |
| 19:38:51 | mriedem | well, not as far as i know anyway | |
| 19:39:04 | mriedem | nova isn't explicitly deleting the inactive source host binding | |
| 19:39:09 | sean-k-mooney | the correfct thing to do based on the spec would be to reactivate the souce binding | |
| 19:39:27 | mlavalle | in that case, I think that whn going back, activate tje source binding | |
| 19:39:28 | sean-k-mooney | rather then update it | |
| 19:39:57 | sean-k-mooney | which is what mriedem is doing in https://review.opendev.org/#/c/594139/ correct | |
| 19:40:31 | sean-k-mooney | ya in setup_networks_on_host | |
| 19:41:34 | mriedem | ok yeah that's what i'll try (when i can push up the change) | |
| 19:42:29 | sean-k-mooney | mriedem: that is what you are already doing in https://review.opendev.org/#/c/594139/1/nova/network/neutronv2/api.py@423 | |
| 19:42:39 | sean-k-mooney | instance.host should be the souce host | |
| 19:42:50 | mriedem | sean-k-mooney: that's not a patch in my cross-cell series though | |
| 19:42:57 | sean-k-mooney | oh ok | |
| 19:42:57 | mriedem | it's just a related thing | |
| 19:43:01 | mriedem | and ^ isn't merged anyway | |
| 19:44:34 | sean-k-mooney | i wonder if we call _update_port_binding_for_instance in teh revert flow | |
| 19:45:00 | sean-k-mooney | that might be why https://review.opendev.org/#/c/653506/ was fixign your cross cell issue | |
| 19:45:16 | mriedem | i'm not using https://review.opendev.org/#/c/653506/ in the cross-cell series | |
| 19:45:48 | mriedem | what fixed the cross-cell issue was i needed to activate the dest host bindings before calling migrate_instance_finish https://review.opendev.org/#/c/634832/29/nova/compute/manager.py@4625 | |
| 19:46:09 | mriedem | same as live migration in _post_live_migration | |
| 19:47:23 | sean-k-mooney | actully i missed something the cross cell migration/resize is a cold migration. you choose to use the the multiple port binding flow for cross cell migrations? | |
| 19:48:14 | mriedem | yes | |
| 19:48:24 | sean-k-mooney | ah ok | |
| 19:48:43 | mriedem | because we want to validate early that we can create the port binding on the dest host in the target cell | |
| 19:48:50 | sean-k-mooney | then yes that makes sense that you would have to also add that | |
| 19:49:29 | sean-k-mooney | yep cross cell is proably even more imporant then live migration in that its likely more expensive to try again | |
| 19:55:26 | sean-k-mooney | i think the answer is no but does the super conductor ever call the cell conductor or does it always interact directly with a compute node. that a general cellsv2 question not related to your patches | |
| 19:56:14 | sean-k-mooney | i just realised i dont think i have ever seen code in the conductor call another conductor but i have nerver actully looked either | |
| 20:00:26 | mriedem | it calls the compute | |
| 20:00:48 | sean-k-mooney | and the compute talks to its local cell conductor as needed | |
| 20:13:05 | mriedem | yes | |
| 20:32:30 | sean-k-mooney | mriedem: thanks for the correction/comments on https://review.opendev.org/#/c/643578 ill fix that up tomorrow | |
| 20:33:02 | sean-k-mooney | mriedem: are you ok with the verb 'resurrect' by the way | |
| 20:34:38 | mriedem | from the forum session etherpad there is a note that mordred wants to talk about naming | |
| 20:34:47 | mriedem | https://etherpad.openstack.org/p/DEN-osc-compute-api-gaps | |
| 20:35:01 | openstackgerrit | Eric Fried proposed openstack/nova master: Support old & new versions of svm and avx traits https://review.opendev.org/660515 | |
| 20:35:12 | sean-k-mooney | ill ping him and dean to review once i fix up the last few bits | |
| 20:36:55 | mriedem | dansmith may or may not have strong feelings about how evacuate gets named in osc | |
| 20:37:12 | sean-k-mooney | ill also proably submit a patch to try and swap over the nova live migration job to uses it but im not 100% certin a depens-on will work. i could add it to the requred project which should work but no sure we want to do that in general | |
| 20:37:46 | mriedem | you could test it with a dnm/wip patch until it's released in osc | |
| 20:38:04 | sean-k-mooney | ya i can try that | |
| 20:38:23 | sean-k-mooney | its more i dont think we want to use osc in the gate form mater in general | |
| 20:38:34 | sean-k-mooney | so i can juse a dnm patch that does for testing | |
| 20:38:52 | sean-k-mooney | then drop the source install bit after its released | |
| 20:39:55 | sean-k-mooney | i just dont want to adde the python-openstackclient as a required project in the final version of the gate job patch but as you siad tis fine for a dnm or wip patch | |
| 20:40:31 | mriedem | we already use osc in the gate | |
| 20:40:33 | mriedem | for devstack and grenade | |
| 20:40:52 | mriedem | using the things we want users to use in our testing is a good thing | |
| 20:43:13 | dansmith | mriedem: I dunno.. I definitely want a different name for it, but don't think we should change the API.. having it be named something different in osc seems confusing, especially since it will be a new operation that isn't one of the other three evacuates we have | |
| 20:44:34 | mriedem | new operation? | |
| 20:44:58 | mriedem | it would just be the osc version of https://docs.openstack.org/python-novaclient/latest/cli/nova.html#nova-evacuate | |
| 20:46:17 | sean-k-mooney | mriedem: oh im not saying we shoulding use osc in the gate i was saying we proably want to stick to released versions in the gate rather then adding to reqiured porjects which get translated in to LIBS_FORM_GIT which will install it form master | |
| 20:46:37 | mriedem | sean-k-mooney: yes agree | |
| 20:47:27 | sean-k-mooney | dansmith: my current patch just delegated internall to the nova evacuate command so its the same one that we know and hate | |
| 20:48:13 | sean-k-mooney | dansmith: origially i was calling the osc version "openstack server recreate" but aspiers asked me to change it to "openstack server resurrect" | |
| 20:48:22 | sean-k-mooney | which is what the current patch uses | |
| 20:49:02 | dansmith | sean-k-mooney: right and I'm saying having the command name be something new may not help with the confusion | |
| 20:49:25 | sean-k-mooney | dansmith: that is vaild | |
| 20:49:34 | dansmith | because now it will be "resurrect in osc, which is evacuate in novaclient, which is not host-evacuate or host-evacuate-live" | |
| 20:49:52 | sean-k-mooney | at least for osc we currently dont have the host versions | |
| 20:50:30 | sean-k-mooney | we did talk about that in the fourm session however but bauzas is not a fan of adding them to osc and well i dont care one way or another | |
| 20:50:51 | mriedem | and then i had to yell at both of you, it was great fun | |
| 20:51:14 | sean-k-mooney | :) | |
| 20:52:00 | sean-k-mooney | anyway ill add the docs and a release not and fix all the spelling mistakes tomorrow then let the patch sit for a few days for peopel to think about | |
| 20:57:16 | mriedem | fwiw in osc the sub-command is scoped to the source which might avoid some confusion | |
| 20:57:22 | mriedem | i.e. nova evacuate vs openstack server evacuate | |
| 20:57:39 | mriedem | so that should lessen confusion over what evacuate means per resource | |
| 20:58:00 | mriedem | if we did a whole host evacuate in osc, it would likely be "openstack compute service evacuate" | |
| 20:58:04 | mriedem | since there is a 'compute service' resource | |
| 20:59:08 | sean-k-mooney | is ironic the only case where there is not a 1:1 correspondece between compute services and hypervisors | |
| 20:59:42 | mriedem | yes | |
| 20:59:43 | sean-k-mooney | in the ironic case you would jsut use teh server version | |
| 21:00:00 | sean-k-mooney | ok i was wondering if vmware worked similarly | |
| 21:00:48 | mriedem | it used to back before i think kilo or liberty | |
| 21:00:59 | mriedem | 1 nova-compute service host could manage M vcenters | |
| 21:01:16 | mriedem | much hilarity ensued | |
| 21:01:30 | sean-k-mooney | im sure cdent has fond memories | |
| 21:01:46 | mriedem | this was pre-cdent in nova or vmware | |
| 21:01:59 | mriedem | but coincidentally had dire consequences for evacuate | |
| 21:02:09 | mriedem | i.e. nova deleting all vms in your vcenter | |
| 21:02:15 | mriedem | oops! | |
| 21:02:18 | sean-k-mooney | i can imagine | |
| 21:04:27 | dansmith | mriedem: you mean the scoping actually makes "evacuate" less bad right? | |
| 21:06:02 | sean-k-mooney | the only thing that is unintutive about evacuate (ignoring the host versions) is the fact for ephmereal root volumes you loose the data | |
| 21:07:00 | sean-k-mooney | if evacuated only worked for instacnes with shared storage it actully would be a good name for what it does | |