Problem description:
We use several initContainers to provide some configuration files, certificates, etc., so we can mix and match what we provide to our containers. As SCDF only allows to set one initContainer per task execution we're forced to provide an additional initContainer which is the sum of the previous ones. Currently we have 3 different initContainers for our tasks, so we have to mantain the combinations of each of them with the rest, and with all of them, and then apply the appropiate one to the task execution configuration. If/As the number of available initContainer grows this becomes a larger problem.
We can narrow the amount of needed initContainers from the total number of possibilities, but we'll have the case that one initContainer will provide some file that activates some configuration that collides with the configuration provided on another initContainer (again this is workable, but it's some work we'd rather not do)
Solution description:
Allow setting several initContainers. To retain backward compatibility, introduce another property initContainers receiving a list of current initContainer and mix both of them (or prefer one over the other)
Description of alternatives:
As described above, our current alternative is generate the neeed amount of initContainers and set the appropiate one to the task execution configuration.
Problem description: We use several initContainers to provide some configuration files, certificates, etc., so we can mix and match what we provide to our containers. As SCDF only allows to set one initContainer per task execution we're forced to provide an additional initContainer which is the sum of the previous ones. Currently we have 3 different initContainers for our tasks, so we have to mantain the combinations of each of them with the rest, and with all of them, and then apply the appropiate one to the task execution configuration. If/As the number of available initContainer grows this becomes a larger problem.
We can narrow the amount of needed initContainers from the total number of possibilities, but we'll have the case that one initContainer will provide some file that activates some configuration that collides with the configuration provided on another initContainer (again this is workable, but it's some work we'd rather not do)
Solution description: Allow setting several initContainers. To retain backward compatibility, introduce another property
initContainers
receiving a list of currentinitContainer
and mix both of them (or prefer one over the other)Description of alternatives: As described above, our current alternative is generate the neeed amount of initContainers and set the appropiate one to the task execution configuration.
Additional context: N/A