CLI should fill in existing values for parameters not specified on update requests

[wfchandler]

Target component

• CLI
• SDK
• Something else
• Not sure

Overview

Currently commands like instance update require the user to provide all settings for the object being updated. This is inconvenient for users who need to adjust just one setting on a large number of objects, requiring them to separately lookup the details of each item and pass all of them on the command line.

For update commands, the CLI should instead make all of the field arguments optional. For values not passed, it should transparently query the API and send the existing values on the update request.

Implementation details

We'd want to update progenitor's CLI generator to implement this.

Anything else you would like to add?

No response

[ahl]

If we want this kind of functionality, let's look into implementing PATCH endpoints in the API.

[wfchandler]

If we want this kind of functionality, let's look into implementing PATCH endpoints in the API.

I agree PATCH is a good fit here, but the lack of that method in our API seems mostly intentional based on RFD 4. I know in the past there some disagreement on whether to allow partial updates in the context of firewall rules, as well. Would you expect similar push back for things like instance settings?

Thinking about the CLI generator, we wouldn't want both update and update-just-a-bit subcommands. I suppose Progenitor could prefer using PATCH for the update subcommand when the schema contains both PATCH and PUT for a given path.

[ahl]

I agree PATCH is a good fit here, but the lack of that method in our API seems mostly intentional based on RFD 4. I know in the past there some disagreement on whether to allow partial updates in the context of firewall rules, as well. Would you expect similar push back for things like instance settings?

I don't know; we can always reconsider that position from RFD 4.

Thinking about the CLI generator, we wouldn't want both update and update-just-a-bit subcommands.

No?

I suppose Progenitor could prefer using PATCH for the update subcommand when the schema contains both PATCH and PUT for a given path.

I guess we could ignore the PUT operation?