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

Flows v1beta1 #2407

Merged
merged 7 commits into from
Jan 24, 2020
Merged

Flows v1beta1 #2407

merged 7 commits into from
Jan 24, 2020

Conversation

vaikas
Copy link
Contributor

@vaikas vaikas commented Jan 18, 2020

Addresses #1869

Proposed Changes

  • Add v1beta1.[sequence,parallel]
  • Types only, nothing else

Release Note

Add v1beta1.[parallel,sequence] types only.

@knative-prow-robot knative-prow-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 18, 2020
@googlebot googlebot added the cla: yes Indicates the PR's author has signed the CLA. label Jan 18, 2020
@knative-prow-robot knative-prow-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Jan 18, 2020
@knative-prow-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vaikas

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

@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 Jan 18, 2020
pkg/apis/flows/v1beta1/parallel_lifecycle.go Outdated Show resolved Hide resolved
pkg/apis/flows/v1beta1/parallel_lifecycle.go Outdated Show resolved Hide resolved
duckv1.Status `json:",inline"`

// IngressChannelStatus corresponds to the ingress channel status.
IngressChannelStatus ParallelChannelStatus `json:"ingressChannelStatus"`
Copy link
Contributor

Choose a reason for hiding this comment

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

I would remove Status and have it just be obj.status.ingressChannel

I might even trim it all the way down to obj.status.ingress

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I prefer to leave the statuses there. Just like in pods, in there's containerStatuses.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Furthermore, status can contain other fields where it's not really conveying Status of another resource, so in this particular case, I think having Status there adds clarity.

Copy link
Contributor

Choose a reason for hiding this comment

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

ah right k8s precedent. ok! 👌

pkg/apis/flows/v1beta1/parallel_types.go Show resolved Hide resolved
pkg/apis/flows/v1beta1/parallel_types.go Show resolved Hide resolved
ReadyCondition apis.Condition `json:"ready"`
}

type ParallelSubscriptionStatus struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

I would combine ParallelChannelStatus and ParallelSubscriptionStatus to be the same object, maybe an array of conditions for subscriptions that related to the channel. But it kinda feels overkill because this data is all in the channel object already and will be propagated to its ready condition.


// Reply is a Reference to where the result of the last Subscriber gets sent to.
// +optional
Reply *duckv1.Destination `json:"reply,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

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

why is this a separate thing? it feels like Reply could be deleted and the operator just adds this to the last step in steps.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, I don't understand this. If I have a sequence, I can either have it terminate or the result of the last sequence step gets wired to send it's output here. Separate from what?
As an example here:
https://knative.dev/docs/eventing/sequence/
You can have a sequence that's "terminal" and sequence with reply.

Copy link
Contributor

Choose a reason for hiding this comment

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

what is the diff between:

Steps: A->B->C->ReplyX

vs

Steps: A->B->C
Reply: ReplyX

Copy link
Contributor

Choose a reason for hiding this comment

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

is there an extra channel created for the first version?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Where would you specify ReplyX in the first case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ah, I think I understand. Why can't the last step just decide? Ideally these would be reusable components so if you wire the last piece into the sequence, seemed more cumbersome to be able to reuse
the A->B->C
and then depending on your application be able to reuse only that part.

Copy link
Member

Choose a reason for hiding this comment

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

Reply is needed so that there is no ambiguity when composing/reusing sequences.

Channel corev1.ObjectReference `json:"channel"`

// ReadyCondition indicates whether the Channel is ready or not.
ReadyCondition apis.Condition `json:"ready"`
Copy link
Contributor

Choose a reason for hiding this comment

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

This needs a reason and message to be useful

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Feels similar to issue with Subscription related issue?
#2416

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah same issue.

Subscription corev1.ObjectReference `json:"subscription"`

// ReadyCondition indicates whether the Subscription is ready or not.
ReadyCondition apis.Condition `json:"ready"`
Copy link
Contributor

Choose a reason for hiding this comment

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

This needs a reason and message to be useful

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Feels similar to issue with Subscription related issue?
#2416

pkg/apis/flows/v1beta1/sequence_types.go Show resolved Hide resolved
@vaikas
Copy link
Contributor Author

vaikas commented Jan 22, 2020

Thanks @n3wscott PTAL.

@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/flows/v1beta1/parallel_defaults.go Do not exist 0.0%
pkg/apis/flows/v1beta1/parallel_lifecycle.go Do not exist 0.0%
pkg/apis/flows/v1beta1/parallel_validation.go Do not exist 0.0%
pkg/apis/flows/v1beta1/register.go Do not exist 0.0%
pkg/apis/flows/v1beta1/sequence_defaults.go Do not exist 100.0%
pkg/apis/flows/v1beta1/sequence_lifecycle.go Do not exist 2.3%
pkg/apis/flows/v1beta1/sequence_validation.go Do not exist 0.0%
pkg/apis/messaging/v1beta1/subscription_lifecycle.go 61.5% 57.1% -4.4

@knative-prow-robot
Copy link
Contributor

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

Test name Commit Details Rerun command
pull-knative-eventing-go-coverage 83ffba1 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.

type SequenceSpec struct {
// Steps is the list of Destinations (processors / functions) that will be called in the order
// provided.
Steps []duckv1.Destination `json:"steps"`
Copy link
Member

Choose a reason for hiding this comment

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

to discuss: #2302. My main argument is one of the reasons for retrying is because a service depends on a backend service that is known to be not very reliable. And one reason to limit retrying is because it might cost real money each time a call is made. That's why I'm arguing for fine-grained delivery control.

@n3wscott
Copy link
Contributor

/lgtm

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 24, 2020
@vaikas vaikas changed the title [WIP] Flows v1beta1 Flows v1beta1 Jan 24, 2020
@knative-prow-robot knative-prow-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 24, 2020
@knative-prow-robot knative-prow-robot merged commit e67a675 into knative:master Jan 24, 2020
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.

7 participants