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 for its own rollout and monitoring, 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 (the point is that the custom agent configuration only need to care the custom agent configuration fields)

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


enabled_plugins_custom.yaml: |
    plugins:
      agent-service:
        supportedTaskTypes:
        - sensor
        - customtask
    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!

hey @billowy-church-83438 would you like to start an RFC? That's the process to organize the discussions for ideas that could change/enhance the DX

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. 😊 Thanks for the information—I’ll go ahead and formalize everything by creating an RFC before the end of week. This will help ensure we stay organized and keep the process on track.

amazing, thank you! Would you mind pushing it to the upstream folder? Then we can track it on the RFC board

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.