jsonnet: establish convention for components default fields

[paulfantom]

Description

Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.
If it fixes a bug or resolves a feature request, be sure to link to that issue.

This is an attempt at establishing a convention for component defaults settings. This change has no implications on code generation as we are reassigning fields one-by-one.

I am starting to align fields in components defaults with CRDs and with our experiments from https://github.com/brancz/kp. Idea is that at some point we will be able to do the following (in jsonnet or cue) in prometheus component:

local defaults = {
  replicas: 2,
  name:: "k8s",
  ...
}

function(params) {
  _config:: defaults + params,
  prometheus: {
    spec: _config,
  },
}

Type of change

What type of changes does your code introduce to the kube-prometheus? Put an x in the box that apply.

• CHANGE (fix or feature that would cause existing functionality to not work as expected)
• FEATURE (non-breaking change which adds functionality)
• BUGFIX (non-breaking change which fixes an issue)
• ENHANCEMENT (non-breaking change which improves existing functionality)
• NONE (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

Changelog entry

Please put a one-line changelog entry below. Later this will be copied to the changelog file.

establish convention for default field types

[ArthurSens]

Ok, let me see if I got the idea...

defaults will hold everything just like it always had. Whatever piece of configuration that can be passed to Custom Resource specs without any special manipulation will be unhidden fields inside defaults. Fields that are unrelated to CRDs, or that require some sort of manipulation before passing them through, will be hidden fields.

Our goal for the following interactions will be to make our libsonnets more similar to upstream CRDs, e.g. replacing alertmanagerName with the appropriate alerting spec..

Another advantage here is avoiding multiple places that modify CRDs, right? e.g. instead of doing something like this:

{
  values+:: {
    prometheus+:: {
      replicas: 2
    }
  },

  prometheus+: {
    prometheus+: {
      spec+: {
        alerting: {
          // ...
        }
      }
    }
  }
}

We could just use:

{
  values+:: {
    prometheus+:: {
      replicas: 2,
      alerting: {
       // ...
      }
    }
  }
}

[ArthurSens]

If the above is true then I like how this is going!

I think this hidden/unhidden approach will be a good baseline to a hypothetical future KubePrometheus custom resource. Unhidden fields we just re-use upstream modules, hidden fields will require extra tooling from our side?

[paulfantom]

You got it 100% right!

---

Unhidden fields we just re-use upstream modules, hidden fields will require extra tooling from our side?

We can include all upstream fields as hidden ones and just 'unhide' them when needed. But I am still open to how exactly we can do this.

---

a good baseline to a hypothetical future KubePrometheus custom resource

I am currently thinking if we can move all non-crd configuration options to such resource somehow. This would simplify a lot of things and potentially allow us to create a simple CLI tool or helm integrations.

[ArthurSens]

Cool :)

Another thing to keep in mind is a good way to keep upstream definitions with the definitions we have defined here. I think upstream doesn't change that often, but it will be extra effort to keep things up-to-date as they change 😬

[paulfantom]

Another thing to keep in mind is a good way to keep upstream definitions with the definitions we have defined here.

That's partially what I am trying to do in #1477 :D