Make the backup jobs request and limits configurable about k8up HOT 15 CLOSED

Under implementation Ideas I see add more global environment variables. I don't agree with that, this should be something that schould be configurable by job/schedule IMHO. Because Resic's memory usage is very dependent on how many files it backs up. So a project with not many files to backup will need drastically less resources than a project with millions of files.

from k8up.

Yeah I wasn't sure about this. Please feel free to add your own ideas, you know K8up best :)

from k8up.

I'll take this one

from k8up.

I have refined this issue. @megian please review and add corrections or more acceptance criteria

from k8up.

Most is fine by me. I would just reword "I can optimize resource usage or comply with cluster resource policies" to "I can override the default request and limits of the namespace".

from k8up.

I have updated the summary
basically the "so that" clause should specify what we get out of it from a business perspective and less the technical reasons.

from k8up.

Well in this case this is very theoretic, because it's just a technical issue. K8up is just not usable without this under the cluster conditions. So we probably could write something like enable k8up run on multi tenant cluster allow a higher audience, but as long as I can override the resource and limits, I'm happy with the current wording as well.

from k8up.

I amended the implementation ideas with my ideas

from k8up.

@Kidswiss I have a question related to this sentence “we should have the ability to set the limits by job and schedule, where values can be overwritten like for the S3 endpoints”, do you mean we need a environment variable for the backup job and another one for the schedule (also per request/limit)?

from k8up.

I would do the defaults with environment variables.

I wouldn't do the overrides with them though. But rather in the CRDs. Create a new type like k8upResourceLimits and include it in all the jobs and the schedule. Like the Backend type. It exists for each job type as well as the schedule. This way we can specify backends for schedules as well as for single jobs. That's what I mean with that sentence :)

from k8up.

@Kidswiss ok, all clear now, thank you :)

from k8up.

@megian The PR is now merged and should work. The new feature is currently available in quay.io/vshn/k8up:master image tag available

from k8up.

@ccremer When is an tagged release planned? I think as this is a production cluster, we don't want to set the deployment to a master or latest tag.

from k8up.

I don't have a clear date. There's a milestone for feature parity for the code that is currently released: https://github.com/vshn/k8up/milestone/1
However, I don't think we can finish the milestone in the next 2 weeks as-is, unless #129 is removed from that milestone, then we might make it.
@tobru WDYT?

from k8up.

I don't want to cut a release before we did more tests, so this most probably won't happen this year anymore.

from k8up.