introduce AppDefinition CRD

[cppforlife]

AppDefinition allows to expose App creation as a dedicated CRD so that "configuration details" are hidden from the App creator. For example:

AppDefinition named my-app specifies how to create MyApp/v1alpha1 by defining App template (represented via App CRD's spec section). Users that want to create new instance of MyApp use create MyApp CR and fill it out with data values (if any required).

apiVersion: kappctrl.k14s.io/v1alpha1
kind: AppDefinition
metadata:
  name: myapp
spec:
  crd:
    apiGroup: apps.co.com
    version: v1alpha1
    name: MyApp
  defaults: # <-- ytt data values?
    ...
  template:
    spec: # App CRD spec
      fetch:
      - git: ...
      template:
      - ytt: ...
      deploy:
      - kapp: ...

apiVersion: apps.co.com/v1alpha1
kind: MyApp
metadata:
  name: app1
  namespace: apps
spec:
  host: blah.com
status:
  conditions:
  - type: Reconciling
  - type: ReconcileSucceeded
  - type: ReconcileFailed
    reason: Invalid
    message: ...

[voor]

Do you think something like this might also support adding in overlays to the original definition?

[cppforlife]

Do you think something like this might also support adding in overlays to the original definition?

hmm, that's an interesting question. i havent thought too much about that. on one hand providing a CR with fine grain config knobs is a good barrier, from the other side providing additional config might be useful. what is the example you are thinking of where this would be needed?

[voor]

In terms of Cluster API, the standard cluster template gets you a Kubernetes cluster for 99% of your use cases. Now, let's say I need to change to a cluster that has PodSecurityPolicies -- I could create an app that has an overlay to add in the admission controller.

[cppforlife]

given that AppDefinition is something that is meant to be defined by end users -- e.g. platform operator for example as an interface to users in the cluster, i'm still undecided on this.

in your example i imagine KubernetesCluster CRD would be defined with some defaults via AppDefinition CR. to support some clusters with PSPs builtin i would probably recommend a data value to be exposed to enable that (so it would be available under KubernetesCluster CR). effectively an overlay is an impl detail of KubernetesCluster CR.

[voor]

In some ways exposing the ability to directly inject overlays would break that contract, in the sense maybe platform operators don't want end-users doing that kind of modifications. Maybe leave overlays off the MVP and punt it to the backlog as a later configurable option to just "turn on use of overlays"

[cppforlife]

as a lower level API we can also provide PredefinedApp (https://gist.github.com/cppforlife/3a5408e3aeb61266d76b44fcb84c3b0f) that relies on AppDefinition for base config.

[iancoffey]

👋 updated, pardon paste fail :) I like this topic and direction and was about to open a new issue about a similar idea, which was just to update App to just be ref'ed from an new, optional AppInstance or similar sort of thing. Seems like a similar approach here but was curious if this project is open for an alternative proposal or is this specific CRD decided on

Anyway, Id love to chat / help with this topic!

[ewrenn8]

I am going to close this in favor of the new Packaging APIs that will fulfill this use case. These APIs are still in an alpha state, but you can track their progress via #87, and provide any feedback on the associated issues!