search

caddyserver / caddy

Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
https://caddyserver.com
Apache License 2.0
58.39k stars 4.04k forks source link

"caddy add-package", "caddy remove-package" could be idempotent #6548

Open gedw99 opened 2 months ago

gedw99 commented 2 months ago

For idempotency, it would be useful if caddy add-package and caddy remove-package could be idempotent.

caddy remove-package, will return "Error: package is not added" if I do it twice.

caddy add-package, will return "Error: package is already added", if I do it twice.

This idempotency is a nice thing in any architecture, when managing a fleet and building a fleet, because you can just store the package list somewhere and then do add-package without worrying if it was done in the past. Treat them like Cows, not delicate kittens :)

what is the best way to handle this ?



```caddy add-package github.com/x/y```, will return "Warn: package github.com/x/y is already added",
mholt commented 2 months ago

I guess that makes sense. Want to submit a PR?

gedw99 commented 2 months ago

Hey @mholt

Can you also comment on https://github.com/caddyserver/caddy/issues/6549, since it's related.

Might have some bearing on this PR. I would like to get this as tight as possible since it is SBOM related.

mholt commented 2 months ago

I think we should just stick to idempotency for now. As mentioned in other issues, build automation with these commands isn't really intended (there are better tools for the job like xcaddy).

gedw99 commented 2 months ago

Got it . Thanks @mholt for steering me .

loren-osborn commented 1 month ago

I wanted to confirm my understanding of this issue before I look deeper into it: My understanding of idempotency is identical behavior, no matter how many times of the operation is performed. My understanding of the use case, however, is that this is primarily for fleet deployment automation. I believe automated tools for fleet deployment primarily depend on exit codes for error detection, while human users primarily rely on error messages.

To clarify the desired behavior I suspect it would still be useful to display human readable error, messages to human users in a non-idempotent fashion (indicating that no change was made), while the exit code should behave idempotently. (Indicating no error deleting something already missing, or adding something already present.)

Is this the desired behavior?

francislavoie commented 1 month ago

Correct @loren-osborn, see https://github.com/caddyserver/caddy/pull/6577#issuecomment-2373357767

loren-osborn commented 1 month ago

Looks like I should spend my time on other tasks if you already have a PR for this issue.

gedw99 commented 1 month ago

agree that error codes are a key element automation.