nice, thanks for the PR.

A suggestion: perhaps add an example on how to access the installed deployment into NOTES.txt (https://github.com/helm/helm/blob/main/pkg/chartutil/create.go#L438) ?

(I'm not familiar enough with gateway API to know if this is entirely reasonable; but if so, might be helpful to chart consumers/authors?)

Thanks, and great suggestion. I added some infos to the NOTES.txt, but since configuration in the gateway-api are set in Gateway and some in HTTPRoute it is not super easy to give a perfect example for accessing the app since the chart deployment cant look into the Gateway configuration. But I added the infos for accessing it via the most common way (Host and Path based routing) as well on how to get the relevant information from the Gateway

With HTTPRoute enabled and hosts set in the values the output would look like this:

1. Get the application URL by running these commands:
    export APP_HOSTNAME=example.com
    echo "Visit http://$APP_HOSTNAME/headers to use your application"

    NOTE: Your HTTPRoute depends on the listener configuration of your gateway and your HTTPRoute rules.
    These can be set for path, method, header and query parameters.
    You can check the gateway configuration with 'kubectl get --namespace default gateway/gateway -o yaml'

With HTTPRoute enabled and no hosts set in the values the output would look like this:

1. Get the application URL by running these commands:
    export APP_HOSTNAME=$(kubectl get --namespace default gateway/gateway -o jsonpath="{.spec.listeners[0].hostname}")
    echo "Visit http://$APP_HOSTNAME/headers to use your application"

    NOTE: Your HTTPRoute depends on the listener configuration of your gateway and your HTTPRoute rules.
    These can be set for path, method, header and query parameters.
    You can check the gateway configuration with 'kubectl get --namespace default gateway/gateway -o yaml'

Namespaces and Paths are all tempalted form the values/release namespace

Looking good. Thanks for working on this :)

Thanks for the feedback @sabre1041

1. Let's align the default hostname among Ingress and HTTPRoute so that there is pariety. Yes, you could potentially install both, but in most cases, you would pick one or the other. So set the default hostname of the HTTPRoute to be chart-example.local

Sure will do!

2. Support for v1beta1. While the Gateway API is now GA, most who are currently using it is making use of the beta version. Similar to Ingress, there should be a version check to determine which API Group/Version to apply

I thought so too at first but then the question was raised if it is used that much by people, so I removed it. I can revert that without a problem but you also mentioned user experience. I will make the assumption that the people using v1beta1 are technical enough and on the cutting edge side so they will know to change the api version to v1beta1. And if not and they use v1beta1 functions the deployment will just fail. Let the community/maintainers discuss and decide. I have no real preference here.

3. Overall thoughts: I am hesitant about adding this to the default scaffolded chart. This is mainly from a user experience perspective as we would want the getting started experience to be as smooth as possible. Most users will not have the Gateway API installed and there is a chance that they would face errors when attempting to leverage some of the features that are available in the default scaffolded chart.

I understand that concern. My goal was to make using the GatewayAPI easy because at fist I struggled transforming something usable into helm. To not disturb the user experience the gateway stuff is disabled by default, you have to enable it explicitly and then it should provide a good starting point for your first routes. I see it similar to Ingress and HorizontalPodAutoscaler. A lot of people don't use these and just delete the template but if you need them it is nice to have a good starting point.

Thanks for the feedback @sabre1041

1. Let's align the default hostname among Ingress and HTTPRoute so that there is pariety. Yes, you could potentially install both, but in most cases, you would pick one or the other. So set the default hostname of the HTTPRoute to be chart-example.local

Sure will do!

2. Support for v1beta1. While the Gateway API is now GA, most who are currently using it is making use of the beta version. Similar to Ingress, there should be a version check to determine which API Group/Version to apply

I thought so too at first but then the question was raised if it is used that much by people, so I removed it. I can revert that without a problem but you also mentioned user experience. I will make the assumption that the people using v1beta1 are technical enough and on the cutting edge side so they will know to change the api version to v1beta1. And if not and they use v1beta1 functions the deployment will just fail. Let the community/maintainers discuss and decide. I have no real preference here.

3. Overall thoughts: I am hesitant about adding this to the default scaffolded chart. This is mainly from a user experience perspective as we would want the getting started experience to be as smooth as possible. Most users will not have the Gateway API installed and there is a chance that they would face errors when attempting to leverage some of the features that are available in the default scaffolded chart.

I understand that concern. My goal was to make using the GatewayAPI easy because at fist I struggled transforming something usable into helm. To not disturb the user experience the gateway stuff is disabled by default, you have to enable it explicitly and then it should provide a good starting point for your first routes. I see it similar to Ingress and HorizontalPodAutoscaler. A lot of people don't use these and just delete the template but if you need them it is nice to have a good starting point.

The biggest concern with including an HTTPRoute with the default set of scaffolded resources during Helm chart creation is that unlike Ingress or HorizontalPodAutoscaler, an HTTPRoute is not an included API within the cluster. So, if they attempt to enable the feature as part of the installation of a chart to the cluster, an error will be returned, not as a result of an error within the contents of the chart, but due to component(s) not being available within the cluster. Its all about the user experience.

The Kubernetes folks intend for the gateway api to replace the ingress api though. There is a chicken and the egg problem though. Enough software needs to adopt the ability to use the gateway api before enough clusters deploy it. Clusters are reluctant to deploy it unless software uses it. Software developers are less likely to support it if they don't have a good example of how to do it. Hence this pr's goal to help break the deadlock.

Changed the default HTTPRoute hostname in values cording to chart-example.local as suggested by @sabre1041

Rebased from main

Changed the default HTTPRoute hostname in values cording to chart-example.local as suggested by @sabre1041

Rebased from main

Any thoughts about supporting older versions of the Gateway API pre GA?

Seems like there a no real opinions on that. Also asked in the k8s gateway-api slack channel.

Given that v1.1 is already released I don`t see the real need to support beta versions as I dont think they will be needed once it hits a higher adoption rate.

There was a concern raised (on the Helm weekly developer call), that as the gateway API is not part of the core/standard API. Rather, that is an extension installed via optional CRDs. Helm shouldn't include a "non-standard" (non-core) API as part of a standard chart definition.

(I didn't realize when first seeing this PR, that the API would remain non-core for the foreseeable future, iiuc)

Personally, the Gateway API seems to much closer to being a part of core Kubernetes, than many other CRDs e.g. cert-manager's. But strictly, while it is optionally installed via CRDs. It is never going to be part of a "default" Kubernetes API set.

I specifically asked what Helm maintainers see the function of the helm create scaffolding. And the consensus was the scaffolded chart should be a best practices for a vanilla Kubernetes setup. So in that sense. I agree the Gateway API doesn't meet this standard.

So, a few comments from the Gateway API maintainer POV (that's me!):

• Gateway API is a set of extension CRDs that are an official part of Kubernetes. They are subject to the same API review and promotion controls that included APIs are in the core Kubernetes binaries. To be honest, Gateway API is the first of many here - this pattern is already adopted by the AdminNetworkPolicy folks, and more will follow. It makes sense for Helm to have a way to handle this "definitely a Kubernetes API but not included by default" issue. (There's a larger issue about ways to ensure that the required version of Gateway API is installed as well, but that's a way larger discussion). As @kfox1111 says, Gateway API and these other APIs are most likely never going to be installed by default though.
• For Helm charts, I think the way to go is to end up with three settings - hostname, gatewayName, gatewayNamespace, which can be then populated into a HTTPRoute resource and link it up with already-existing infrastructure. Setting one of these should require all three, and the HTTPRoute files should only be included if the values are not empty. (Presumably, this goes for helm create as well).

I'm happy to come to a Helm community call or something at some point to discuss this in a higher-bandwidth way, or to meet up at Kubecon NA and talk there too.

There are two Helm-related problems that have been on my mind for some time:

• How to help chart authors include HTTPRoutes more easily (that's this one)
• How to help chart authors say "Gateway API being installed is a dependency" and "Gateway API must be at least this version", both of which are surprisingly hard problems that will take a while to work out. But having more communication between Gateway API folks and Helm folks here will help a lot, I think.

Apologies for the belated reply. I agree with the above. And I would like to work out how to move forward.

Overall, I'm not exactly sure what the answers are. I think the question is less "how does Helm handle HTTPRoute and gateway API?", and more: "How does Helm (and other tooling) handle 'out-of-tree' types?"

I do think worthy to try and sync at KubeCon. I will be there, as well as other Helm maintainers. And if possible, jumping on the Helm developer call (9:30am Pacific, Thursdays; see #helm-dev on Kubernetes slack for zoom link and password) to try and prompt some attention might help too.

Thanks for approving and your feedback @gjenkins8. I will update the comment tomorrow and will also rebase.

Just out of interest: Did the topic of any none core kubernetes-apis come up at kubecon? I was not able to attend, but am quite interested if there where opinions exchanged. Regarding the role of helm and gateway-api

Whats left to get this in?

Implemented the requested changes to values.yaml template

@hegerdes -- could you fix the conflicts please. I didn't see Andy's prior approval (otherwise I would have merged). Once conflicts are fixed, we should be able to do a quick round of re-approvals and get this merged.

@gjenkins8 No problem!

No code changes required, git handled the modified repo structure just fine in a simple rebase

Thanks for the patience @hegerdes

Since main is now targeting Helm v4, I've created a backport PR to dev-v3 branch: #30658