-
Notifications
You must be signed in to change notification settings - Fork 331
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
Eventing TLS: Update Addressable and AddressStatus #2711
Comments
@pierDipi: Please ensure the request meets the requirements listed here. If this request no longer meets these requirements, the label can be removed In response to this:
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. |
/assign |
…oller (#6881) Signed-off-by: Vishal Choudhary <sendtovishalchoudhary@gmail.com> Fixes #6864 <!-- Please include the 'why' behind your changes if no issue exists --> ## Proposed Changes <!-- Please categorize your changes: - 🎁 Add new feature - 🐛 Fix bug - 🧹 Update or clean up current behavior - 🗑️ Remove feature or internal logic --> - Exposes endpoints based on the Feature Flag - when the feature flag (see #6836) is set to permissive expose - both http and https endpoints in the new status.addresses (see knative/pkg#2711) field - the existing status.address will continue to have the existing http endpoint - when the feature flag (see #6836) is set to strict - expose only the https endpoints in both the new status.addresses and the existing status.address ### Pre-review Checklist <!-- If these boxes are not checked, you will be asked to complete these requirements or explain why they do not apply to your PR. --> - [x] **At least 80% unit test coverage** - [ ] **E2E tests** for any new behavior - [ ] **Docs PR** for any user-facing impact - [ ] **Spec PR** for any new API feature - [ ] **Conformance test** for any change to the spec **Release Note** <!-- :page_facing_up: If this change has user-visible impact, write a release note in the block below. Include the string "action required" if additional action is required of users switching to the new release, for example in case of a breaking change. Write as if you are speaking to users, not other Knative contributors. If this change has no user-visible impact, no release note is needed. --> ```release-note ``` **Docs** <!-- :book: If this change has user-visible impact, link to an issue or PR in https://github.com/knative/docs. --> --------- Signed-off-by: Vishal Choudhary <sendtovishalchoudhary@gmail.com> Signed-off-by: Pierangelo Di Pilato <pierdipi@redhat.com> Co-authored-by: Pierangelo Di Pilato <pierdipi@redhat.com>
) Signed-off-by: Vishal Choudhary <sendtovishalchoudhary@gmail.com> Fixes #6918 <!-- Please include the 'why' behind your changes if no issue exists --> ## Proposed Changes <!-- Please categorize your changes: - 🎁 Add new feature - 🐛 Fix bug - 🧹 Update or clean up current behavior - 🗑️ Remove feature or internal logic --> - Exposes endpoints based on the Feature Flag - when the feature flag (see #6836) is set to permissive expose - both http and https endpoints in the new status.addresses (see knative/pkg#2711) field - the existing status.address will continue to have the existing http endpoint - when the feature flag (see #6836) is set to strict - expose only the https endpoints in both the new status.addresses and the existing status.address ### Pre-review Checklist <!-- If these boxes are not checked, you will be asked to complete these requirements or explain why they do not apply to your PR. --> - [x] **At least 80% unit test coverage** - [ ] **E2E tests** for any new behavior - [ ] **Docs PR** for any user-facing impact - [ ] **Spec PR** for any new API feature - [ ] **Conformance test** for any change to the spec **Release Note** <!-- :page_facing_up: If this change has user-visible impact, write a release note in the block below. Include the string "action required" if additional action is required of users switching to the new release, for example in case of a breaking change. Write as if you are speaking to users, not other Knative contributors. If this change has no user-visible impact, no release note is needed. --> ```release-note ``` **Docs** <!-- :book: If this change has user-visible impact, link to an issue or PR in https://github.com/knative/docs. --> --------- Signed-off-by: Vishal Choudhary <sendtovishalchoudhary@gmail.com>
As the Eventing TLS feature track describes we should update Addressable and AddressStatus types as follow:
Additional Info
/good-first-issue
/kind feature
/area API
The text was updated successfully, but these errors were encountered: