How to define pod resource limits in pom.xml?

[TueDissingWork]

Hi Guys,
I wanted to see if I could get rid of all partial yaml definitions and instead rely solely on what is available through the pom.xml. But I am having trouble with defining the resource requestsand release limits within the pom.xml.
I can't seem to locate it in the documentation, but I might just be missing it.

Any pointers on how to achieve this would be great.

Thanks,
Tue

[rohanKanojia]

Do you want to add these in Deployment's PodTemplateSpec?

[TueDissingWork]

Currently working with an OpenShift cluster. I need it to end up within the DeploymentConfig.yaml.
Any way to handle this from inside the pom?

[rohanKanojia]

I don't think we're supporting this currently. We do provide support for setting requests/limits for OpenShift S2I build but for main DeploymentConfig it is not available at the moment.

Maybe we can add these fields in <resource> configuration so that user can specify requests/limits like this:

<configuration>
    <resources>
        <requests>
              <cpu>500m</cpu>
              <memory>512Mi</memory>
        </requests>
       <limits>
              <cpu>1000m</cpu>
              <memory>1Gi</memory>
        </limits>
</configuration>

our DefaultControllerEnricher would add these specified requests/limits into generated controllers.

[TueDissingWork]

I don't think we're supporting this currently. We do provide support for setting requests/limits for OpenShift S2I build but for main DeploymentConfig it is not available at the moment.

Maybe we can add these fields in <resource> configuration so that user can specify requests/limits like this:

<configuration>
    <resources>
        <requests>
              <cpu>500m</cpu>
              <memory>512Mi</memory>
        </requests>
       <limits>
              <cpu>1000m</cpu>
              <memory>1Gi</memory>
        </limits>
</configuration>

our DefaultControllerEnricher would add these specified requests/limits into generated controllers.

Thank you for the explanation. Any good examples on how to approach this?
Need to differentiate these limits between different NS (dev/test/prod)?

[rohanKanojia]

For now, you're using fragments, right?

Do you think for now you can try using jkube.environment for placing different fragments for different environments? You can see short demo here

[TueDissingWork]

yeah, I am using fragtments, but wanted to get away from that, as each file (for each NS) are more or less identical; resources being the dynamic component.

[TueDissingWork]

ahh, there's a common environment well. Maybe that is what I am looking for! Will test this.

[TueDissingWork]

when combining multiple "environments" it seems to do the trick. Thanks!

[rohanKanojia]

I think providing resource limits via XML/Groovy DSL might also be a good addition.

[TueDissingWork]

mits via XML/Groovy DSL might also be a good a

I agree, then I could get completely rid of the remaining fragments.

[rohanKanojia]

@manusa : Do you think providing resource requests/limits in <resource> configuration makes sense? If you agree I'll open this issue

[TueDissingWork]

@manusa : Do you think providing resource requests/limits in <resource> configuration makes sense? If you agree I'll open this issue

It think it makes a lot of sense! A little too busy right now to add it myself, but maybe in a few weeks I could start contributing this; or just assist in testing/validating the solution.

[manusa]

@manusa : Do you think providing resource requests/limits in <resource> configuration makes sense? If you agree I'll open this issue

Yes it does. However, we need to fix the ResourceConfig class first. We've been adding more and more fields there and everything is a mess. We need to merge #1969 before proceeding with this.

[rohanKanojia]

ResourceRequirements struct (resources field ) contains a new alpha field claims since latest Kubernetes release. It seems to be related to Kubenetes Dynamic Resource Allocation (which has to be enabled with a feature gate).

Does it make sense to add support for this field as well? Or shall we leave it for now until some user requests it in future (when it becomes stable)?