Skip to content
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

Closed
pierDipi opened this issue Apr 3, 2023 · 2 comments · Fixed by #2713
Closed

Eventing TLS: Update Addressable and AddressStatus #2711

pierDipi opened this issue Apr 3, 2023 · 2 comments · Fixed by #2713
Assignees
Labels
area/API good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature

Comments

@pierDipi
Copy link
Member

pierDipi commented Apr 3, 2023

As the Eventing TLS feature track describes we should update Addressable and AddressStatus types as follow:

// Addressable provides a generic mechanism for a custom resource
// definition to indicate a destination for message delivery.
//
// Addressable is the schema for the destination information. This is
// typically stored in the object's `status`, as this information may
// be generated by the controller.
type Addressable struct {
	// Name is the name of the address.
	Name *string `json:"name,omitempty"`

	URL *apis.URL `json:"url,omitempty"`

	// Certification Authority (CA) certificates in PEM format
// according to https://www.rfc-editor.org/rfc/rfc7468.
// +optional
	CACerts *string `json:”CACerts,omitempty”`
}
// AddressStatus shows how we expect folks to embed Addressable in
// their Status field.
type AddressStatus struct {
        // …
        // If addresses is present, address will be ignored by clients.
	Address *Addressable `json:"address,omitempty"`

	// List of addresses for different protocols (HTTP and HTTPS)
	// +optional
	Addresses []Addressable `json:addresses,omitempty”`
}

Additional Info

/good-first-issue
/kind feature
/area API

@knative-prow
Copy link

knative-prow bot commented Apr 3, 2023

@pierDipi:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

As the Eventing TLS feature track describes we should update Addressable and AddressStatus types as follow:

// Addressable provides a generic mechanism for a custom resource
// definition to indicate a destination for message delivery.
//
// Addressable is the schema for the destination information. This is
// typically stored in the object's `status`, as this information may
// be generated by the controller.
type Addressable struct {
  // Name is the name of the address.
  Name *string `json:"name,omitempty"`

  URL *apis.URL `json:"url,omitempty"`

  // Certification Authority (CA) certificates in PEM format
// according to https://www.rfc-editor.org/rfc/rfc7468.
// +optional
  CACerts *string `json:”CACerts,omitempty”`
}
// AddressStatus shows how we expect folks to embed Addressable in
// their Status field.
type AddressStatus struct {
       // …
       // If addresses is present, address will be ignored by clients.
  Address *Addressable `json:"address,omitempty"`

  // List of addresses for different protocols (HTTP and HTTPS)
  // +optional
  Addresses []Addressable `json:addresses,omitempty”`
}

/kind feature

Additional Info

/good-first-issue
/kind feature
/area API

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.

@knative-prow knative-prow bot added good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Apr 3, 2023
@vishal-chdhry
Copy link
Member

/assign

knative-prow bot pushed a commit to knative/eventing that referenced this issue May 4, 2023
…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>
knative-prow bot pushed a commit to knative/eventing that referenced this issue May 8, 2023
)

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/API good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants