anguslees
commented
5 years ago The convention I had been using (without enforcement, so there are plenty of exceptions) is:
- camelCase (to match the k8s resource naming style)
- name component hierarchy after the filename and internal hierarchy (to find relevant code more easily)
- intra-file hierarchy as required. Anywhere you want to name something "foo_config", it should probably be "foo.config".
- use object type as the jsonnet name where there wasn't a more obvious functional name (but see "deploy" discussion below).
I also found it useful to give the generic deployment (lowercase "d") a consistent name (deploy) because in many cases you can switch a Deployment (uppercase "D") with a DaemonSet or StatefulSet, and jsonnet cross-references continue to make sense (eg: the embedded podspec has the same json path in all 3 resource types). So here I chose "deploy" as the general concept rather than a specific "Deployment" type. I agree that's probably confusing.
.. So that's how we got here. We should document some of that style guide somewhere, and/or change it to some other (consistent) style. Patches very welcome to rename things for consistency.
I think your suggestion to add a top-level "functional" name is a good one, and we should do that. It doesn't scale very well to future hypothetical infrastructure that doesn't fit within a single silo however (where does "postgres" appear when it is used as both a logging and monitoring datastore?) so we should also be ready to break that rule sometimes.
For this bug: what are some actions or results you want to see before we can consider this bug closed? It would be nice to rephrase this as a more specific and achievable issue, otherwise it's just going to linger forever.
jjo
Current objects hierarchy and naming lacks consistency (some camelcase there while mostly lowercase), e.g. for prometheus stack:
prometheus.prometheus.deploy (StatefulSet) prometheus.ingress (Ingress) prometheus.config (ConfigMap) prometheus.nodeExporter.daemonset (DaemonSet) prometheus.alertmanager.config (ConfigMap) prometheus.alertmanager.deploy (Deployment)
We should have a clearer take on this, also using a “TLD" naming after the provided stack, as monitoring.<...>, logging.<...> and ingress.<...>, e.g. for above:
monitoring.prometheus.sts (StatefulSet) monitoring.ingress (Ingress) [*] monitoring.prometheus.config (ConfigMap) monitoring.node_exporter.daemonset (DaemonSet) monitoring.alertmanager.config (ConfigMap) monitoring.alertmanager.deploy (Deployment)