Spike/multipath

[squeedee]

Looking at the work involved for multipath [#570].

I feel like this PR contains the bulk of the work.

I don't see any significant hurdles to this implementation, but I do wish we had generics already.

[netlify[bot]]

✔️ Deploy Preview for elated-stonebraker-105904 canceled.

🔨 Explore the source changes: e5fc78a8e94f7a1b4b294b633dfd9812a6b7d861

🔍 Inspect the deploy log: https://app.netlify.com/sites/elated-stonebraker-105904/deploys/62265139fa232b000712ac6b

[cirocosta]

heey I was playing around with it, but found a little weird behavior - sometimes it seems to select the right DAG path, but sometimes it doesn't, not sure why.

the example I'm working with is as follows:

if workload.spec.image:
  image-provider <--[img]--- deployer

if workload.spec.source.git.url:
  source-provider <--[src]--- image-builder <--[img]-- deployer

soo, I've got this supply chain resources:

  resources:
    - name: source-provider
      templateRef:
        kind: ClusterSourceTemplate
        name: git-repository

    - name: image-builder
      selector:
        matchFields:
          - key: workload.spec.source.git.url
            operator: Exists
      templateRef:
        kind: ClusterImageTemplate
        name: kpack-image
      sources:
        - resource: source-provider
          name: source

    - name: image-provider
      selector:
        matchFields:
          - key: workload.spec.image
            operator: Exists
      templateRef:
        kind: ClusterImageTemplate
        name: image-repository

    - name: deployer
      templateRef:
        kind: ClusterTemplate
        options:
          - name: kappctrl-app
            images:
              - resource: image-builder
                name: image
          - name: kappctrl-app
            images:
              - resource: image-provider
                name: image

and the following workloads:

---
apiVersion: carto.run/v1alpha1
kind: Workload
metadata:
  name: test-from-source
  labels:
    app.kubernetes.io/part-of: test-from-source
    apps.tanzu.vmware.com/workload-type: web
spec:
  params:
    - name: service_account
      value: test-basic
  serviceAccountName: test-basic
  source:
    git:
      ref:
        branch: main
      url: https://github.com/kontinue/hello-world

---
apiVersion: carto.run/v1alpha1
kind: Workload
metadata:
  name: test-from-image
  labels:
    app.kubernetes.io/part-of: test-from-image
    apps.tanzu.vmware.com/workload-type: web
spec:
  params:
    - name: service_account
      value: test-basic
  serviceAccountName: test-basic
  image: ghcr.io/cirocosta/cartographer@sha256:f721c277ea1eab25a87b938ba162f179c758bbd16d2d7c64b6a9c109f29e3687

it's pretty cool to see that we indeed get to the two different trees

NAMESPACE  NAME                               READY  REASON                AGE
default    Workload/test-from-image           False  TemplateStampFailure  12m
default    ├─App/test-from-image              -                            11m
default    └─ImageRepository/test-from-image  True   Ready                 12m


vs


NAMESPACE  NAME                                              READY  REASON               AGE
default    Workload/test-from-source                         True   Ready                9m3s
default    ├─App/test-from-source                            -                           7m41s
default    ├─GitRepository/test-from-source                  True   GitOperationSucceed  9m2s
default    └─Image/test-from-source                          True                        8m17s
default      ├─Build/test-from-source-build-1                -                           8m17s
default      │ └─Pod/test-from-source-build-1-build-pod      False  PodCompleted         8m17s
default      ├─PersistentVolumeClaim/test-from-source-cache  -                           8m17s
default      └─SourceResolver/test-from-source-source        True                        8m17s

but, e.g., right now we're seeing TemplateStampFailure on the test-from-image Workload because it thinks it should the the source -> image-builder -> deployer path.

do you spot something wrong in that supplychain? any thoughts on what might be causing that?

thx!

[squeedee]

@cirocosta You want this:

  resources:
    - name: source-provider
      selector:
        matchFields:
          - key: workload.spec.source.git.url
            operator: Exists
      templateRef:
        kind: ClusterSourceTemplate
        name: git-repository

    - name: image-builder
      templateRef:
        kind: ClusterImageTemplate
        name: kpack-image
      sources:
        - resource: source-provider
          name: source

    - name: image-provider
      selector:
        matchFields:
          - key: workload.spec.image
            operator: Exists
      templateRef:
        kind: ClusterImageTemplate
        name: image-repository

    - name: deployer
      templateRef:
        kind: ClusterTemplate
        options:
          - name: kappctrl-app
            images:
              - resource: image-builder
                name: image
          - name: kappctrl-app
            images:
              - resource: image-provider
                name: image

[cirocosta]

nice!

another little one - I noticed that the supplychain resource list I put above would actually not work when running a setup with the admission webhooks running

e.g., with that one we currently get:

kapp: Error: Applying create clustersupplychain/supply-chain (carto.run/v1alpha1) cluster:
  Creating resource clustersupplychain/supply-chain (carto.run/v1alpha1) cluster:
    API server says: admission webhook "supply-chain-validator.cartographer.com" denied the request: error validating clustersupplychain [supply-chain]: duplicate template name [kappctrl-app] found in options for resource [deployer] (reason: error validating clustersupplychain [supply-chain]: duplicate template name [kappctrl-app] found in options for resource [deployer])

from https://github.com/vmware-tanzu/cartographer/blob/0cf9ae2eda6e37827c833373f16d679636bf8afd/pkg/apis/v1alpha1/cluster_supply_chain_validations.go#L36-L48