fix: sequence updates subscription where possible, instead of recreating it

[Cali0707]

Fixes #7939

Proposed Changes

• Check if the changed fields in a subscription are mutable or immutable, and update or recreate accordingly
• Update unit tests to watch for updates where appropriate

Release Note

sequences now update subscriptions instead of recreating them, where possible

[Cali0707]

/cc @pierDipi @creydr

[codecov]

Codecov Report

Attention: Patch coverage is 42.85714% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 69.55%. Comparing base (abdbf14) to head (924f7a6).
Report is 9 commits behind head on main.

Files	Patch %	Lines
pkg/reconciler/sequence/sequence.go	42.85%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7948      +/-   ##
==========================================
+ Coverage   69.51%   69.55%   +0.03%     
==========================================
  Files         344      344              
  Lines       15994    16055      +61     
==========================================
+ Hits        11119    11167      +48     
- Misses       4189     4199      +10     
- Partials      686      689       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Cali0707]

Once this fix is in, I think implementing the same change for Parallels would be a good first issue

[creydr]

As only .spec.channel is relevant here, we could also compare only these fields (instead of using ignoreArguments). So this might be a bit more self speaking directly 🤷

[Cali0707]

Is spec.channel the only immutable field? I just took this check from the validation webhook to make sure that the change is allowable. Maybe we cold just refactor that into its own function and call it here?

[creydr]

I just had it from the comment Given that spec.channel is immutable.... Also in the SubscriptionSpec this is the only one marked as immutable:

eventing/pkg/apis/messaging/v1/subscription_types.go

Lines 74 to 107 in 746dc52

	type SubscriptionSpec struct {
	// Reference to a channel that will be used to create the subscription
	// You can specify only the following fields of the KReference:
	// - Kind
	// - APIVersion
	// - Name
	// - Namespace
	// The resource pointed by this KReference must meet the
	// contract to the ChannelableSpec duck type. If the resource does not
	// meet this contract it will be reflected in the Subscription's status.
	//
	// This field is immutable. We have no good answer on what happens to
	// the events that are currently in the channel being consumed from
	// and what the semantics there should be. For now, you can always
	// delete the Subscription and recreate it to point to a different
	// channel, giving the user more control over what semantics should
	// be used (drain the channel first, possibly have events dropped,
	// etc.)
	Channel duckv1.KReference `json:"channel"`
	// Subscriber is reference to function for processing events.
	// Events from the Channel will be delivered here and replies are
	// sent to a Destination as specified by the Reply.
	Subscriber *duckv1.Destination `json:"subscriber,omitempty"`
	// Reply specifies (optionally) how to handle events returned from
	// the Subscriber target.
	// +optional
	Reply *duckv1.Destination `json:"reply,omitempty"`
	// Delivery configuration
	// +optional
	Delivery *eventingduckv1.DeliverySpec `json:"delivery,omitempty"`
	}

But aligning with the webhook code (via function call) makes sense to me

[Cali0707]

/cc @creydr

[pierDipi]

/lgtm
/approve

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Cali0707, pierDipi

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:

• OWNERS [Cali0707,pierDipi]

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

[Cali0707]

/cherry-pick release-1.13

[Cali0707]

/cherry-pick release-1.14

[knative-prow-robot]

@Cali0707: new pull request created: #7959

In response to this:

/cherry-pick release-1.13

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-sigs/prow repository.

[knative-prow-robot]

@Cali0707: new pull request created: #7960

In response to this:

/cherry-pick release-1.14

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-sigs/prow repository.