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

Bringing ContainerSource back #2824

Merged
merged 18 commits into from
Mar 26, 2020
Merged

Conversation

nachocano
Copy link
Contributor

@nachocano nachocano commented Mar 24, 2020

Fixes #2755

Proposed Changes

  • 🎁Bringing back ContainerSource in the new sources.knative.dev API group and as v1alpha2.
  • 🧽Removed old deprecated fields and just using spec.template. Updated types to be a valid duckv1.Source. Updated validation, defaults, reconciler to use genReconciler, and some other cleanups.
  • Implemented it using SinkBindings as suggested by @n3wscott and @mattmoor
  • For more context, see Bring back ContainerSource? #2739

Release Note

ContainerSource is available in a new API group `sources.knative.dev` and as part of `v1alpha2` version. Its deprecated fields have been removed. You should use `spec.template` to configure it. Please look at the updated docs in knative.dev to see examples of how to use it. If you want/need more advanced functionality, you should resort to SinkBinding (also in the docs).
Action Required: you should migrate your ContainerSources to this new version, and delete the old CRD called `containersources.sources.eventing.knative.dev` with `kubectl delete crds containersources.sources.eventing.knative.dev`.

Docs

knative/docs#2332

/cc @lionelvillard @grantr @vaikas @n3wscott

@googlebot googlebot added the cla: yes Indicates the PR's author has signed the CLA. label Mar 24, 2020
@knative-prow-robot knative-prow-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Mar 24, 2020
@knative-prow-robot knative-prow-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. area/test-and-release Test infrastructure, tests or release labels Mar 24, 2020
Copy link
Member

@mattmoor mattmoor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Produced via:
gofmt -s -w $(find -path './vendor' -prune -o -path './third_party' -prune -o -type f -name '*.go' -print)

@nachocano
Copy link
Contributor Author

/retest

Copy link
Member

@mattmoor mattmoor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Produced via:
gofmt -s -w $(find -path './vendor' -prune -o -path './third_party' -prune -o -type f -name '*.go' -print)

@nachocano
Copy link
Contributor Author

nachocano commented Mar 24, 2020 via email

@n3wscott
Copy link
Contributor

I think we need to have agreement before this can just land.

/approve cancel

@nachocano
Copy link
Contributor Author

I think we need to have agreement before this can just land.

/approve cancel

@n3wscott the agreement was documented here: #2739.
2/3 eventing WG leads voted for this, plus plenty of other members in the community. Let's not start these discussions all over again. Is a waste of time for everybody. We have better things to do.
I know you disagree, but I'd really expect you to commit, so that we can move forward.
If you worry about not having enough contributors to maintain it (IIRC that was the last argument against adding this back), then don't, I'm willing to do so. And I think I've already shown that I do contribute #1, #2.

BTW nothing is set in stone, if we later on decide this is useless, we can certainly revisit.

/fyi @grantr @lionelvillard @vaikas as WG leads

@n3wscott
Copy link
Contributor

at the very least this needs to use sink binding internally.

@mattmoor
Copy link
Member

nit: can we call it DeploymentSource to better align with the syntactic sugar it represents?

fwiw I think Serving's Service resource is useful precedent for a new abstraction to simplify the resource model 🤷‍♂

@n3wscott
Copy link
Contributor

I think we need to have agreement before this can just land.
/approve cancel

@n3wscott the agreement was documented here: #2739.
2/3 eventing WG leads voted for this, plus plenty of other members in the community. Let's not start these discussions all over again. Is a waste of time for everybody. We have better things to do.
I know you disagree, but I'd really expect you to commit, so that we can move forward.
If you worry about not having enough contributors to maintain it (IIRC that was the last argument against adding this back), then don't, I'm willing to do so. And I think I've already shown that I do contribute #1, #2.

BTW nothing is set in stone, if we later on decide this is useless, we can certainly revisit.

/fyi @grantr @lionelvillard @vaikas as WG leads

Because this is a source, it should go to the sources WG. That is the point of having a Sources WG.

@vaikas
Copy link
Contributor

vaikas commented Mar 24, 2020

Getting the container source back is fine with me as clearly there's a need from the users/developers to make it super trivial to create sources. However, before we move too much forward with some of the proposed changes that I saw on the issue, I think we need a further discussion about some of the proposed features. For example imho DLQ does not belong imho to the source, just like fanout doesn't belong there and so forth. There should be a clean / clear separation of concerns and baking more things into what a source is seems wrong to me. We should discuss that in the context of Sources WG.

@nachocano
Copy link
Contributor Author

at the very least this needs to use sink binding internally.

Maybe that can be done in a follow up. I'm not entirely convinced that is the right approach, it will create an IMO unnecessary extra object.

@nachocano
Copy link
Contributor Author

nit: can we call it DeploymentSource to better align with the syntactic sugar it represents?

