Add untracked Subvolume and Snapshot metadata APIs in api-status

[anoopcs9]

Following APIs are being added as preview APIs after ceph_pre_* tags are removed with an exception to Pacific where backports are not yet merged.

• FSAdmin.GetMetadata
• FSAdmin.SetMetadata
• FSAdmin.RemoveMetadata
• FSAdmin.ForceRemoveMetadata
• FSAdmin.ListMetadata
• FSAdmin.GetSnapshotMetadata
• FSAdmin.SetSnapshotMetadata
• FSAdmin.RemoveSnapshotMetadata
• FSAdmin.ForceRemoveSnapshotMetadata
• FSAdmin.ListSnapshotMetadata

fixes #752

[phlogistonjohn]

I'm a bit confused. First, why are you removing the ceph_preview tag but not the ceph_pre_quincy tag? Should not the process be: remove pre_* tags and then remove preview tags later?
I also don't think the made stable in version numbers are correct - how can the APIs be stable in a past release?

[anoopcs9]

I'm a bit confused. First, why are you removing the ceph_preview tag but not the ceph_pre_quincy tag? Should not the process be: remove pre_* tags and then remove preview tags later?

Unlike ceph_preview, ceph_pre* tags are just an indication to run CI tests on specific branches(as and when patches get backports). So I thought we should correct/update json(by removing ceph_preview) prior to removing ceph_pre* tags from sources.

I also don't think the made stable in version numbers are correct - how can the APIs be stable in a past release?

These were supposed to be updated in json and markdown format when they were added(in v0.16.0) but we failed to do so. v0.18.0 would have been the right version at which those APIs become stable. But I'm OK with updating it to v0.20.0 since we always say expected_stable_version which can change subject to reasons.

[phlogistonjohn]

I'm a bit confused. First, why are you removing the ceph_preview tag but not the ceph_pre_quincy tag? Should not the process be: remove pre_* tags and then remove preview tags later?

Unlike ceph_preview, ceph_pre* tags are just an indication to run CI tests on specific branches(as and when patches get backports). So I thought we should correct/update json(by removing ceph_preview) prior to removing ceph_pre* tags from sources.

I may be mistaken, but I don't think that's quite right. Any unfulfilled tag (unless in an || in the new syntax) is going to skip that file from being built. AFAIU this is why there was no previous instance of these APIs as preview in the json. The pre tag is causing them to be filtered out of the API discovery of "implements" tool.

If we remove the pre tags first. Then "implements" should suddenly find a new API (in the preview) state. Then we have a preview api that works on supported (& released) vrersions of ceph. After that we can then stablize that API through the (new) standard process.

I also don't think the made stable in version numbers are correct - how can the APIs be stable in a past release?

These were supposed to be updated in json and markdown format when they were added(in v0.16.0) but we failed to do so. v0.18.0 would have been the right version at which those APIs become stable. But I'm OK with updating it to v0.20.0 since we always say expected_stable_version which can change subject to reasons.

I think if we follow the process I outlined above everything should "just work" the api is added as preview in the current version. etc.

[phlogistonjohn]

cc: @ansiwen for 2nd opinion on the tags

[ansiwen]

IMHO these tags are almost orthogonal. You guys might get a bit carried away with processes and "rules", so let's take a step back and ask two simple questions:

• Is the exported functionality considered mature, that is, we think it's very unlikely that we would like to change it again? Then let's remove the ceph_preview tag.
• Is the used pre-release feature available in a release version now? Then let's replace the ceph_pre_* tag with negative tags for the releases that didn't receive backports yet.

Of course APIs that are based on pre-release features are more likely to be considered immature for a longer time, but I wouldn't make an automatism out of that. On the other hand, it also doesn't hurt to keep features longer in preview state. So, if we think these APIs are stable, I don't really care if we remove ceph_preview first.

However, I have no idea how the tooling can handle these cases, so that might be a valid practical argument.

[dpulls]

🎉 All dependencies have been resolved !

[anoopcs9]

@phlogistonjohn @ansiwen PR updated considering all responses received so far.

[phlogistonjohn]

LGTM, as you addressed all my concerns from earlier.

Just to be on the up-and-up I'll not set the needed github label on this PR until monday, in case there's any additional discussion warranted.