Add a unique identifier to each feature

[brian-avery]

This adds a unique, machine readable identifier to features. This can be used, among other things, for linking features to annotations.

@zhlsunshine @therealmitchconnors PTAL

[brian-avery]

Currently, this is just numeric, however, if area is necessary, we could also support an identifier of the format areaID.featureID.

One con with doing this as an object property is I don't believe jsonschema supports verifying uniqueness. I.e. it will verify uniqueness for:

1: {},
2: {},
2: {}, 

But not for:

{
  id: 1,
  name: foo
}, {
 id: 1
 name:bar
}

If we were to change it to be a key id:object, then we could verify using the schema. Without it, we can verify the uniqueness with either an additional check outside of the schema or updating all of the features as mentioned, but there are quite a few PRs in flight that I think we should get reviewed first.

[therealmitchconnors]

Yes, that is the idea.

…

On Tue, Jun 22, 2021, 5:20 PM Brian Avery ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In features.yaml <#88 (comment)>: > @@ -1,299 +1,344 @@ features: - name: "Protocols:HTTP1.1/HTTP2/gRPC/TCP" + id: 1 Sure. I'm fine with that. Will the API maturity annotations look up the feature name? The name is rendered to Istio.io so may be useful for consistency in things like istioctl. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#88 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGIQFQ4UZBRIHL33MJOLRDTUESEJANCNFSM47EFZHLA> .

[zhlsunshine]

Hi @brian-avery , LGTM, I have approved it. Let's see the other's, thank you for your effort on this PR! ^_^

[howardjohn]

We now have two mappings of "features" - the other one being here https://github.com/istio/istio/blob/809c761526f43e05853d1b8f389449a41e7c4d27/pkg/test/framework/features/features.yaml#L36 and doesn't have the same identifiers. it seems like we should have one

[brian-avery]

Yeah, the IDs should probably be the same.

[brian-avery]

Talking to @therealmitchconnors, it sounds like either the other feature IDs will go away, or they will be updated to match the ones here so I think that using the ones here is fine.

There's also not a one-to-one mapping with what's in the other features.yaml and what's here.