Hello all,

Recently I've raised an issue about user comfort when destroying stratis fs [1] which got rejected with idempotency as reason. I do not agree with this, let me explain why.

First let's start with the user comfort itself. It seems to be good practice to fail on item removal if the item user is trying to remove is not present. This can have many reasons varying from "item is already removed" to "user made typo in item name". Here are some examples:
device mapper:
# dmsetup table
test: 0 102400 linear 7:0 102400
# dmsetup remove test
# echo $?
0
# dmsetup remove test
device-mapper: remove ioctl on test  failed: No such device or address
Command failed.
# echo $?
1
LVM:
# pvremove /dev/loop0
  Labels on physical volume "/dev/loop0" successfully wiped.
# echo $?
0
# pvremove /dev/loop0
  No PV found on device /dev/loop0.
# echo $?
5

On the other hand Stratis CLI does not work this way:
# stratis pool create test /dev/loop0
# stratis fs create test test_fs
# echo $?
0
# stratis fs create test test_fs
Execution failure caused by:
ALREADY EXISTS: test_fs
# echo $?
1
# stratis fs destroy test test_fs
# echo $?
0
# stratis fs destroy test test_fs
# echo $?
0

Now let's get to idempotency itself. Given the response in [1], command is idempotent only when the output is teh same. Based on the example above it seems that stratis create is actually not idempotent, as trying to create the same fs again fails. But I'd like to pinpoint the definition and application of idempotency first before settling this. I like the idempotency definition from RFC 7231 [2] (HTTP/1.1), mainly the end of the paragraph: "repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ."
Based on this it is actually idempotent to give user different response as long as the effect is the same, eg. item is present at the end of create command (unless something crashed). So even if I run the command again and the item got already created by previous command, the item still present. The user gets different response, but the state of the server is the same, hence idempotency stands. Same applies to any other command including 'stratis fs destroy' - idempotency is not broken as long as the fs is not present at the end of the command. Response to user does not matter to idempotency.

So I think based on examples on what others do (dm, LVM...), 'stratis fs remove' should actually warn user and fail if he tries to remove something that is not there. It does not break idempotency and makes the CLI much nicer to user.