Flyte

it's unrelavant

don't copy the click_types.py

do it

not it doesnt have

<@U05FFAF4FC2> does https://github.com/flyteorg/flytekit/pull/2619 have other dependencies? Can it be upgraded standalone?

Check this one

https://github.com/flyteorg/flytekit/pull/2619|https://github.com/flyteorg/flytekit/pull/2619

It’s related to my pr about flyteschema

This is fixed by me and ketan

Yes I know this error

the custom sensor has the error: {"asctime": "2024-10-10 08:05:36,444", "name": "flytekit", "levelname": "ERROR", "message": "failed to create dssensor task with error `np.string_` was removed in the NumPy 2.0 release. Use `np.bytes_` instead.."}

please update both

flyte: 1.13 flytekit: there

agent watcher

and flyte

The change you have fixed is here: https://github.com/flyteorg/flytekit/pull/2012?

cc <@U05HLV2URT5> <@U04FZQ8U3C7> ^^

I'll help him or she make the upgrade of agent success

tell the person or team in charge of upgrade flytekit and flyte contact me

this is the version

flyte 1.13

I've fixed already

btw, <@U05FFAF4FC2> can you please forward the metadata service PR fix to avoid override default agent being overriden? when the flyte team at linkedin upgrade the flyte SDK, they can pay special care to that.

yes, anytime, very excited the incoming journey

Thanks A TON for staying up to help to resolve the outage! :heart: will ping here once the new data sensor works as well :slightly_smiling_face:

please let me know if the new agent work in linkedin

and checked the code by myself

<@U05HLV2URT5> as you are oncall, do you want to try that?

verified by Kevin

sensor: defaultAgent

YES

100% correct answer for youo

let me check the code now

give me 1 min

hi

wati

• sensor: defaultAgent

like sensor: defaultAgent?

how to specify that?

what if the sensor is for defaultAgent?

