CUE at large

[stribb]

I'm trying to figure out how best to fit CUE into my company's monorepo, initially for Kubernetes but also to support other outputs and tooling.

Right now, we have a deployment directory that currently contains Kustomize trees. I'd like to transform these into .cue files, but I'm struggling a bit to find out how to modularise things.

While I'm starting out with the basics of CUE: making opinionated specifications for Kubernetes objects, and instantiating them; I'd like a CUE directory to be able to specify more high level applications in a manner akin to the Kubernetes Tutorial.

For now, I need a couple of things:

• A subdirectory of configuration needs to be able to be applyed to k8s, both for real and in dry-run mode
• I need to be able to interpolate arbitrary secrets from Google Secret Manager

Ideally:

• Tools shouldn't be repeated across the repo
• We shouldn't have to maintain a list of config directories.

I'm sure these are possible but there's a documentation gap between the Kubernetes Tutorial and a real-world production example.

[mpvl]

We have been adding some features like conditional includes (via the @if attribute) as part of the injection mechanism as a means of organizing along various orthogonal lines.

We are currently taking a broader look at modules and organization, though. So we would love to hear from users:

• what kind of limitations they are running into today,
• what they consider an ideal organization of their files, and/or
• what properties or invariants they would like such an organization to have.

[PierreR]

FFIW it is not quite clear to me how you would include files in your config. For instance it is not really practical to copy the content of our crt files when building kubernetes secret from them.

[mpvl]

Currently there are two main ways:

1. mark a CUE file as a named package (package name). All files with the same package name in a directory and all ancestor directories up tot he cue.mod root are automatically pulled in by the cue too in a single namespace.
   An @if(foo) attribute placed above the package clause allows files to be pulled in conditionally based on some expression.

2. create a separate package, somewhere with your CUE root (the directory containing cue.mod) and import it in any of the other files.

See https://cuelang.org/docs/concepts/packages/ for an overview.

We are also contemplating allowing embedding of individual files, including JSON or YAML directly. But it doesn't seem that this is what you want in this case.

Would be interested to learn if the above doc gives you some insights or if you are running into other issues.

[PierreR]

@mpvl For the file to be pulled in, it needs to be a cue file, is that correct ? Hence, I need to convert the crt file to a cue file. That's not such a big deal but if this is the case it would be a nice addition if the cue import command would directly support bytes.

[mpvl]

Right now you would have to convert, indeed. With the contemplated embedding option, it could convert on the fly.

With support for bytes, you mean that your crt file is in binary format (not base64)?

[mpvl]

@PierreR Would this help: https://cue-review.googlesource.com/c/cue/+/9570?

[cueckoo]

This discussion has been migrated to cue-lang/cue#817.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.