-
Notifications
You must be signed in to change notification settings - Fork 592
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
Flows v1beta1 #2407
Conversation
[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 |
duckv1.Status `json:",inline"` | ||
|
||
// IngressChannelStatus corresponds to the ingress channel status. | ||
IngressChannelStatus ParallelChannelStatus `json:"ingressChannelStatus"` |
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.
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
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.
I prefer to leave the statuses there. Just like in pods, in there's containerStatuses.
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.
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.
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.
ah right k8s precedent. ok! 👌
ReadyCondition apis.Condition `json:"ready"` | ||
} | ||
|
||
type ParallelSubscriptionStatus struct { |
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.
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"` |
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.
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.
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.
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.
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 the diff between:
Steps: A->B->C->ReplyX
vs
Steps: A->B->C
Reply: ReplyX
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.
is there an extra channel created for the first version?
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.
Where would you specify ReplyX in the first case?
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.
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.
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.
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"` |
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.
This needs a reason
and message
to be useful
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.
Feels similar to issue with Subscription related issue?
#2416
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.
Yeah same issue.
Subscription corev1.ObjectReference `json:"subscription"` | ||
|
||
// ReadyCondition indicates whether the Subscription is ready or not. | ||
ReadyCondition apis.Condition `json:"ready"` |
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.
This needs a reason
and message
to be useful
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.
Feels similar to issue with Subscription related issue?
#2416
Thanks @n3wscott PTAL. |
The following is the coverage report on the affected files.
|
@vaikas: The following test failed, say
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"` |
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.
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.
/lgtm |
Addresses #1869
Proposed Changes
Release Note