10:08 a.m.
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.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1688262
[2] https://tools.ietf.org/html/rfc7231#section-4.2.2