Mega Feature: Implement collections (for loops) in ResourceGroups

[a-hilaly]

Add support for collections in ResourceGroups to allow dynamic creation of multiple similar resources.. This will probably need a design and a review. It also needs the garbage collection mechanisms to be in place.

• Implement iteration based on a range or list
• Add current iteration index reference within resource definitions
• Support specifying "deployment strategies" for collection types

Example:

apiVersion: x.symphony.k8s.aws/v1alpha1
kind: ResourceGraphDefinition
metadata:
  name: replicaset.x.symphony.k8s.aws
spec:
  apiVersion: v1alpha1
  kind: ReplicaSet
  definition:
    spec:
      image: string
      replicas: integer
  resources:
  - name: podsCollection
    collection:
      index: ${range(0, spec.replicas)}
      deploymentStrategy: RollingUpdates
      definition:
        apiVersion: v1alpha1
        kind: Pod
        metadata:
          name: pod-unit-${index}
        spec:
          containers:
          - image: ${spec.image}
            replicas: ${spec.replicas}

[gfrey]

Index reminds me of Terraform's count iteration concept. This had plenty of downsides when combined with lists of actual configuration values. Any change to the that list would result in modification on all subsequent list items. This was eventually solved with for_each based on sets or dicts. Then the item or key was used as part of the resource address. This made things a lot more stable. Possible solution could be to change the relevant part of the example above to:

collection:
  items: ${range(0, spec.replicas)}
  deploymentStrategy: RollingUpdates
  definition:
    metadata:
      name: pod-unit-${item}

An immediate application for this would be distribution of a VPC's subnets to availability-zones. Then the list of items would be the AZs (or maybe a dictionary from AZ to CIDR block).

A follow-up question would be how the resources of a collection can be queried? In the subnets application I would need to associate a NetworkACL with all these subnets. How could that be done?

[greghaynes]

Would the above solutions be limited in that they cannot allow for multiple sources of iteration within a single resource?

Here's a contrived example: Imagine we want to support a RG which supports defining multiple containers where some values are defaulted below each container.

apiVersion: kro.run/v1alpha1
kind: ResourceGroup
metadata:
  name: Application
spec:
  apiVersion: v1alpha1
  kind: Application
  definition:
    spec:
      name: string
    containers:
      - name: frontend
        image: nginx
      - name: backend
        image: nginx

This would mean it needs to be capable of rendering out a single Deployment resource, but within that deployment resource it iterates over the collection of containers within our RG:

  resources:
    - id: deployment
      definition:
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: ${schema.spec.name}
        spec:
          replicas: 1
          selector:
            matchLabels:
              app: deployment
          template:
            metadata:
              labels:
                app: deployment
            spec:
              containers:
               ${ NEEDS CONTAINER COLLECTION HERE }

One thought on how to approach this is to introduce a vars layer like the following:

apiVersion: kro.run/v1alpha1
kind: ResourceGroup
metadata:
  name: Application
spec:
  apiVersion: v1alpha1
  kind: Application
  definition:
    spec:
      name: string
    containers:
      - name: frontend
        image: nginx
      - name: backend
        image: nginx
  vars:
    - name: deploymentContainers
      function: map
      input: schema.spec.containers
      render:
        - name: ${item.name}
          image: ${item.image}
          resources:
                requests:
                  memory: "64Mi"
                  cpu: "250m"
  resources:
    - id: deployment
      definition:
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: ${schema.spec.name}
        spec:
          replicas: 1
          selector:
            matchLabels:
              app: deployment
          template:
            metadata:
              labels:
                app: deployment
            spec:
              containers:
                ${vars.deploymentContainers}

[btwseeu78]

How about object bases substitution, like how helm template works, like toYaml function in helm.

we are substituting {{ $schema.spec.containers } let containers be an object rather than value type.
so we can do like this.

apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
  name: my-application
spec:
  # kro uses this simple schema to create your CRD schema and apply it
  # The schema defines what users can provide when they instantiate the RGD (create an instance).
  schema:
    apiVersion: v1alpha1
    kind: Application
    spec:
      containers:
        - name: conatiner1
        - name: container2

containers:
{{ $.schema.spec.containers }}

[VladRico]

Hi there !
I'm really interested about this feature. Has a solution been adopted ? Or is it still open to proposals ?

[handicraftsman]

This tbh.

As somebody who's using a similar tool, but built in-house, I absolutely understand the need of having ability to e.g. define several databases, containers, or whatever in a SINGLE resource manifest.