| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-31 | |||
| 11:55:24 | kevinz | Thanks | |
| 11:58:46 | gibi | brinzhang_: it is about how we define RESTFull | |
| 11:59:26 | gibi | brinzhang_: if we want that the GET response can be sent back as PUT request then we need that the GET rsp matches with the PUT req | |
| 12:00:11 | gibi | kevinz: ack, I will try | |
| 12:00:36 | kevinz | gibi: Thanks ~ | |
| 12:02:07 | gibi | bauzas: so you think there is a fault in the functional test test_create_servers_with_vgpu ? | |
| 12:02:14 | bauzas | gibi: not really | |
| 12:02:32 | bauzas | gibi: tbc we supported a reshape for Stein | |
| 12:02:40 | bauzas | for Rocky>Stein | |
| 12:02:48 | bauzas | now, we're in Ussuri | |
| 12:02:53 | brinzhang_ | gibi: yeah, as you think it's should keep the same, but we add the tag, device, because swap volume need these parameters, so we should add them in the reqeust body, if we are just update the delete flag for the attachemt, these are invalid, do we need to add these check, such as attachment_id and serverId cannot be changed | |
| 12:03:05 | bauzas | gibi: so I can remove the upgrade support that we created | |
| 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) | |