Prefer org.openzfs for features and properties #10003
Conversation
behlendorf
added
Status: Code Review Needed
Codecov Report
@@ Coverage Diff @@
## master #10003 +/- ##
========================================
+ Coverage 79% 79% +<1%
========================================
Files 386 386
Lines 122431 122431
========================================
+ Hits 97023 97069 +46
+ Misses 25408 25362 -46
Continue to review full report at Codecov.
|
module/zcommon/zfeature_common.c
Outdated
| @@ -381,6 +381,7 @@ zpool_feature_init(void) | |||
| SPA_FEATURE_EXTENSIBLE_DATASET, | |||
| SPA_FEATURE_NONE | |||
| }; | |||
| /* NOTE: Use org.openzfs (without the dash) for new feature GUIDs. */ | |||
There was a problem hiding this comment.
What if instead of annotating each one of these instances of org.zfsonlinux we added a comment above the zpool_feature_init() function which briefly summarized the policy. Here's a first attempt, which could still use a bit more editing.
/*
* Each feature is prefixed by a reversed domain name so that it can be
* uniquely identified. This has allowed companies to independently develop
* features without first reserving the feature name with the OpenZFS
* project (org.delphix, org.datto). Similarly, features developed on one
* platform have used the platform's domain name (org.zfsonlinux, org.illumos).
* Use of the "org.openzfs" domain is recommended for new features which
* are developed by the community. The domain may optionally be used by
* companies or platforms provided they reserve the feature name in
* advance with the OpenZFS project developers.
*/There was a problem hiding this comment.
I spent some time editing on this. In the course of doing so, I came to the conclusion that where/when the features are going to be released is a significant factor. If a company (like Delphix or Datto) wants to be able to release their feature before it lands in OpenZFS, then they should use their own domain name. If they use the OpenZFS domain name, then the on-disk format for that feature is already committed, which ties the hands of the OpenZFS project. It seems that the OpenZFS domain should only be used when the code is going to be initially released through an OpenZFS platform.
The first sentence is from the man page. The rest is from what you wrote, with edits from me.
/*
* Every feature has a GUID of the form com.example:feature_name. The
* reversed DNS name ensures that the feature's GUID is unique across all ZFS
* implementations. This allows companies to independently develop and
* release features. Examples include org.delphix and org.datto. Previously,
* features developed on one implementation have used that implementation's
* domain name (e.g. org.illumos and org.zfsonlinux). Use of the org.openzfs
* domain name is recommended for new features which are developed by the
* OpenZFS community and its platforms. This domain may optionally be used by
* companies developing features for initial release through an OpenZFS
* implementation. Use of the org.openzfs domain requires reserving the
* feature name in advance with the OpenZFS project.
*/
rlaager
force-pushed
the
features-and-properties
branch
from
14fe150 to
cd894e7
Compare
Moving forward, we wish to use org.openzfs (no dash) rather than org.open-zfs or org.zfsonlinux for feature GUIDs and property names. The existing feature GUIDs cannot be changed. Signed-off-by: Richard Laager <rlaager@wiktel.com>
rlaager
force-pushed
the
features-and-properties
branch
from
cd894e7 to
9ac4521
Compare
behlendorf
added
Status: Accepted
Moving forward, we wish to use org.openzfs (no dash) rather than org.open-zfs or org.zfsonlinux for feature GUIDs and property names. The existing feature GUIDs cannot be changed. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Signed-off-by: Richard Laager <rlaager@wiktel.com> Closes openzfs#10003
Motivation and Context
Moving forward, we wish to use
org.openzfs(no dash) rather thanorg.open-zfsororg.zfsonlinuxfor feature GUIDs and property names.We want to avoid the dash for property names, as it is easier to type without the dash. Then, we might as well be consistent in feature names. The website's "main" name is still open-zfs.org and openzfs.org is a redirect, though I have proposed swapping those around. (This situation occurred because openzfs.org was not originally available.)
The ZFS-on-Linux branding is being minimized (though not completely eliminated), so it makes sense to discourage that in these contexts too.
Description
I changed as many existing instances as possible to use the new naming style.
The existing feature GUIDs cannot be changed. I added comments to each in
man/man5/zpool-features.5andmodule/zcommon/zfeature_common.cto try to alert people who are looking at those as a precedent. I'm open to other ideas here.How Has This Been Tested?
I looked at
zpool-features.5withmanto make sure the comments were not visible.Types of changes
Checklist:
Signed-off-by.