Introduce starter module blueprint

[stefanprodan]

This PR introduces a blueprint for a minimal Timoni module with the goal of helping people gets started writing modules. Compared to the current module generated by timoni mod init, the starter blueprint contains just a Kubernetes Deployment and a Service. The cue.mod contains only the corev1 and appsv1 Kubernetes schemas. The #Config definition documentation tries to explain the magic behind Timoni autogenerated fields.

Ref: #251

[jmgilman]

This comment applies to lines 45 and 65 as well.

I've been going back and forth on where these types of things should be configured. In a lot of cases, you can make a very good guess about things like security contexts and resource constraints. Defaulting these reduces the cognitive load on a consumer to figure these out, so I think it's a good practice to implement.

However, should these be defined in config.cue or values.cue? The values.cue technically contains the "defaults" according to the documentation. So, as an end-user, I'm more likely to look there than in config.cue. As it stands, we're sort of intermixing defaults. The config.cue holds both the schema and some default configuration which then has the defaults of values.cue applied over it. This can be a bit jarring to someone reading the code.

Hopefully, that makes sense. All that to say, I'm leaning towards moving these to values.cue and keeping config.cue purely schema driven.

[jmgilman]

I suppose this would also apply to things like the default service port as well. I guess the question becomes where do you add a default value: config.cue or values.cue?. If they are literally interchangeable (and perhaps there's a distinction I'm not understanding here), then it seems like without standardizing on one you're going to end up looking in two places to understand a module's default values.

[stefanprodan]

The values.cue serves as a default file when no values files are supplied by the user, and the fields there get overwritten not unified. The config.cue is the place where CUE defaults can be set. The reason I've put the image concrete values in values.cue is for Dependabot or other automation to bump them without having to parse CUE, just JSON. I get that this is very confusing and I haven't got to the Dependabot part yet. I will change the blueprint to set the image defaults in config.cue.

[stefanprodan]

I'm leaning towards moving these to values.cue and keeping config.cue purely schema driven.

I suggest you use a dedicated file for this, like defaults.cue and leave values.cue empty. As documented in the header, values.cue can't used for anything but concrete fields.

// Note that this file must have no imports and all values must be concrete.