This message was deleted.

• https://github.com/gimlet-io/onechart for web app template • https://github.com/gimlet-io/gimlet/blob/main/pkg/dx/manifest.go#L23 for the full workload spec

gimlet manifest template

does the client side render for the above manifest struct Examples: https://github.com/gimlet-io/gimlet/tree/main/examples

That's exactly the topic that i'm trying to push to the CNCF Platform WorkinGroup. A mix of score.dev and kubevela (open application model). A somehow simplified subset that i call "platform intention" (score applied to cncf sandbox, and kubevela cncf incubading). I encountered the topic when i presented score.dev to our actuel developpers and i got "see that? that's still too complex for some of our developpers, they just want to say "i want a static frontend, a java backend and that one connected to a pg database". I'm working slowly and it's "on hold" as i need to start some talks about it internally.

You could do this with kyverno as well using Mutators/Generators on either labels on a deployment/ingress or on fields in a CRD

@Antoine BERMON Sounds good! Yes I'm in Paris for KubeCon. I'll plan to come along to the morning coffee on the Tuesday. I've responded to the framadate poll.

in our current pattern we are thinking on going with a lib that can be integrated within an api and a CLI (for standalone). Something like score dev. The discussion we had is maybe the cli should be able to self update with public mapping intention<>template (so that you don't need to download new CLI to get the "correct latest" mapping)

Kyverno can be run as CLI: https://kyverno.io/docs/kyverno-cli/

Makes sense. It's the core issue of if you "distribute" something far and wide you sure need a easy way to "update" that thing either elective by the end consumer or centrally by the core platform.

Looking forward to this chat in Paris!

I have also ventured down this road for the last 8 months. I started with kubevela (OAM) and looked at score.dev however neither the tooling was what I was looking for. Then crossplane 1.14 came out with composition functions and that was the silver bullet I needed to create my own "Application/workflow definition". I currently have an XRD (crossplane resource definition, IE CRD) that defines the spec of the application definitions and then I have a composition that generates all the resources for the application.

Great topic! In our current solution towards a common expression language (CEL) to define workloads and engineering intent, we are grouping YAMLs, consolidating them in a central reconciliation git repo for ArgoCD, and then using Kustomize to render/automate them. The fact that our microservices use OAM guidelines helps. We did explore score.dev and kratix and seem to be progressing in that direction.

I see that a lot, where people take inspiration from generic interface definitions (docker compose, acorn, score, etc) and then generate their own for their context. What would you say is the biggest reason you didn't use an existing interface definition?

All the listed big ones have one company behind them afaik. There is train to hop on.

Love that comic 😂 though this seems to be not creating a new standard, but customising their own. But maybe not, just curious!

@Kevin Scheunemann Can the Crossplane XRDs and compositions being rendered locally? Or do they only get generated when it gets applied to k8s for the Crossplane controller/operator to deal with?

@James Daniels They can with the command you found, however that's used for testing. Crossplane and it's providers run in K8s and uses the kubernetes api to reconcile state. Anyways what I'm doing is simply hydrating (adding container image tags) the application definition yaml in a build pipeline, storing that as an artifact and then apply the hydrated yaml to a k8s cluster and then my crossplane configuration does the rest and keeps it in sync.

So is your challenge that you want to have more visibility into the reconciliation process Crossplane goes through in the cluster? Like what it will render is stored somewhere visible?

@Abby Bangser I think for me it was more of how do I modify the score/OAM to fit our needs. There is definitely a few things missing from score, for example how do I define a job or schema migration before deployment? Or maybe deploying to multiple clusters/regions? With OAM/kubevela dynamic variables are not something exposed very well to the developer, etc.

Ah cool. So some updates both to the interface to the devs (e.g. moar fields for score) and to platform config (take in user inputs and do moar things to it before applying)?

that's correct, maybe exposing additional runtime configuration as well. Some teams need adjustments to build and runtime configuration for example.