feat: Exclude experimental guidance from standard channel CRDs

[slayer321]

What type of PR is this?
/kind feature

What this PR does / why we need it:
This PR adds the feature where we can specifiy the start and end tag to the CRDs description which only need to be there in expremental channel CRDs and exclude from standard channel CRDs.

Which issue(s) this PR fixes:

Fixes #2160

Does this PR introduce a user-facing change?:

Excluding experimental guidance in field descriptions from standard CRDs

[k8s-ci-robot]

Hi @slayer321. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[slayer321]

I raised this PR which already have Routability changes, and after raising as there was a merge conflict I found that the Routability changes where drop. So the changes I made is tested with Routability part and can confirm it works.

[robscott]

Thanks @slayer321! This looks good to me, but it would be helpful if you could start by wrapping some examples so we can confirm it works as intended. Here are the main ones I'm thinking of:

• gateway-api/apis/v1beta1/shared_types.go

  Line 28 in 73d727a

  // * Service (Mesh conformance profile, experimental, ClusterIP Services only)

• gateway-api/apis/v1beta1/shared_types.go

  Lines 69 to 77 in 73d727a

  	// ParentRefs from a Route to a Service in the same namespace are "producer"
  	// routes, which apply default routing rules to inbound connections from
  	// any namespace to the Service.
  	//
  	// ParentRefs from a Route to a Service in a different namespace are
  	// "consumer" routes, and these routing rules are only applied to outbound
  	// connections originating from the same namespace as the Route, for which
  	// the intended destination of the connections are a Service targeted as a
  	// ParentRef of the Route.

• gateway-api/apis/v1beta1/shared_types.go

  Lines 130 to 132 in 73d727a

  	// When the parent resource is a Service, this targets a specific port in the
  	// Service spec. When both Port (experimental) and SectionName are specified,
  	// the name and port of the selected port must match both specified values.

• gateway-api/apis/v1beta1/shared_types.go

  Line 170 in 73d727a

  // * Service (Mesh conformance profile, experimental, ClusterIP Services only)

• gateway-api/apis/v1beta1/shared_types.go

  Lines 192 to 200 in 73d727a

  	// ParentRefs from a Route to a Service in the same namespace are "producer"
  	// routes, which apply default routing rules to inbound connections from
  	// any namespace to the Service.
  	//
  	// ParentRefs from a Route to a Service in a different namespace are
  	// "consumer" routes, and these routing rules are only applied to outbound
  	// connections originating from the same namespace as the Route, for which
  	// the intended destination of the connections are a Service targeted as a
  	// ParentRef of the Route.

[robscott]

Maybe we should just copy xml here? (Non-blocking, just an idea)

Suggested change

	startTag := "<experimental:description:start>"
	endTag := "<experimental:description:end>"
	startTag := "<experimental:description>"
	endTag := "</experimental:description>"

[robscott]

Thanks @slayer321! Sorry I lost track of this one!

[robscott]

One tiny nit, probably best to stick with the <gateway:experimental prefix we're using elsewhere.

Suggested change

	//<experimental:description>
	// <gateway:experimental:description>

[robscott]

/ok-to-test

[slayer321]

@robscott I have made the changes can you please take a look.

[robscott]

Thanks @slayer321, Sorry I lost track of this one! Please add a release-note in the PR description above, maybe something like "Excluding experimental guidance in field descriptions from standard CRDs". Once you do that, I believe the PR should merge.

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: robscott, slayer321

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 [robscott]

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