You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cleanup: Remove redundant API to change service offering for VMs #6150
As investigated on #3110, PR #5008 had impact on two similar APIs for changing the service offering for a VM, resulting both on resizing the VM's ROOT volume (scaleVirtualMachine and changeServiceForVirtualMachine APIs)
The proposal is to remove the changeServiceForVirtualMachine API, since it is not used in the UI codebase, and the outcome of this API can be obtained by invoking scaleVirtualMachine.
Agree @nvazquez we can remove the API "changeServiceForVirtualMachine" since "scaleVirtualMachine" handles both stopped and running VM to change the offering.
@DaanHoogland@sureshanaparti a quick suggestion is needed here please. Can I proceed with completely removing the API or using deprecate annotations? My only concern with deprecate annotation is I did not see any proper notification on deprecation when the API is used, so users may end up using it even after the deprecation.
@harikrishna-patnala for an API we can only annotate it and not prevent any usage of it. We should wait with removing it untill 5.0 if at all it comes. If scaleVirtualMachine allows for changing the service offering than we can mark changeServiceForVirtualMachine for removal and maybe cripple its functionality. We have more clients than the UI hwoever, so let's not remove it just yet (cmk, terraform, ...).
Agree with removing it. But also agree with @DaanHoogland. Removing it would cause API backwards compatibility and therefore requires a 5.0 (which would be fine for me).
For a 4.X.Y we can deprecate it adding an annotation and also spreading the words via release notes, documentation etc.
One way to deprecate it would be to stop the API getting published via apidocs and use in UI (the API may still continue to be listed via cmk/listApis though), as well as add deprecation note in the Api cmd class description.
Activity
harikrishna-patnala commentedon Jul 7, 2022
Agree @nvazquez we can remove the API "changeServiceForVirtualMachine" since "scaleVirtualMachine" handles both stopped and running VM to change the offering.
@DaanHoogland @sureshanaparti a quick suggestion is needed here please. Can I proceed with completely removing the API or using deprecate annotations? My only concern with deprecate annotation is I did not see any proper notification on deprecation when the API is used, so users may end up using it even after the deprecation.
DaanHoogland commentedon Jul 7, 2022
@harikrishna-patnala for an API we can only annotate it and not prevent any usage of it. We should wait with removing it untill 5.0 if at all it comes. If
scaleVirtualMachineallows for changing the service offering than we can markchangeServiceForVirtualMachinefor removal and maybe cripple its functionality. We have more clients than the UI hwoever, so let's not remove it just yet (cmk, terraform, ...).GabrielBrascher commentedon Jul 7, 2022
Agree with removing it. But also agree with @DaanHoogland. Removing it would cause API backwards compatibility and therefore requires a 5.0 (which would be fine for me).
For a 4.X.Y we can deprecate it adding an annotation and also spreading the words via release notes, documentation etc.
yadvr commentedon Jul 7, 2022
One way to deprecate it would be to stop the API getting published via apidocs and use in UI (the API may still continue to be listed via cmk/listApis though), as well as add deprecation note in the Api cmd class description.
harikrishna-patnala commentedon Jul 7, 2022
Thanks guys, I've raised a PR deprecating the API and updated the description, please review.
yadvr commentedon Jul 9, 2022
Fixed in #6540