Flyte

Sure. It is a draft https://github.com/flyteorg/flyte/pull/5818/files will revise a bit as I saw some comments already and then we can convert to be PR.

as promised, the RFC draft is here: https://github.com/flyteorg/flyte/pull/5818

Sounds good! The team has been receptive to the feature request, and the discussions have been progressing well. I was actually about to follow up on this feature myself. :blush: Thanks for the information—I’ll go ahead and formalize everything by creating an RFC before the end of tomorrow. This will help ensure we stay organized and keep the process on track.

Hi Folks, I believe we are approaching the final step in enabling separate deployment and management of custom Flyte agents.

Currently, all agents must be configured directly within the FlytePropeller configuration, with the config map mounted under /etc/flyte/config. This setup raises a key question: Is it possible for FlytePropeller to read and merge multiple ConfigMaps?

Problem Statement: The current approach requires all custom agent configurations to be included in the central FlytePropeller config. However, in many cases: • Different teams are responsible for writing custom agents and managing Flyte components like Propeller, Scheduler, and Admin, console, etc • These teams have strong desire to maintain their own configurations for their respective custom agents, rather than relying on the centralized team to manage all configurations. Potential Solution: I propose allowing custom agent configurations to reside in separate ConfigMaps. For example, each custom agent team could maintain their own configuration in a ConfigMap, like this: Example Custom Agent ConfigMap:

    plugins:
      agent-service:
        # defaultAgents are configured by the centralized team of flyte
        agents:
          gnn-agent:
           endpoint: gnnflyteagent:8000
           insecure: true
        supportedTaskTypes:
        - sensor
        - gnntask


enabled_plugins.yaml: |
    plugins:
      agent-service:
        supportedTaskTypes:
        - sensor
        - gnntask
    tasks:
      task-plugins:
        default-for-task-types:
          CUSTOMTASK: agent-service
          # OTHER TASKS are configured by the  centralized team of flyte team
        enabled-plugins:
        - agent-service```
This custom configuration could be deployed in a ConfigMap (e.g.,
`custom-agent.yaml`). The FlytePropeller would then be responsible for *reading and merging* these custom agent configurations with the existing centralized configurations.
*Benefits*:
• *Separation of concerns*: Different teams can manage their own custom agent configurations independently.
• *Decentralized management*: Custom agents can be deployed and managed separately from the core Flyte infrastructure.
• *Flexibility*: This approach allows FlytePropeller to adapt to varying configurations without requiring central management to maintain all settings.
*Request for Feedback:*
I would like to explore this idea further if possible, and we’re open to alternative suggestions for achieving separate configuration management for custom agents.
Are there other approaches that we could consider for enabling more flexible and modular configurations?
Looking forward to your thoughts and feedback!