Improve AAE helm charts for upgradability

Description

Description
As customers currently have to modify our delivered AAE helm charts and as it is then difficult to migrate changes during upgrades to new versions of AAE, customer has some suggestions for improvement in the helm charts and is asking for them to be brought over into the product:

1. Custom pod labels
2. Custom extraEnv variables
3. Not all properties are defined in the documentation.

The variables supplied by the custumer should be reserved for the customer, so the orignal Alfresco's values shouldn't be copied over to prevent loss of Alfresco configuration. Alfresco's configuration shouldn't be overriden by customer. (by default)

Should unify the prefixes:

  • extra -> reserved for Alfresco

  • customer -> the end user, it should be always empty in the Alfresco's values file
    and types (string, list, map/dictionary)

What can be extra/customer:

  • env

  • volumes

  • volumenMounts

  • initContainers

  • javaOpts

  • podLabel (new)

  • podAnnotation

  • sidecarContainer (new, optional)

The extra and the custumer prefixes are just examples to highlight the differentiation.

extraEnv (string) vs env(dictionary) <- the extraEnv is a string and the env is a map. Which type is preferred? Why there are two?
javaOpts (fixed dictionary) vs extraArgs <- which is preferred?
-> javaOpts is fixed: xmx,xms, other

Database settings should be separate values (not env args).
Some service use the 'db' object some use environemnt variable.

Environment

None

Testcase ID

None
Your pinned fields
Click on the next to a field label to start pinning.

Assignee

Unassigned

Reporter

Dennis Koch

ACT Numbers

00383892

Bug Priority

Category 2