[BUG] Enable k8s array plugin and aws batch plugin simultaneously

[hamersaw]

Describe the bug

The k8s array plugin and aws batch plugin both declare themselves as the default plugin for the task type "container_array". Therefore, a FlytePropeller instance is unable to enable both of these plugins simultaneously.

Expected behavior

A Flyte deployment should be able to support the k8s array plugin and AWS batch plugin simultaneously.

Additional context to reproduce

The following FlytePropeller task configuration:

tasks:
  task-plugins:
    enabled-plugins:
      - aws_array
      - K8S-ARRAY
    default-for-task-types:
      - container_array: K8S-ARRAY

causes this error:
Error: Error running FlytePropeller.: TaskType [container_array] has multiple default handlers specified: [aws_array] and [k8s-array]

Screenshots

No response

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

• Yes

Have you read the Code of Conduct?

• Yes

[hamersaw]

@EngHabu @katrogan wanted to get a quick opinion here based on the previous isuse.

To breakdown what is happening in this case, because this is fairly bizarre. We have the ability to define a plugin as being the default for a task type in two place, namely the flytepropeller DefaultForTaskTypes configuration and the plugin entries DefaultForTaskType field. If there is an entry (or multiple) for a plugin defined in the flytepropeller configuration we replace the plugins default task types during the registration process here for a core plugin and here for a k8s plugin.

In this example, the aws_batch plugin declares itself as the default plugin for the container_array task type in it's plugin entry, and then the k8s-array plugin declares as the default for the container_array task type in the flytepropeller configuration. This introduces the obvious conflict.

It looks like there was some previous discussion here and here regarding the DefaultForTaskType plugin field. I think we may have missed a corner case in the implementation.

That being said, I don't see any reason why we need the DefaultForTaskType field defined in the plugin registry entry. I think it makes sense to register plugin types as follows:
(1) if there is only one plugin registered for a task type it is automatically the default
(2) if more than one plugin registered for a task type - require setting the default in the flytepropeller configuration
Implementing this will be trivial, really just removing some functionality that is unnecessary.

It was difficult to track the origins of the plugin configuration, but it seems to predate the flytepropeller configuration. Can we deprecate the DefaultForTaskType plugin entry field?

[katrogan]

That being said, I don't see any reason why we need the DefaultForTaskType field defined in the plugin registry entry. I think it makes sense to register plugin types as follows:
(1) if there is only one plugin registered for a task type it is automatically the default
(2) if more than one plugin registered for a task type - require setting the default in the flytepropeller configuration
Implementing this will be trivial, really just removing some functionality that is unnecessary.

This all sounds super reasonable! I know Haytham was looking into the plugins' specific defaults config so I'll let him chime in, but centralizing the config in propeller sounds 💯