make sure you are having the right key value (relative position

    # supportedTaskTypes:
      # - chatgpt
      # - sensor  
      # - spark
    #   - default_task
    #   - custom_task
    #   - sensor
    #   - airflow
    # By default, all the request will be sent to the default agent.
    defaultAgent:
      endpoint: "localhost:8000"    
      insecure: true
      timeouts:
        CreateTask: 100s
        GetTask: 100s
      defaultTimeout: 100s
    agents:
      custom_agent:
        endpoint: "localhost:8001"
        insecure: true
        # defaultServiceConfig: '{"loadBalancingConfig": [{"round_robin":{}}]}'
        timeouts:
          ExecuteTaskSync: 300s
          GetTask: 100s
        defaultTimeout: 300s
    agentForTaskTypes:
      # It will override the default agent for custom_task, which means propeller will send the request to this agent.
      - chatgpt: custom_agent
      - airflow: custom_agent```

THAT ME GIVE YOU AN EXAMPLE NOW

USE THAT

YES

say if we are on the old version can not upgrade. does the agentForTaskTypes work?

we add an agent watcher and fix bug about the routing mechanism

https://github.com/flyteorg/flyte/releases/tag/v1.13.0

but maybe it will cause some error (just rollout back)

it's ok to upgrade propeller only in my opinion

upgrade to flyte 1.13.0

currently the bug is causing us unable to roll out custom agent.

the upgrade at LinkedIn will be slow and need more testing.

we have some tiny bugs before

use the latest one

I think it probably not the latest propeller. cc <@U05HLV2URT5>

are you using the latest flytepropeller?

<@U05FFAF4FC2> We have observed some overridding problem

    plugins:
      agent-service:
        defaultAgent:
          endpoint: flyteagent:8000
          insecure: true
        agents:
          aip-agent:
           endpoint: <http://aipflyteagent.dlc-system.svc.kube.grid.linkedin.com:8000|aipflyteagent.dlc-system.svc.kube.grid.linkedin.com:8000>
           insecure: true
        supportedTaskTypes:
        - sensor
        - dataservicetask```
it looks like the request will be always sent to the `aip-agent`  end point.

and we can not remove `sensor` because it is needed for the defaultAgent.
What’s the best way to do this?

> Really?! are there recent changes that we are using the old version? I just misunderstand this, supported task type is in agent-service section, this is never changed. the order of the key in yaml can be different, but it's always the same.

will try it out and keep you updated if any other issues. :slightly_smiling_face:

thank you so much

thanks a lot for hte confirmation. this helps me resolve some unknowns before I package and deploy my custom_agent separately!

for example, you have 2 agent deployement, agent-service needs to know all supported task types, so that propeller can check if we support the given supportedTaskTypes from flytekit.

got it!

yes, but supported task types will not be used by defaultAgent , it will be used by agent-service

this is what we configured

> supported task type is in agent-service section Really?! are there recent changes that we are using the old version?

supported task type is in agent-service section

    supportedTaskTypes:
      - chatgpt
      - sensor  
      - spark
      - default_task
      - custom_task
      - sensor
      - airflow
    By default, all the request will be sent to the default agent.
    defaultAgent:
      endpoint: "localhost:8000"    
      insecure: true
      timeouts:
        CreateTask: 100s
        GetTask: 100s
      defaultTimeout: 100s
    agents:
      custom_agent:
        endpoint: "localhost:8001"
        insecure: true
        # defaultServiceConfig: '{"loadBalancingConfig": [{"round_robin":{}}]}'
        timeouts:
          ExecuteTaskSync: 300s
          GetTask: 100s
        defaultTimeout: 300s```

no

wait, but supportedTaskTypes in defaultAgent section. the defaultAgent would not have custom_sensor

I think supportedTaskTypes will be looked like this, is this what you are asking?

    - sensor
    - custom_sensor```

I mean if there is other team configures the defaultAgent with the default sensor name…

if you are using the latest version of propeller

propeller will auto-update latest supported task types

right now you don't need supportedTaskTypes

sorry

yes it will

no it will not

one last check point: what about for sensor agent?

The default name is sensor : https://github.com/flyteorg/flytekit/blob/master/flytekit/sensor/base_sensor.py#L54 If I package the custom_agen with end point 8001 it supports custom_sensor type as well, will the configuration look like following?

defaultAgent:
  endpoint: "localhost:8000"    
  insecure: true
  timeouts:
    CreateTask: 100s
    GetTask: 100s
  defaultTimeout: 100s
  supportedTaskTypes:
        - sensor <<<<<<<========= 
agents:
  custom_agent:
    endpoint: "localhost:8001"
    insecure: true
    timeouts:
      ExecuteTaskSync: 300s
      GetTask: 100s
    defaultTimeout: 300s
agentForTaskTypes:
  - chatgpt: custom_agent
  - airflow: custom_agent
  - custom_sensor: custom_agent <<<<<======== ```

> • but for any other types of task, it will still be sent to the default agent yes

> for custom_task, propeller will be sent to the custom_agent, not the default agent. yes

> It can be used in production, not just for canary deployment, correct? yes, there's company use that

defaultAgent:
  endpoint: "localhost:8000"    
  insecure: true
  timeouts:
    CreateTask: 100s
    GetTask: 100s
  defaultTimeout: 100s
agents:
  custom_agent:
    endpoint: "localhost:8001"
    insecure: true
    timeouts:
      ExecuteTaskSync: 300s
      GetTask: 100s
    defaultTimeout: 300s
agentForTaskTypes:
  - chatgpt: custom_agent
  - airflow: custom_agent```

Hi community, as we are leveraging the agent framework to manage the custom agent in a decoupled way, we’d like to understand if propeller has the capabilities to talk to multiple agent end points? for example, In the propeller config map, people usually define one defaultAgent

    plugins:
      agent-service:
        defaultAgent:
          endpoint: customagent:8000
          insecure: true```
But if we have the custom agent running serving different port,

```agent_service.yaml: |
    plugins:
      agent-service:
        defaultAgent:
          endpoint: customagent1:8000
          insecure: true
        customAgent1:
          endpoint: customagent2:8001
          ...
        customAgent2:
          endpoint: customagent2:8002```