search

cnoe-io / idpbuilder

Spin up a complete internal developer platform with only Docker required as a dependency.
https://cloud-native.slack.com/archives/C05TN9WFN5S
Apache License 2.0
149 stars 45 forks source link

Feature: Templating #295

Open omrishiv opened 2 weeks ago

omrishiv commented 2 weeks ago

Have you searched for this feature request?

Problem Statement

Not sure if this should be in cnoe-io/stacks or here, but I think here makes sense since idpbuilder ultimately deploys the stacks:

I think we need a way to properly template the stacks. Right now, we have stacks that have hardcoded urls for the local cnoe deployment. If we want to think about deploying to remote clusters (cnoe-io/idpbuilder#74), we need a way to template out some of the hardcoded bits.

Possible Solution

Two possibilities: 1) Add new functionality to idpbuilder that allows taking in a values.yaml or similar to give it the ability to render out some common variables. As idpbuilder is ultimately what applies these stacks, that functionality can be centralized there and the stacks in the repo can be kept generic.

2) Rewrite the stacks as helm charts. Helm already has a lot of functionality for advanced templating beyond kustomize. We could have generic values that would deploy the local stack vs overrides that could deploy to remote environments. As a bonus, we'd also maybe be able to leverage chart dependencies, so we could deploy the reference implementation as a collection of sub charts, or the subcharts themselves independent of others.

Alternatives Considered

No response

nimakaviani commented 2 weeks ago

yeah I really like this proposal and it has been top of mind for me too, thinking about how to enable deployment to remote clusters.

I am not so sure about helm charts though. I think the UX that we have for idpbuilder is pretty solid and we should stay with it. whether or not we enable some way of passing configs or enable some of the optionality via some flags, both are approaches we should explore.

tapas4java commented 2 weeks ago

I would propose to have a 'cue' schema, and then we can validate users 'values' file against it before applying.

nimakaviani commented 2 weeks ago

interesting thought and cue has certainly come up a number of times. feels a bit out of place though given that everything else in idpBuilder is just yaml config. But I am open to hearing others' thoughts on this and decide accordingly.

omrishiv commented 2 weeks ago

I'm not saying we ditch idpbuilder for helm. I think we can write some of the stacks as helm charts which would allow us to template them and do some conditional magic depending on the target. We would use idpbuilder to template/deploy. I don't love it, but it's something that's currently available.

Happy to entertain other options, but I think we need to sort this out.

nimakaviani commented 2 weeks ago

oh yeah the stack can be an Application or AppSet that deploys a helm chart and the helm chart can be a custom helm chart that we create from some of the technologies we put together. That part is fine. However, we gotta be careful about having to maintain these helm charts. I'd rather we avoid taking on any maintenance work unless it is strictly required.