On Tue, 26 Feb 2019 at 06:59, George Wilson <[email protected]> wrote:
> On Mon, Feb 25, 2019 at 10:54 PM Garrett D'Amore <[email protected]> wrote:
>> I suspect having the platform “resolve” which property to use is going to be
>> problematic at the very best. The semantics are platform specific, and to
>> make matters worse, I suspect that even on some platforms, you will find
>> distributions that have imparted their own meanings to these properties.
>> For example, I know of several different distributions built on illumos, and
>> they don’t necessarily handle the properties in a perfectly compatible way.
>> I suspect the situation may actually be worse on Linux, where some
>> distributions are likely to ship with *wildly* different userland and system
>> layers (e.g. systemd vs. legacy rc scripts), and may thus wind up having
>> quite different supported properties.
Though they are platform specific, at least in the illumos case I
believe the "sharenfs" property works on all of the _general purpose_
distributions in a compatible fashion; e.g., at least OpenIndiana,
OmniOS, SmartOS, and I believe Tribblix, all support using this
property in the same way.
>> Probably, the best solution here is for distributions to use their own “user
>> property” for this, and that could apply to operating systems as well. For
>> example, one can imagine “openindiana:sharenfs” as a property. The upshot
>> of that is that these properties might not convey automatically when moving
>> file systems between distributions, but as the semantics (and possibly even
>> syntax) of the contents are assumed not be 100% compatible, probably this is
>> for the very best. It is to be hoped that the NAS vendors building on top
>> of ZFS are already making decent use of user properties (and namespace
>> prefixes) to minimize problems. Certainly that is the case for RackTop.
I think that's almost certainly the best solution for _appliances_
where the vendor is replacing some or all of the mechanism that exists
within the base operating system. In an appliance of this type, I
feel you would simply never use the native "sharenfs", preferring your
own properties with custom behaviour. As you're almost certainly
inserting a control plane of some type between the operator and ZFS,
this seems reasonably easy to enforce.
>> Automatic conversion (or simply using a single shared value) only makes
>> sense when there is broad agreement about the property contents. Absent
>> that, namespace separation, *without* naïve attempts to convert, is probably
>> the next best option.
Indeed. A lack of agreement on the semantics of the "sharenfs"
property, interpreted as it is by each platform's NFS export
machinery, is how we got here.
> The goal of the proposal was not to put that burden on the admins but rather
> try to preserve the native properties while still providing cross platform
> safety. It also seems to me that if vendors and distributions are already
> going down the path of creating incompatibilities in their implementations,
> then they don't care about or haven't thought about cross platform safety.
> And if we can provide automatic conversion of a native property to a
> platform-specific property then we haven't made it worse for them.
>
> I guess the question we should first answer is whether or not we want to keep
> these native properties as native properties. Should they stay or should they
> go? Effectively moving them from native properties mean deprecating them and
> allowing distributions/vendor to move down the user-defined path if they so
> wish.
>From an illumos perspective, at least for the general purpose
distributions, I think we'd like to keep them as they are today from
the perspective of the operator. As you note, there are many extant
scripts, documents, and even muscle memory.
With respect to the proposal, I completely agree with the goals. I
think from an implementation point of view, we could do something a
little different. Rather than add aliases with suffixes, visible
themselves as separate properties, I think we should record a platform
value token when the property is set. For instance, for general
purpose illumos distributions we'd probably use the string "illumos".
Linux distributions could use "Linux". Custom distribution vendors
could choose to override this with some other string, e.g.,
"DelphixOS" or "RackTop". This would be a separate field, and would
only be for the properties where the interpretation is
platform-specific like NFS, SMB, etc.
If one of these properties has an OS token that matches the current
OS, its value would be visible in the usual way through "zfs get",
"zfs list", etc. There may be another value for the same property,
but with a different OS token, which would not be shown. We can add a
new flag to "get", "set", etc, which accepts a platform token string;
the operator would be able to examine and manipulate properties as if
they were running on a different platform without affecting the
current-OS properties.
In a pool with an existing "sharenfs" value with no OS token, we would
(as we do today) continue to return that value for "zfs get" on all
platforms. As soon as you _set_ the value, we would include the
current OS token, at which point the value you set would only be used
on future imports with the same OS token. It's possible that we could
have a two-level approach, with a special OS token like "all", which
would be the property used if no OS-specific property was available --
this "all" token could be retroactively applied to any pre-token
property value, thus providing effective backwards compatibility.
This would effectively mean some of the native properties are no
longer unique purely by name -- rather now by (name, OS). Existing
APIs wouldn't have to change, though, as they would deal in the
composed view of the properties and would implicitly use the current
OS token when setting new property values.
Some examples of the kind of interface I'm imagining:
* Get the current OS value, or the legacy value if no per-OS value:
# zfs get sharenfs tank
NAME PROPERTY VALUE SOURCE
tank sharenfs off default
* Set the current OS value:
# zfs set sharenfs=on tank
# zfs get sharenfs tank
NAME PROPERTY VALUE SOURCE
tank sharenfs on local
* Get the value for a specific OS (-O for OS token override)
# zfs get -O illumos sharenfs tank
NAME PROPERTY VALUE SOURCE
tank sharenfs on local
# zfs get -O Linux sharenfs tank
NAME PROPERTY VALUE SOURCE
tank sharenfs off default
* Get the value for _all_ OSes (-A, new column in -o):
# zfs get -A -o name,property,value,source,os sharenfs tank
NAME PROPERTY VALUE SOURCE OS
tank sharenfs on local illumos
tank sharenfs off default Linux
Cheers.
--
Joshua M. Clulow
Engineer @ Joyent
http://blog.sysmgr.org
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-M8daf77c5f6d771584c325b4e
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
