feat: Add MYKS_HELM_NAMESPACE to environment passed to plugins

[fritzduchardt]

I am using myks for my home automation. I have Argo disabled and roll out with kapp via myks plugin. However, kapp errors on non-existent namespaces. Therefore, I need a means to create the beforehand.

[kbudde]

Code is ok, I'm just not sure if this is the way it should be done.

1. It's running ytt to generate helm values outside of the render stage
2. It's only for helm and not for all sources

I'm doing something similar during rendering with ytt. Isn't this good enough?

PS: I was thinking about providing a common set of features/functions in ytt. Maybe this could be something.

[Zebradil]

I also just create namespaces with ytt when needed, no matter whether ArgoCD is enabled or not.

What if we don't just expose one specific configuration value, but provide a way to inspect the full configuration? Something like MYKS_APP_CONFIG=.myks/envs/<path-to-the-app>/config.yaml (which we'll have to write on disk beforehand). This way we'll automatically provide access to all possible fields in the config. A user then can use yq to extract required values.

[fritzduchardt]

Code is ok, I'm just not sure if this is the way it should be done.

1. It's running ytt to generate helm values outside of the render stage
2. It's only for helm and not for all sources

I'm doing something similar during rendering with ytt. Isn't this good enough?

PS: I was thinking about providing a common set of features/functions in ytt. Maybe this could be something.

Code is ok, I'm just not sure if this is the way it should be done.

1. It's running ytt to generate helm values outside of the render stage
2. It's only for helm and not for all sources

I'm doing something similar during rendering with ytt. Isn't this good enough?

PS: I was thinking about providing a common set of features/functions in ytt. Maybe this could be something.

Nice solution with ytt. I will go with that. So, there is no need for this MR.

In defense of this MR (purely academic): ytt is run several times during initialization already, it is not invoked only during rendering. None of the other sources have a namespace value in the global values schema, so there is nothing we could write into the environment.

[fritzduchardt]

I also just create namespaces with ytt when needed, no matter whether ArgoCD is enabled or not.

What if we don't just expose one specific configuration value, but provide a way to inspect the full configuration? Something like MYKS_APP_CONFIG=.myks/envs/<path-to-the-app>/config.yaml (which we'll have to write on disk beforehand). This way we'll automatically provide access to all possible fields in the config. A user then can use yq to extract required values.

I like the idea of exposing the entire configuration, but doing so in the environment would be much more user friendly. Let's think about is again, once another use case for this emerges.