ZFS state and encryption

[darkpixel]

Description of Issue

The current ZFS module does not appear to "properly" support encryption.

In order to create an encrypted dataset you need to issue a command line:
zfs create -o encryption=on -o keylocation=/dev/shm/mykeyfile -o keyformat=passphrase tank/mydataset

This can currently be handled using a state like:

tank/mydataset:
  zfs.filesystem_present:
    - properties:
        compression: lz4
        encryption: on
        keylocation: /dev/shm/mykeyfile
        keyformat: passphrase

Salt dutifully runs a 'zfs create -o encryption=on ... tank/mydataset``` and the dataset is created perfectly.

The problem comes in on the second run--because parameters like encryption=on are read-only after the dataset is created.

The second run of highstate results in a command being run:
/usr/sbin/zfs set encryption=on tank/mydataset

This throws a return code of 1 and spits out cannot set property for 'tank/isostore': 'encryption' is readonly

This causes the state to fail and dependencies to fail.

One possible solution I can see would be to add a second 'properties' dict called 'create_properties' that would apply only on creation of the dataset--but that would probably be best debated by someone with a more intimate knowledge of salt.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[darkpixel]

Zark off stalebot.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[xeacott]

Thanks for reporting this, and apologies for the horrendously long wait for a response. I recall thinking about this one night too, I must not have updated the ticket. But anyways, it makes sense that command runs, but since the feature itself is missing we're kind of shoehorning ZFS to do this task, and then fails afterwards.

If anyone on @saltstack/team-core has experience with this state, maybe it is easier than I'm thinking. But i'll add a feature request to this ticket.

[darkpixel]

No worries on the timing--there's only ~1,500 other issues open at the moment. I'm sure everyone busy. :)

Looking at the code, it might be as simple as having an array of read only properties, and then only paying attention to them at create-time since they can't be changed. Alternatively, maybe pay just enough attention to warn when a read-only property doesn't match up so someone can manually intervene.

[xeacott]

Agreed! I like the idea of read only properties. Since I added the feature request I'm hopeful it'll get picked up faster. :)