> On Mar 27, 2019, at 11:46 AM, Gregor Kopka > <[email protected]> wrote: > > I read the proposal as giving a ZFS admin the QoL to not having to dig > through some feature compatibility matrix each time he wants to create a pool > that should be importable on a set of other machines. > > I'm fine with that general idea. I just see no point (and no benefit) in > hardcoding the values. > > Because even should someone decide to mess up his config file, leading to his > pools having strange feature sets, it will not have any effect at all on > everyone else. > > Not giving the ability to do that (be it to create custom definitions that > make sense for a use case or even remove features from the 'official' > definitions as these have no use - both to the user doing that),without any > technical need for it, makes no sense. > > As no one seems to be interested in working on this (at least from what I > gathered from the video): I am willing to implement it as a python helper > that can be called into from the zfs userland (so zpool can request the > configured list of features for a tag given) and also be used standalone (to > list all tags a specified pool should to be compatible with).
Having built several several appliances, I can assure you that the development time and technical debt of implementing this is not worth the effort. It is much simpler to just pass the right args when you create the pool. Almost all automation frameworks allow this. For humans, encouraging people to edit a file to set the default values then creating the pool is simply too complicated. -- richard ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/Td66d70a086ae5a9e-M29fe800876cc11b9cecc0462 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
