(MODULES-10726) Add support for ashift/autoexpand/failmode to the zpool provider.

[KeithWard]

This PR adds support for setting ashift (linux only), autoexpand, and failmode on zpools,

Both setting them individually, and also as part of creation
ashift (Only valid on linux)
autoexpand
failmode.

[KeithWard]

As far as I can tell ashift appears to be valid on ZoL, but couldn't find any information about it being supported on Solaris? If it turns out ashift is supported there, then it's a trivial change to enable it for other OS.

[GabrielNagy]

Hi @KeithWard,

Thanks for your contribution. I just ran the acceptance test suite on our Solaris platforms and we ran into some issues.
From the looks of it, Solaris 10 and 11 do not support flags for zpool get (neither -o or -H).

Here's some output on how zpool properties are shown on Solaris 10/11:

root@racy-saturation:~# zpool get -H -o autoexpand rpool
bad property list: invalid property '-H'
For more info, run: zpool help get
root@racy-saturation:~# zpool help get
usage:
        get <"all" | property[,...]> <pool> ...
root@racy-saturation:~# zpool get autoexpand rpool
NAME   PROPERTY    VALUE  SOURCE
rpool  autoexpand  off    default

However... Solaris 11.4 comes with a newer version of zfs which does support these flags:

root@smug-nationhood:~# zpool get -H -o value autoexpand rpool
off

To fix this, I'd suggest either executing zpool get <property> <pool>, and parsing the output to get the value of the property, or execute zpool get -H -o value <property> <pool> and fall back to the simpler syntax if the command fails.

Let me know if you need any help with this. Also, it'd be good to have a MODULES ticket opened to track the work on this PR.

[GabrielNagy]

As far as I can tell ashift appears to be valid on ZoL, but couldn't find any information about it being supported on Solaris? If it turns out ashift is supported there, then it's a trivial change to enable it for other OS.

I just did a quick check and the ashift property does not seem to be supported on any of our supported Solaris versions.

[KeithWard]

To fix this, I'd suggest either executing zpool get <property> <pool>, and parsing the output to get the value of the property, or execute zpool get -H -o value <property> <pool> and fall back to the simpler syntax if the command fails.

Let me know if you need any help with this. Also, it'd be good to have a MODULES ticket opened to track the work on this PR.

I'll probably do the former for this, and switch to parsing zpool get <property> <pool> as that's supported by all OS, as and when the EOL for Soalris 10 comes around we can look at switching it.

I'll update the PR with my changes and let you know when i'm done, Thanks.

[KeithWard]

@GabrielNagy Apologies for the delay, I've updated the PR switching it to parsing the output from zpool get prop pool. Please try acceptance against this and let me know.

Thanks.

[KeithWard]

I've raised an explicit ticket in JIRA to reference this PR MODULES-10726 , and updated the title to match.

[KeithWard]

I've squashed squashed my commits down to one for ease of merging

[KeithWard]

OK so aparently me re-requesting review removed the request for a review from puppetlabs/night-s-watch, not sure how to go about re-adding that or if i need to.

[smortex]

My last suggestion was not wise, I'm sorry about this :-(

[GabrielNagy]

This looks good now, and acceptance tests are passing! Thanks for also raising a ticket.

[GabrielNagy]

@KeithWard one last thing, please squash your commits and prepend (MODULES-10726) to the commit title as well. Thanks!

[KeithWard]

@GabrielNagy Thats all done for you. Thanks.