| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-31 | |||
| 12:03:21 | bauzas | gibi: but then, of course the reshape method won't longer work | |
| 12:03:37 | bauzas | gibi: so I should probably remove it too, right? (and the tests) | |
| 12:03:50 | bauzas | but then I think about FFU | |
| 12:04:01 | brinzhang_ | gibi: so form this side, I think they are redundant to add the PUT request body, maybe dansmith have some idea of this. | |
| 12:04:02 | gibi | brinzhang_: let's ask dansmith how serious he want the two json body to match | |
| 12:04:31 | gibi | bauzas: yeah FFU support is a question | |
| 12:06:34 | gibi | bauzas: if we can say that we dont support FFU between Rocky - Ussuri then we can remove the reshape code | |
| 12:07:04 | bauzas | gibi: ... or I would just leave the upgrade support until we agree on that | |
| 12:07:24 | bauzas | gibi: but do we have already some consensus about those kind of questions ? | |
| 12:07:30 | gibi | bauzas: yeah, I think we had the agreement in the past that we keep reshape support for a while | |
| 12:07:40 | bauzas | am I the first folk asking about it ? | |
| 12:07:41 | gibi | bauzas: I think we don't have | |
| 12:07:55 | gibi | or at least I dont rememer | |
| 12:07:55 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: tox: Integrate mypy https://review.opendev.org/676208 | |
| 12:07:56 | bauzas | hum | |
| 12:07:56 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: libvirt: Add typing information https://review.opendev.org/714695 | |
| 12:07:56 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: hardware: Update and correct typing information https://review.opendev.org/714694 | |
| 12:07:57 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: objects: Replace 'cpu_pinning_requested' helper https://review.opendev.org/714697 | |
| 12:07:57 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: tests: Split instance NUMA object tests https://review.opendev.org/714696 | |
| 12:07:58 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: hardware: Remove handling of pre-Train compute nodes https://review.opendev.org/714699 | |
| 12:07:58 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: hardware: Don't consider overhead CPUs for unpinned instances https://review.opendev.org/714698 | |
| 12:07:59 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: hardware: Tweak the 'cpu_realtime_mask' handling slightly https://review.opendev.org/461456 | |
| 12:07:59 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: hardware: Add validation for 'cpu_realtime_mask' https://review.opendev.org/468203 | |
| 12:08:00 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: hardware: Invert order of NUMA topology generation https://review.opendev.org/714701 | |
| 12:08:00 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: hardware: Rework 'get_realtime_constraint' https://review.opendev.org/714700 | |
| 12:08:01 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: Introduce 'pcpuset' field for InstanceNUMACell https://review.opendev.org/714658 | |
| 12:08:01 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: hardware: Remove '_numa_fit_instance_cell_with_pinning' https://review.opendev.org/714703 | |
| 12:08:02 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: libvirt: set host CPUs for the mixed instance https://review.opendev.org/714655 | |
| 12:08:02 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: hardware: Add support for 'hw:cpu_dedicated_mask' extra spec https://review.opendev.org/714706 | |
| 12:08:03 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: metadata: export the vCPU IDs that are pinning on the host CPUs https://review.opendev.org/688936 | |
| 12:08:03 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: Setup 'mixed' instance through 'PCPU' and 'VCPU' resource https://review.opendev.org/713355 | |
| 12:08:04 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: Introduce the 'CPUAllocationPolicy.MIXED' enum https://review.opendev.org/716267 | |
| 12:08:36 | gibi | bauzas: I think it is worth to ask the others how they think about it | |
| 12:08:39 | bauzas | gibi: I think we would need to have some policy about it | |
| 12:08:43 | gibi | yeah | |
| 12:08:52 | bauzas | gibi: because before FFU, it was simple | |
| 12:08:58 | gibi | I can imagine that the default policy is not to remove reshape, eer | |
| 12:09:00 | gibi | ever | |
| 12:09:12 | bauzas | gibi: we were just removing upgrade support after one release | |
| 12:09:24 | bauzas | gibi: but now, I no longer know when we should do it | |
| 12:09:53 | bauzas | gibi: and like you say, some operators could tell us to just support reshapes for a whole | |
| 12:10:01 | bauzas | if so, uhu | |
| 12:13:04 | brinzhang_ | gibi: http://paste.openstack.org/show/791394/ https://review.opendev.org/#/c/693828/22/nova/tests/functional/api_sample_tests/test_volumes.py@305 | |
| 12:13:34 | brinzhang_ | I debuged in http://paste.openstack.org/show/791394/ | |
| 12:16:49 | gibi | brinzhang_: what do you mean? | |
| 12:17:05 | gibi | I simply removed the sub and the test still passed. | |
| 12:17:15 | gibi | so the sub is unused | |
| 12:17:48 | brinzhang_ | gibi: yes, it unused | |
| 12:18:22 | brinzhang_ | gibi: gibi: when the data volume attached to the server, the delete_on_termination will be set to False by default https://opendev.org/openstack/nova/src/branch/master/nova/compute/api.py:_attach_volume() | |
| 12:19:51 | brinzhang_ | gibi: I think that's why the sub['delete_on_termination'] is unused reason | |
| 12:20:29 | brinzhang_ | https://opendev.org/openstack/nova/src/branch/master/nova/compute/api.py#L4505 | |
| 12:22:54 | gibi | brinzhang_: I think the sub is not used as it is not referred in the template update-volume-attachment-delete-flag-req | |
| 12:23:12 | gibi | nova/tests/functional/api_sample_tests/api_samples/os-volumes/v2.85/update-volume-attachment-delete-flag-req.json.tpl | |
| 12:25:20 | brinzhang_ | gibi: you mean we can change ""delete_on_termination": true" to ""delete_on_termination": %(delete_on_termination)s" to resolve this issue? | |
| 12:25:21 | gibi | if you replace the "delete_on_termination": true with "delete_on_termination": "%(delete_on_termination)s" | |
| 12:25:28 | gibi | then the subs will be applied | |
| 12:26:02 | brinzhang_ | yeah, I will try | |
| 12:27:31 | brinzhang_ | gibi: it's true, thanks for you explain ^^ | |
| 12:29:21 | openstackgerrit | Maciej Józefczyk proposed openstack/nova master: [WIP] Respect multiple segments in network https://review.opendev.org/716275 | |
| 12:30:36 | openstackgerrit | Maciej Józefczyk proposed openstack/nova master: [WIP] Respect multiple segments in network https://review.opendev.org/716275 | |
| 12:30:49 | gibi | bauzas: I only found two mentions in the nova doc about FFU | |
| 12:31:24 | bauzas | gibi: I'm writing a ML thread FWIW | |
| 12:31:58 | gibi | doc/source/user/cells.rst: be a gap for other deployment tools. Consider also the FFU case | |
| 12:31:58 | gibi | $ egrep -e "fast forward|FFU" -R doc/ | |
| 12:32:01 | gibi | doc/source/reference/upgrade-checks.rst: fast forward upgrading from Ocata to Rocky, something could have been | |
| 12:32:04 | gibi | bauzas: yeah thanks. | |
| 12:33:33 | gibi | bauzas: one way to remove reshape is to add an upgrade check | |
| 12:35:39 | bauzas | gibi: http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013709.html | |
| 12:37:10 | johnthetubaguy | are we not meant to be able to FFU between *any* release, like gibi said, we are probably just missing an upgrade check | |
| 12:37:58 | bauzas | gibi: mmm, that'd make sense | |
| 12:38:01 | openstackgerrit | Maciej Józefczyk proposed openstack/nova master: [WIP] Respect multiple segments in network https://review.opendev.org/716275 | |
| 12:38:18 | johnthetubaguy | bauzas: can your code be activated without any nova services running? | |
| 12:38:45 | bauzas | gibi: but since reshapes are made automatically when you restart nova-compute in Stein or later, that doesn't need an operator modification | |
| 12:39:03 | bauzas | johnthetubaguy: nope, you need to restart nova-compute, that's the main concern | |
| 12:39:18 | johnthetubaguy | bauzas: in which case we can't remove that code until we have one | |
| 12:39:29 | johnthetubaguy | when we then enforce to be run via an upgrade check | |
| 12:39:36 | gibi | bauzas: we need to make sure that all the compute was started up one during FFU _before_ Ussuri | |
| 12:39:37 | bauzas | and I think we started discussing on this kind of problem, but we haven't had an agreement *yet* | |
| 12:39:37 | johnthetubaguy | then following release we can drop the code | |
| 12:40:16 | gibi | yeah, I don't find any agreement | |
| 12:40:30 | gibi | but the above upgrade check based solution could be a good proposal | |
| 12:40:32 | bauzas | johnthetubaguy: the problem I have with this direction is that usually we write an upgrade check for asking operators to do *something* before upgrading | |
| 12:40:51 | bauzas | johnthetubaguy: in this specific case, what would it be ? restart n-cpu? | |
| 12:40:57 | johnthetubaguy | bauzas: we need to give the operators a way to do something though, we *cannot* requite nova-compute to be started | |
| 12:41:07 | johnthetubaguy | s/requite/require/ | |
| 12:41:20 | johnthetubaguy | at least that was my understanding of the situation | |
| 12:41:41 | bauzas | johnthetubaguy: well, I think we drafted this discussion somewhere sometimes in a PTG and we said it should be a separate module that would be run off nova services | |
| 12:42:04 | bauzas | it, being the reshape codes (with a trailing s, please note) | |
| 12:42:19 | bauzas | but we honestly never designed it | |
| 12:42:26 | sean-k-mooney | johnthetubaguy: requireing n-cpu to be started breaks ffu | |
| 12:42:30 | johnthetubaguy | I was fairly sure it had to be nova-manage, possibly running on each compute node... but yeah I guess we didn't | |
| 12:42:41 | johnthetubaguy | sean-k-mooney: exactly what I am saying, +1 | |
| 12:42:44 | sean-k-mooney | but only if we remove the code before x releases | |
| 12:42:50 | bauzas | and i don't disagree with it | |
| 12:43:13 | sean-k-mooney | e.g. we have to keep the reshape and code for ~3 release if we require you to start the agent | |
| 12:43:15 | bauzas | but given we never thought more about that, we never agreed on *when* and *how* to remove such reshape codes | |
| 12:43:21 | johnthetubaguy | I guess we can't remove the code till we design a way to get rid of it | |
| 12:43:52 | bauzas | agreed | |
| 12:44:03 | johnthetubaguy | cool | |
| 12:44:11 | sean-k-mooney | i think osa and ooo are the only tools that do ffu | |