Kanister-sidecar resources definition

Thank you @jaiganeshjk will do a hot-tryout in a sec

First try after patching Kasten and redeploying demo deploys
Tha@jaiganeshjk - I’d strongly suggest to make more comments in charts about this value correlation with sidecars as it’s not clear.

Now, we dig deeper. Kanister job pod also has no limits set

```

Failed to create pod: Failed to create pod. Namespace: elasticsearch, NameFmt: kanister-job-: pods "kanister-job-7c22n" is forbidden: failed quota: default-4srzr: must specify limits.cpu,limits.memor

```

Yea I assume this kanister-job-* pod is from a blueprint based backup. right ?

You might have to use pod Overrides for this use case I believe.

Because if you have an admission controller that forbids pods without resource limits, Kanister pod Override is the way to go for dynamically created pods (by kanister).

I think so. But - sorry for that - docs for override are quite lazy and will require reverse engineering in case of kasten-job construction. Is there any real-world-working example?
Currently experimenting with overrides requires me to rebuild almost whole kasten-job anew, which may hold until - let’s say - next upgrade.
Don’t want to stress out, but unability to set resources for anything related with Kasten eliminates it from 99% of cases ;)

@marcinbojko

Why do you think you will lose it after the upgrades ?

Would you be able to let me know how you are configuring the podOverrides ?

IMO, You won’t lose it unless the configMap is deleted manually.

@jaiganeshjk I had to prepare almost complete replacement for kasten-job, including name, image - aka variables which can change after chart/application upgrade.
I am unable to prepare configMap which be merged successfuly using only partial data (for exemple skip name, skip image etc)
I was hoping for:
 

 apiVersion: v1
 data:
   override: |
     kind: Pod
     spec:
      containers:
      - name: kanister-job
        resources:
          requests:
            cpu: "100m"
            memory: "512Mi"
          limits:
            cpu: "200m"
            memory: "1Gi"
 kind: ConfigMap
 metadata:
   name: pod-spec-override
   namespace: kasten-io

@marcinbojko 

The container name is mandatory field in the override and the container name should match the actual pods container name.

In case of K10, all the container in pods created by kanister has a default name `container`.

Can you try the below ConfigMap ? It should work.

 apiVersion: v1
 data:
   override: |
     kind: Pod
     spec:
      containers:
      - name: container
        resources:
          requests:
            cpu: "100m"
            memory: "512Mi"
          limits:
            cpu: "200m"
            memory: "1Gi"
 kind: ConfigMap
 metadata:
   name: pod-spec-override
   namespace: kasten-io

Thanks @jaiganeshjk - THAT information is very crucial and should be in docs!
Seems that at least this time pods are creating (still failing though) but at least one step closer
 

And debugged to the end - we need extra work to make elasticdump in a blueprint working with basicauth.
Thanks, anything above is working ;)