Use ImageSpec as default task image

[pingsutw]

Motivation: Why do you think this is important?

The below task will fail when running on a remote cluster if people use non-fast register. (pyflyte register --non-fast or pyflyte package + flytectl register)

That's because flytekit won't download the task code in non-fast mode, and expect the user code to be inside the image.

@task()
def t1():
    print("hello world")

Goal: What should the final outcome look like, ideally?

Change the default image (cr.flyte.org/flyteorg/flytekit:py3.8-latest) to ImageSpec(base_image=cr.flyte.org/flyteorg/flytekit:py3.8-latest), so flytekit will build the image at compile time, and copy the user code into the image.

https://github.com/flyteorg/flytekit/blob/1bb50675b4a64bb6318813c9a9ddda77ebbcbb47/flytekit/configuration/default_images.py#L16-L27

Describe alternatives you've considered

Raise an exception at compile time when container_name is None in non-fast mode

Propose: Link/Inline OR Additional context

No response

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[runllm]

To address the issue of task failure in non-fast register mode due to the absence of user code in the default image, the proposal to change the default image to an ImageSpec object is a viable solution. This change would ensure that Flytekit builds the image at compile time and includes the user code, thus preventing runtime failures.

However, this approach requires modifications to the Flytekit configuration to use ImageSpec as the default for task images. Currently, Flytekit does not automatically build images unless explicitly specified by the user through an ImageSpec. Implementing this change would involve altering the default behavior of image handling in Flytekit, potentially affecting all users.

An alternative, as mentioned, is to raise an exception at compile time when container_name is None in non-fast mode. This would enforce that users specify their container configurations explicitly, ensuring that the necessary code is included in the image used for execution.

Both solutions have implications for Flytekit's usability and user experience. The first approach simplifies the user workflow by automating image builds but increases build times and complexity. The second approach places more responsibility on the user to manage their image configurations but maintains current performance and behavior.

Would you like more detailed information on how to implement these changes in Flytekit, or further discussion on the potential impacts of each solution?

Sources:

• ImageSpec in Flytekit
• ImageSpec Example

---

This is an AI-generated response and your feedback is appreciated! Please leave a 👍 if this is helpful and 👎 if it is not.

Mention @RunLLM to ask follow-up questions. See runllm.com for more!