This works well for setting a new value for root=, rw= and ro=, unless I want to undefine root, rw or ro. For example, I have a requirement to make an export RO for a data migration. That is to change this:
I found that this only works if I am specifying a RO component in the same update. I my use case I am attempting to undef rw and then set ro in sequential calls.
setting rw=’undef’ (or calling nfs-exportfs-modify-rule-2 with no rw component) does not work if read-only=’undef’, even though the API call returns success (which is not good, a bug?).It returns sucess but leave the rw export to all-hosts.
In my example the export does not have ro defined at all.
I also cannot set read-only = ‘all-hosts’ first, I get a reasonable error.
Unable to update nfs_export /vol/nyn197f2v2/cda_test246,
Both 'read-write' and 'read-only' have 'all-hosts' true.
so I can set ro to a temporary value of a host that does not exist, set rw to undef, then set ro to all-hosts in separate calls.
$nfs_export = $nfs_export->set_read_only(['unicorns']); # does not exist
$nfs_export = $nfs_export->set_read_write(); # does this drop clients?
$nfs_export = $nfs_export->set_read_only(['all-hosts']); # all read-only now
I could hide the temp host and all-hosts in my API by substituting on 'undef' and '*'. Or I will have to modify my API to handle these as a single call.
I'm not a fan of returing sucess when a default was applied rather than the instruction in the ReST call.