canonical
Support for idempotent operations
Would it be possible to add option-based support to make LXD operations idempotent?
For example, lxc start throws an error if a container is already started, and lxc delete fails
if the target container is already deleted. As a user I don't generally care whether a container was
actually started / deleted; I'm simply trying to get the container into a certain state. The non-idempotency
of the operations means I have to write a lot of repeated if { } else { } style code to handle each case.
It's painful having to wrap each command to make it idempotent, and dropping error-codes etc. requires more boilerplate and worsens error-handling.
I think I responded to a similar question before. The conclusion was that I'd be happy to review a branch which either introduces a different return code in such case (0 = success, 1 = failure, 2 = already in requested state) or a flag to turn the client into such mode (either a global command line argument or entry in config.yml).
You may find implementing this a bit challenging though as most of those errors right now are returned by the API directly and just displayed by the lxc command line tool. That is, the client doesn't necessarily know how to differentiate between an error and something already being in the expected state.
Changing the API behavior itself wouldn't be acceptable, so you'd need to add extra logic on the client side to handle this, making sure not to make the normal case any slower in the process (only query actual state if in idempotent mode).
That is, the client doesn't necessarily know how to differentiate between an error and something already being in the expected state
Now that we have api.StatusError smuggled in the error response from the API client (https://github.com/lxc/lxd/commit/fe43124da0d36df8b12398bef4ded0270a48b34f) it should make it easier to detect specific error types (although we would also need to ensure that the relevant API endpoint was returning differing api.StatusError values for the different scenarios).
Indeed, we don't want to do string matching on things like that but could make better use of some HTTP codes to indicate that something is already in the desired state.