https://flyte.org logo
Join Slack
Powered by
Hi, I have a bunch of `ContainerTask`s and want to...
# flyte-support
q
Hi, I have a bunch of `ContainerTask`s and want to specify the image tag to use in my workflow as an input (so I can override the default when launching), is there a way to do this?
r
We use a child class of the ContainerTask that includes the docker image tag as an input for the init, then initialize it in a dynamic. i.e.
Copy code
class CustomContainerTask(ContainerTask):
We use a child class of the ContainerTask that includes the docker image tag as an input for the init, then initialize it in a dynamic. i.e.
Copy code
class CustomContainerTask(ContainerTask):
    def __init__(
        self,
        requests: Optional[Resources] = None,
        limits: Optional[Resources] = None,
        docker_image_tag: str = DOCKER_IMAGE_TAG_LATEST,
        **kwargs: Any,
    ):
        super().__init__(
            name="custom_container_task",
            input_data_dir="/var/inputs",
            output_data_dir="/var/outputs",
            inputs=kwtypes(file1=FlyteFile, file2=FlyteFile),
            image=f"{DOCKER_REGISTRTY_URL}:{docker_image_tag}",
            requests=requests,
            limits=limits,
            metadata_format=ContainerTask.MetadataFormat.JSON,
            command=["/bin/sh", "-c"],
            arguments=[" ".join(arguments)],
            **kwargs,
        )

@dynamic
def start_some_custom_task() -> None:
    pod_resources = Resources(cpu="3", mem="20Gi", gpu="1")
    export_terrain_texture_container_task = CustomContainerTask(
        limits=pod_resources,
        requests=pod_resources,
        docker_image_tag=docker_image_tag,
    )
Likely not a fully working example, but I'm sure you get the idea
q
thanks for the idea, will look into it! But seems a bit overkill to create a dynamic workflow to just parametrize the image for one task
do you know where in flyte the substitution of 
{{.input.x}}
e.g. for command is done?
t
q
ah, in plugins, thanks @thankful-minister-83577 Would it be possible to extend this for image as well, or is there some requirement that this is a fqn at register time?
t
it’s already in place for images though. but the search and replace is being done on the flytekit side.
adding this to the run-time side is a much bigger discussion. since that would fundamentally break some of the assumptions in flyte.
container based tasks are strongly tied to the image
allowing this to change at run time kinda fundamentally changes what a task is
q
yeah, I saw the registration time stuff in flytekit...
For me to specify a different tag/version of an image is very natural and does not fundamentally change the task, i.e. a new version with a bugfix or an image built from a testing branch
registering a completely new task for that is ..... super cumbersome
t
let’s pick this up tomorrow? I’m ooo today. but let’s start an issue around this.
i’m curious why…
could you help us understand why registering a completely new task is cumbersome?
like it shouldn’t be cumbersome at all, it should be super super seamless
if you’re finding it cumbersome then we’re doing something wrong and we will fix it 😞
q
So I have a larger workflow that in the end trains an ML model, now I just want to run that workflow again where I only change the container tag for one container task (i.e. new/test version of our data generation/rendering step). Now my idea was to just use an input for that so that the collegues can just launch that workflow again with the new container image... But now I have to teach them how to write/register a new task and a update workflow to use that task... and the only thing that changed is a container tag in one ContainerTask. That essentially makes it super cumbersome to have a feature branch based model in our rendering image..
Or am I missing something?
And in most cases there it is of no use to us to keep many many versions of task/workflows around with just a image tag change
t
will let @freezing-airport-6809 chime in here too.
in this case i feel like the right thing to do is the dynamic wrapper.
you’re right it is just changing the container tag, but changing the container tag has the potential to change the code and business logic entirely
q
sure, it has this potential, but at least in our case this was never the case so far. But I do agree that this is mostly a convenience problem and not on top of the priority list
g
@quaint-diamond-37493 mind creating a ticket for it
159 Views
Open in Slack
PreviousNext
Powered by