spring.cloud.dataflow.task.platform.kubernetes.accounts.[platformid].initContainer no longer injects the initContainer

[juanpablo-santos]

Description:
Using latest SCDF (2.11.0) the initContainer section described through spring.cloud.dataflow.task.platform.kubernetes.accounts.[platformid].initContainer is no longer working, the pods aren't set up with the described initContainer. F.ex., this configuration from SPRING_APPLICATION_JSON did work with SCDF 2.10.3, but doesn't with 2.11.0:

[...]
     "spring": {
        "cloud": {
          "dataflow": {
            [...]
            "features": {
              "schedules-enabled": true
            },
            "task": {
              "platform": {
                "kubernetes": {
                  "accounts": {
                    "onp": {
                      [...]
                      "initContainer": {
                        "containerName": "shared-libs",
                        "environmentVariables": [
                          "MY_VAR=/my-dir"
                        ],
                        "commands": [
                          "sh",
                          "/tmp/init.sh"
                        ],
                        "imageName": "myimagename:myversion",
                        "volumeMounts": [
                          {
                            "name": "vol-libs",
                            "mountPath": "/libs",
                            "readOnly": false
                          }
                        ]
                      },
[...]

Release versions:
Issue happens with 2.11.0, wasn't happening with 2.10.3

Custom apps:
N/A

Steps to reproduce:
set up the above configuration on SPRING_APPLICATION_JSON on a 2.11.0 SCDF server, and launch some pods; they don't get the initContainer

Screenshots:
N/A

Additional context:
N/A

[juanpablo-santos]

Hi,

went digging to see the cause of this issue, seems it is #5280 again:

• On LauncherInitializationService we can inspect the platform and see that the initContainer configuration is there. So far so good.
• However, when executing the task, KubernetesTaskLauncher calls AbstractKubernetesDeployer.createPodSpec, which in turn delegates initContainer setup to DeploymentPropertiesResolver.getInitContainer. This last method only takes into account application deployer properties to setup the initContainer configuration, ignoring platform specific properties.

#5280 was fixed by spring-cloud/spring-cloud-deployer#381 but seems that this issue was reintroduced by this commit later on.

So the only workaround right now would be the same as in #5280, that is, setting initContainer properties as task properties, something like:

spring.cloud.dataflow.task.platformName=onp
deployer.<TASK_ID>.kubernetes.init-container.container-name=shared-dir
deployer.<TASK_ID>.kubernetes.init-container.environment-variables=SHARED_DIR=/shared-dir
deployer.<TASK_ID>.kubernetes.init-container.commands=/tmp/init.sh
deployer.<TASK_ID>.kubernetes.init-container.image-name=XXXX.YYYY:zzz
deployer.<TASK_ID>.kubernetes.init-container.volume-mounts=[{name: 'vol-shared-dir', mountPath: '/shared-dir', readOnly: false}]

This happens with SCDF 2.11.0 and 2.11.1, either using the official helm chart or the local deployment mode.

[cppwfs]

Issue resolved with the following commit: spring-cloud/spring-cloud-deployer@02a1d05