-
Notifications
You must be signed in to change notification settings - Fork 558
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Istio API Feature Status using proto annotations #2013
base: master
Are you sure you want to change the base?
Conversation
😊 Welcome @zhlsunshine! This is either your first contribution to the Istio api repo, or it's been You can learn more about the Istio working groups, code of conduct, and contributing guidelines Thanks for contributing! Courtesy of your friendly welcome wagon. |
/test release-notes_api |
Adding @jasonwzm who authored this design. |
@zhlsunshine Thanks for working on this! The feature name should be from the features defined in Istio repos. Do you plan to help implement the proto feature status? If so, we should definitely sync before more work is done this. :) Your contribution is much appreciated! |
@jasonwzm yes, it will be great if I can help on the proto feature status. And I also hope to sync with u @jasonwzm @therealmitchconnors for the next step. ^_^ |
/test build_api |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
@@ -238,7 +239,7 @@ message DestinationRule { | |||
// The value "." is reserved and defines an export to the same namespace that | |||
// the destination rule is declared in. Similarly, the value "*" is reserved and | |||
// defines an export to all namespaces. | |||
repeated string export_to = 4; | |||
repeated string export_to = 4 [(istio.extensions.feature) = {status: "alpha", name: "dr-export-to", id: "traffic.control"}]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is a bit confusing is that you highlight this export_to feature status as alpha and API is also alpha. Do you mean this feature is alpha while the rest of DR is beta?
What is the criteria for adding the istio feature status out of so many fields in DR or any other resource?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: what is a bit confusing is that you highlight this export_to feature status as alpha and API is also alpha. Do you mean this feature is alpha while the rest of DR is beta?
A: In fact, user may pay more attention on the status of these new imported features which may be alpha or beta or experimental, and user also want to know more details about the status and progress for these features, so it should not be key point for the rest which is not highlighted. And @jasonwzm please correct me if I am wrong.
Q: What is the criteria for adding the istio feature status out of so many fields in DR or any other resource?
A: Thanks for this question. In spite of more details for field based on feature status, I think this doc of the criteria still can be a great reference.
// there would be experimental in future. | ||
optional string status = 1; | ||
// show the feature field for specified resource, such as vs-export-to shows the virtualservice's field export_to, | ||
// it can be defined by feature owner. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any approval process needed? or just the normal PR approval?
also, how a feature owner know which ones they should add this status field? (asked below in the example below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: any approval process needed? or just the normal PR approval?
A: I think normal PR approval is enough, because API repo change is a significant thing. Any other idea?
Q: how a feature owner know which ones they should add this status field? (asked below in the example below)
A: I think doc should be a great referenced criteria for feature owner. Beside that, I think proposal doc or PR review would be a right place to discuss the status field.
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
1 similar comment
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
Can we build the tooling that makes these fields useful before merging it into the API? my concern is we will end up like the test frameworks features thing - it adds a significant burden to developers, but has yet to be useful. Before we go add another hurdle to merging a PR, we need to make sure its actually giving us a benefit today |
Hi @howardjohn, I understand your worry about it. However, this PR is the first phase to this API feature status, and I will build a tool to make these fields useful based on the design doc once this PR can be merged. According to the design, there would be a sub-command named |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
Hi @howardjohn new submit to remove proto annotations of name based on comment here , I will fetch the necessary information related to name as |
Hi @howardjohn, after some thinking and discussion, I think it's an agree on dropping the IstioFeature field name, and just 2 fields left as below:
Could you please help to check and approve it? Thanks! ^_^ |
@@ -238,7 +239,7 @@ message DestinationRule { | |||
// The value "." is reserved and defines an export to the same namespace that | |||
// the destination rule is declared in. Similarly, the value "*" is reserved and | |||
// defines an export to all namespaces. | |||
repeated string export_to = 4; | |||
repeated string export_to = 4 [(istio.extensions.feature) = {status: STABLE, id: "traffic.control"}]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what happens when we have a field that is associated with multiple features?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally speaking, multiple features should have the same feature status if they are included in the same field, even if feature status is not the same, it's okay to provide more information in https://github.com/istio/enhancements/blob/master/features.yaml or append additional feature id to field id
as well. Moreover, this situation is uncommon.
optional FeatureStatus status = 1; | ||
// id means the feature id which can be mapped here: https://github.com/istio/enhancements/blob/master/features.yaml | ||
// it should be contained in id section of features under this yaml file. | ||
optional string id = 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given John's comment below I think this would be best suited as repeated string id = 2;
. A repeated item that's empty is essentially optional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jacob-delgado okay, I will add repeated
for field id
. BTW, I think field status
should be necessary to add repeated
as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@zhlsunshine: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. You should bring this to the APAC meeting next week to get the RFC approved.
great idea! |
According to proposal design doc,
FieldOptions
of proto3 can be used to implement this feature label, and I just change the code forExport To
feature as PoC work.Thank you for your time for reviewing this PR! ^_^