feat: resource workload configuration support #259
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a WIP for being able to template basic resource workload implementations (HPA/PDB) and eventually resources per service overrides (requests/limits).
Currently the requests/limits overrides are ignored in the templating stage as these are currently done in an odd way that requires a bit more work to override (mainly that service templates are still done in helm, so can't benefit from the way the build-deploy-tool generates values)
The way to consume this currently is to set a
LAGOON_FEATURE_FLAG_WORKLOAD_RESOURCES
envvar, which is a base64 encoded JSON value.The structure of which looks something like this, which is a
map[string]structure
where thestring
= the parameter name which is to be consumed, and thestructure
is the data payload contained within which can define the hpa, pdb, and eventually resources, that should be applied to any services that match the servicetype and request the workload resources by nameCurrently, a user needs to specify the workloadresource to consume using a label in docker-compose.yml like so, and the build will fail if the requested workloadresource is not for the requested service-type that the workloadresource is defined for
It is also possible to specify workloadresource assignment via an envvar override type similarly to how dbaas and service type overrides work(but as a feature flag for now), where it is
serviceName:workloadResource
. This allows for updates to workload resources without requiring the docker-compose file to be modified. API wins out over docker-compose defined workload resources too.