Add v1alpha2 API

[danehans]

Please describe the problem you have
#382 is an important breaking API change. Other potential breaking API changes may be needed due to Contour natively supporting Gateway API.

Possible API changes:

• The operator will no longer need to manage the Envoy infra when Contour adds this support. How does this affect the operator API? For example, should GatewayClassRef still exist, or does it need to change?
• Will Contour fully support EnvoyNetworkPublishing? Do any deviations exist?
• Will the removal of gatewayclass/gateway controllers introduce API changes?

[danehans]

v1alpha2 should be based on main after a release is cut, i.e. v1.17.0. Copy v1alpha1 to v1alpha2, preface deprecated fields with deprecated, make API changes, add any new fields, generate CRDs, update imports/examples to use new API version, etc..

[danehans]

Will Contour fully support EnvoyNetworkPublishing? Do any deviations exist?

Since the GatewayClass is being managed similarly to IngressClass, I suggest the API change look something like:

// ContourSpec defines the desired state of Contour.
type ContourSpec struct {
...
	// GatewayClassController is the controller string used by Contour to manage gatewayclasses.
	// If unset, defaults to "projectcontour.io/contour"
	//
	// For additional GatewayClass details, refer to:
	//   https://gateway-api.sigs.k8s.io/api-types/gatewayclass/
	//
	// +kubebuilder:validation:MinLength=1
	// +kubebuilder:validation:MaxLength=253
	// +kubebuilder:default={"projectcontour.io/contour"}
	// +optional
	GatewayClassController *string `json:"gatewayClassController,omitempty"`
}

[danehans]

#382 details namespace-related API changes. Note: the PR implements the changes to v1alpha1 and should be updated to use v1alpha2 after this issue is resolved.

[danehans]

xref: #322

[danehans]

cc: @nak3 @amdonov @BostjanBozic to make you aware of the plans for an API bump. Feel free to chime in with any feedback for API improvements.

[BostjanBozic]

From my side maybe just a remark that maybe we can get rid of NetworkPublishing level and go straight to Envoy, as there are no other options configurations there anyway. Unless there is something planned for the future?

On side note, should we maybe take this opportunity to upgrade project to Kubebuilder scheme v3 (migration)?

[danehans]

Reopen #386 after this PR is resolved.

[danehans]

From my side maybe just a remark that maybe we can get rid of NetworkPublishing level and go straight to Envoy, as there are no other options configurations there anyway. Unless there is something planned for the future?

@BostjanBozic thanks for the input. The NetworkPublishing API was designed to support the ability to manage Contour network endpoints. This may change due to projectcontour/contour#3545.

On side note, should we maybe take this opportunity to upgrade project to Kubebuilder scheme v3 (migration)?

I agree that the we should consider migrating to kubebuilder v3, but I see that as a separate independent issue.

[danehans]

On side note, should we maybe take this opportunity to upgrade project to Kubebuilder scheme v3 (migration)?

xref: #386

[youngnick]

This can't be done until we push out 1.17, so this is deliverable in the 1.18 timeframe.

[sunjayBhatia]

this is important to do for 1.19: #386 (comment)

will also allow us to be smarter about how we handle multiple contours with gateway api