Add pre-install hook annotation for namespace creation

[astorise]

This pull request introduces an annotation "helm.sh/hook": "pre-install" to the namespace creation manifest in the haproxy-ingress chart. This change ensures that the namespace is created before any resources, including dependencies, are installed. This is particularly useful for users who want to manage namespaces and their associated resources using Helm, especially when they require specific annotations to be set on the namespace before deploying other resources.

Changes:

Added a namespace.yaml file in the templates directory with the necessary annotation. Updated documentation to reflect the new annotation and its purpose. Testing:

The change has been tested locally with the following setup:

Created a chart parent that includes haproxy-ingress as a dependency. Confirmed that the namespace is created with the correct annotation before the installation of other resources. Motivation:

This addition solves the issue where namespaces need to be pre-configured with specific annotations, ensuring compatibility with Helm's resource lifecycle. It provides a more seamless and automated experience for users managing complex deployments.

[dkorunic]

We intentionally keep hook usage at minimum because not all K8s environments support hooks. Major one that comes first to mind (and which we support) is [AWS Marketplace for Containers](AWS Marketplace for Containers Anywhere). While we typically keep a separate IC Chart for AWS, we typically keep the differences at minimum.

[astorise]

We intentionally keep hook usage at minimum because not all K8s environments support hooks. Major one that comes first to mind (and which we support) is [AWS Marketplace for Containers](AWS Marketplace for Containers Anywhere). While we typically keep a separate IC Chart for AWS, we typically keep the differences at minimum.

Thank you for your feedback. I understand the concerns regarding hook compatibility with different Kubernetes environments, especially AWS Marketplace for Containers Anywhere.

To address this limitation while still allowing for advanced customization, I propose adding an extraManifests feature to the Helm chart. This feature will allow users to add custom resources directly to the chart without using hooks. Here are some advantages of this approach: `` Increased compatibility: Templates are universally supported across all Kubernetes environments, including AWS Marketplace for Containers Anywhere. Flexibility: Users can define custom resources tailored to their specific needs without modifying the main chart. Easier maintenance: This method minimizes the differences between charts while providing extensibility. I suggest structuring the extraManifests to accept an array of user-defined YAML resources. Here is an implementation example:

In the templates/extramanifests.yaml file:

 {{- range .Values.extraManifests }}
 ---
 {{- tpl (toYaml .) $ }}
 {{- end }}

And in the values.yaml file:

## Extra manifests to deploy as an array
extraManifests: []
  # - apiVersion: v1
  #   kind: ConfigMap
  #   metadata:
  #     name: haproxy-extra
  #     labels:
  #       extra: "true"
  #   data:
  #     extra-data: "value"

With this approach, users can easily add and customize their own YAML resources to include in the Helm release.

What do you think? I am open to any suggestions or modifications to improve this proposal.

Thank you in advance for your consideration.

[dkorunic]

@astorise While this looks sensible from the user point of view, it looks like a nightmare from the support/developer side :-) Reason why we typically avoid overwhelming extensibility is because we need to support our EE KIC that uses the same chart -- and this would allow our users to very easily break their prod environments.