The implementation might change in the near future, so we'd rather not couple it with Deployments. ContainerSource is a (widely) popular name already, I think we should keep it.

fwiw I think Serving's Service resource is useful precedent for a new abstraction to simplify the resource model 🤷‍♂

@mattmoor just to be sure, you consider Serving's Service is a precedent in favor of having this ContainerSource abstraction?

@nachocano
Copy link
Contributor Author

Getting the container source back is fine with me as clearly there's a need from the users/developers to make it super trivial to create sources. However, before we move too much forward with some of the proposed changes that I saw on the issue, I think we need a further discussion about some of the proposed features. For example imho DLQ does not belong imho to the source, just like fanout doesn't belong there and so forth. There should be a clean / clear separation of concerns and baking more things into what a source is seems wrong to me. We should discuss that in the context of Sources WG.

Yes, I wasn't planning on adding any of those extra bits yet, they are not included in this PR at all.
It's a fair and valid point that should require a more thorough discussion in the Sources WG.

@n3wscott
Copy link
Contributor

at the very least this needs to use sink binding internally.

Maybe that can be done in a follow up. I'm not entirely convinced that is the right approach, it will create an IMO unnecessary extra object.

If you do not use SinkBinding, ContainerSource is duplicating all the logic of SinkBinding. So that is not ideal.

@nachocano
Copy link
Contributor Author

at the very least this needs to use sink binding internally.

Maybe that can be done in a follow up. I'm not entirely convinced that is the right approach, it will create an IMO unnecessary extra object.

If you do not use SinkBinding, ContainerSource is duplicating all the logic of SinkBinding. So that is not ideal.

hmm, I think we are just doing the same for ceOverrides serialization and setting the env variables in the containers. That can be easily moved out to some util. I wonder if the ceOverrides marshalling thing is actually better to have it in pkg so that different sources can easily leverage it?

@nachocano
Copy link
Contributor Author

Implemented it using SinkBinding as suggested by folks. Updated UTs, etc...

/assign @n3wscott

@@ -86,6 +86,7 @@ var ourTypes = map[schema.GroupVersionKind]resourcesemantics.GenericCRD{
sourcesv1alpha1.SchemeGroupVersion.WithKind("ApiServerSource"): &sourcesv1alpha1.ApiServerSource{},
sourcesv1alpha1.SchemeGroupVersion.WithKind("PingSource"): &sourcesv1alpha1.PingSource{},
sourcesv1alpha1.SchemeGroupVersion.WithKind("SinkBinding"): &sourcesv1alpha1.SinkBinding{},
sourcesv1alpha1.SchemeGroupVersion.WithKind("ContainerSource"): &sourcesv1alpha1.ContainerSource{},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

v1alpha2

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good, will do

type: date
JSONPath: .metadata.creationTimestamp
versions:
- name: v1alpha1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

v1alpha2

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ack! will do

Copy link
Contributor

@n3wscott n3wscott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets move it to v1alpha2 and I will approve

@nachocano
Copy link
Contributor Author

lets move it to v1alpha2 and I will approve

Perfect, will do!

Copy link
Member

@mattmoor mattmoor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Produced via:
gofmt -s -w $(find -path './vendor' -prune -o -path './third_party' -prune -o -type f -name '*.go' -print)

@knative-metrics-robot
Copy link

The following is the coverage report on the affected files.
Say /test pull-knative-eventing-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/sources/v1alpha2/container_defaults.go Do not exist 100.0%
pkg/apis/sources/v1alpha2/container_lifecycle.go Do not exist 83.3%
pkg/apis/sources/v1alpha2/container_types.go Do not exist 0.0%
pkg/apis/sources/v1alpha2/container_validation.go Do not exist 88.2%
pkg/reconciler/containersource/containersource.go Do not exist 74.1%
pkg/reconciler/containersource/controller.go Do not exist 100.0%
pkg/reconciler/containersource/resources/deployment.go Do not exist 100.0%
pkg/reconciler/containersource/resources/labels.go Do not exist 100.0%
pkg/reconciler/containersource/resources/names.go Do not exist 100.0%
pkg/reconciler/containersource/resources/sinkbinding.go Do not exist 100.0%

@knative-prow-robot
Copy link
Contributor

knative-prow-robot commented Mar 26, 2020

@nachocano: The following test failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
pull-knative-eventing-go-coverage 73fdde6 link /test pull-knative-eventing-go-coverage

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

@n3wscott
Copy link
Contributor

/lgtm
/approve

🙃

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Mar 26, 2020
@knative-prow-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: n3wscott, nachocano

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@nachocano
Copy link
Contributor Author

/lgtm
/approve

Highly appreciated @n3wscott !!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/test-and-release Test infrastructure, tests or release cla: yes Indicates the PR's author has signed the CLA. lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add ContainerSource to core eventing
7 participants