[feature] Add ability to parameterize container images

[HumairAK]

Feature Area

/area sdk

What feature would you like to see?

As a user of KFP sdk I want to be able to provide container images as pipeline parameters.

What is the use case or pain point?

There are a number of use cases for this, one example might be requiring a specific image for a specific accelerator type. Having to create multiple pipelines just for different container images is unnecessarily redundant.

Is there a workaround currently?

No

Also note this is a regression from v1.

Previous discussion on this topic: #5834
It was decided not to add this for v2 due to technical hurdles and concerns around component interface breaking. Let's re-evaluate.

---

Love this idea? Give it a 👍.

[HumairAK]

I'm thinking we do something like this:

@dsl.component(base_image="docker.io/python:3.9.17")
def empty_component():
    pass

@dsl.pipeline(name='pipeline-accel')
def pipeline_accel(img: str):
    task = empty_component()
    task.set_container_image(img) # overwrite base_image="docker.io/python:3.9.17"

Which would require us to treat the container spec image as a pipeline channel

It looks like we can just follow the same pattern we have followed for setting accelerators

pipelines/sdk/python/kfp/compiler/pipeline_spec_builder.py

Line 618 in 64e3900

def convert_to_placeholder(input_value: str) -> str:

seems pretty straight forward

[HumairAK]

It looks like we can just follow the same pattern we have followed for setting accelerators

Turns out, while we set the accelerator types and the input parameter string like:

        inputs:
          parameters:
            accelerator_type:
              runtimeValue:
                constant: '{{$.inputs.parameters[''pipelinechannel--atype'']}}'

This will never get resolved in the driver because inputs.parameters is trying to reference the inputs in the argo workflow container_impl:

but these values cannot be added dynamically via pod_spec_patch, they are added during compile time. But because these are runtime values, I don't think it makes sense to be generating these during compile time either.

Note that this means that today, while you can set parameters via sdk for accelerator type, this doesn't get resolved within upstream kfp's driver

I can see that they do get included as resolved inputs in the executor Inputs, so the information is there in the driver to extract and apply these inputs. A simple work around for now can be to parse the pipeline channel strings that look like

'{{$.inputs.parameters[''pipelinechannel--someparameter'']}}'

And search for the parameter in the resolved values within executor inputs when running driver's initpodspecpatch.