feat: simplify configuration options by forcing configuration through config w/o fallbacks in code

[qdzlug]

Is your feature request related to a problem? Please describe. Right now, we allow users to specify override values in the configuration for elements such as chart versions, locations, etc. Some of these will be fairly static (chart location / name), and some of them will be more volatile (chart version). This requires that we maintain the correct values in two places - in the configuration template, and inside the pulumi python for each given stack.

Describe the solution you'd like I think that we need to take a two step approach here:

1. The configuration file becomes the source of the truth.
2. Values will be removed from the pulumi python - that is, we should not have a fallback value in the pulumi code because that is another place to maintain it.

This will require that we copy over the core configuration as part of setup; this could also open up a pattern where our scripts copy over the default, prompt the user for data we need from them, and then offer the user the choice to do an edit of the file before applying.

We may want to consider also having any manifests that are pulled into the config - this is more for visibility than anything else.

Describe alternatives you've considered We've been running with the values specified in two places to date, and it becomes a pain in the ass making sure that we keep the two in sync. This becomes more difficult when we have dependencies outside of a stack (for example, an upgrade to cert-manager can cause all components that depend on cert-manager, such as the otel operator, to be updated as well).

Additional context Add any other context or screenshots about the feature request here.

[qdzlug]

This seems the best place to drop this comment from a CR made by @4141done which I think is important to bear in mind.

---

I think there's two points where clarity and consistency are important (and I may be just restating what you said above but this is my understanding):

1. On install. While installing I want to be clear on the versions of the primary components over which I have control.
2. When making changes or troubleshooting. I want to know where I can go and find the one source of truth for versions of each component I control (and maybe read only the versions of some I don't)

As for how we accomplish that, I'd need to get more familiar with MARA to have a good opinion, but having a general config file for MARA itself seems like a reasonable idea that's common to many such frameworks. Like having a .maraconf file that you plop in the main directory that could be generated off of your sample.

This actually reminds me of an old blog post @dekobon wrote. But I'm not sure if his thinking has changed since then 😅