1 new commit pushed to

<https://github.com/flyteorg/flytepropeller/tree/master|master>

by pingsutw

<https://github.com/flyteorg/flytepropeller/commit/2086bb91f4d88d68e4414238a3f777615fb0841e|2086bb91>

- Register gRPC plugin after reading configmap (#564) flyteorg/flytepropeller

Release - v1.1.95 New release published by flyte-bot Changelog • 2086bb9 Register gRPC plugin after reading configmap (#564) flyteorg/flytepropeller

#356 Don't add master replica log link when doing elastic pytorch training Pull request opened by fg91 TL;DR When doing torch elastic training, there is no so-called master replica in the resulting

PytorchJob

as opposed to when doing non-elastic pytorch distributed training. Flyteplugins, however, still generates a log link for the non-existing master replica in case of elastic training. This PR fixes this. Type ☑︎ Bug Fix ☐ Feature ☐ Plugin Are all requirements met? ☑︎ Code completed ☑︎ Smoke tested ☑︎ Unit tests added ☐ Code documentation added ☐ Any pending items have an associated Issue I built a propeller image and tested that the correct log links are shown both for elastic and the original non-elastic pytorch tasks. Complete description When doing "normal" non-elastic training, a flyte task looks like this:

@task(
    task_config=PyTorch(
        num_workers=3,
    )
)
def train():

The pytorch job that is created from this task definition looks like this:

apiVersion: "<http://kubeflow.org/v1|kubeflow.org/v1>"
kind: PyTorchJob
metadata:
  ...
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      ...
    Worker:
      replicas: 3
      ...

Notice that there is a so-called "master" replica and multiple workers. In the Flyte console, a link to the master replica and to the 3 worker replicas logs is shown. When using the new elastic training task (torchrun) ...

@task(
    task_config=Elastic(
        nnodes=3,
        nproc_per_node=1,
    ),
)
def train():

... the resulting pytorch job looks like this:

apiVersion: "<http://kubeflow.org/v1|kubeflow.org/v1>"
kind: PyTorchJob
metadata:
  ...
spec:
  elasticPolicy:
    ...
  pytorchReplicaSpecs:
    Worker:
      replicas: 3
      ...

Notice that there is no-more "master" replica. Even though there is no "master" replica, currently the Flyte console still shows a log link for the master replica that doesn't exist. This PR fixes this. Tracking Issue NA Follow-up issue NA flyteorg/flyteplugins ✅ All checks have passed 7/7 successful checks

#574 Correctly validating error code on aborting terminal launchplans Pull request opened by hamersaw TL;DR Correctly checking the event code of an error to abort launchplan Type ☑︎ Bug Fix ☐ Feature ☐ Plugin Are all requirements met? ☑︎ Code completed ☑︎ Smoke tested ☐ Unit tests added ☑︎ Code documentation added ☐ Any pending items have an associated Issue Complete description ^^^ Tracking Issue fixes flyteorg/flyte#3582 Follow-up issue NA flyteorg/flytepropeller GitHub Actions: Goreleaser GitHub Actions: Build & Push Flytepropeller Image GitHub Actions: Bump Version ✅ 11 other checks have passed 11/14 successful checks

#3755 RFC - Flyte Console UI Upgrade Pull request opened by tsheiner Describe your changes The proposal is to do a modest branding, orientation & navigation enhancement to the Flyte Console: 1. move the application header to the left side of the viewport 2. introduce consistent bread crumb element on all pages 3. introduce consistent page header on all pages 4. enable the bread crumb & page header elements to also function as navigation controls Screenshots Please review the RFC for details and illustrations. Note to reviewers flyteorg/flyte DCO: DCO ✅ 5 other checks have passed 5/6 successful checks

#1681 Local Agent Pull request opened by pingsutw TL;DR Run agent code locally Type ☐ Bug Fix ☑︎ Feature ☐ Plugin Are all requirements met? ☐ Code completed ☐ Smoke tested ☐ Unit tests added ☐ Code documentation added ☐ Any pending items have an associated Issue Complete description How did you fix the bug, make the feature etc. Link to any design docs etc Tracking Issue https://github.com/flyteorg/flyte/issues/ Follow-up issue NA OR https://github.com/flyteorg/flyte/issues/ flyteorg/flytekit ✅ All checks have passed 2/2 successful checks

#3756 [BUG] Refresh cluster resource controller on template data changes Issue created by pmahindrakar-oss Describe the bug Following issue #3086 Fixed the case where templates themselves change. Resource controller also needs to handle cases where the template data changes. Eg: role annotation key or value changes for one of the synced service account Expected behavior cluster resource controller should resync config on template data changes aswell Additional context to reproduce No response Screenshots No response Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte

1 new commit pushed to

<https://github.com/flyteorg/flyteplugins/tree/master|master>

by fg91

<https://github.com/flyteorg/flyteplugins/commit/de1d1d345f3bf487701b1f732b2c56f76e81e086|de1d1d34>

- Don't add master replica log link when doing elastic pytorch training (#356) flyteorg/flyteplugins

Release - v1.0.65 New release published by flyte-bot Changelog • de1d1d3 Don't add master replica log link when doing elastic pytorch training (#356) flyteorg/flyteplugins

#1682 Set a less strict deadline for hypothesis tests Pull request opened by eapolinario TL;DR Hypothesis tests sometimes take more than the default 200ms to run Type ☐ Bug Fix ☐ Feature ☐ Plugin Are all requirements met? ☐ Code completed ☐ Smoke tested ☐ Unit tests added ☐ Code documentation added ☐ Any pending items have an associated Issue Complete description For example #1678 Tracking Issue https://github.com/flyteorg/flyte/issues/ Follow-up issue NA OR https://github.com/flyteorg/flyte/issues/ flyteorg/flytekit GitHub Actions: build-plugins (3.8, flytekit-deck-standard) GitHub Actions: build-plugins (3.8, flytekit-dbt) GitHub Actions: build-plugins (3.8, flytekit-data-fsspec) GitHub Actions: build-plugins (3.8, flytekit-dask) GitHub Actions: build-plugins (3.8, flytekit-bigquery) GitHub Actions: build-plugins (3.8, flytekit-aws-sagemaker) GitHub Actions: build-plugins (3.8, flytekit-aws-batch) GitHub Actions: build-plugins (3.8, flytekit-aws-athena) GitHub Actions: lint GitHub Actions: build (windows-latest, 3.11) GitHub Actions: build (windows-latest, 3.9) GitHub Actions: build (windows-latest, 3.8) GitHub Actions: build (ubuntu-latest, 3.11) GitHub Actions: build (ubuntu-latest, 3.10) GitHub Actions: build (ubuntu-latest, 3.9) GitHub Actions: build (ubuntu-latest, 3.8) GitHub Actions: docs GitHub Actions: Docs Warnings ✅ 2 other checks have passed 2/20 successful checks

1 new commit pushed to

<https://github.com/flyteorg/flytekit/tree/master|master>

by eapolinario

<https://github.com/flyteorg/flytekit/commit/ad56f8affeb0cecc2f7d32c8bd55c49165a95429|ad56f8af>

- Set a less strict deadline for hypothesis tests (#1682) flyteorg/flytekit

1 new commit pushed to

<https://github.com/flyteorg/flytekit/tree/master|master>

by eapolinario

<https://github.com/flyteorg/flytekit/commit/1952a56ca36b8310ae756f8e2ef2cf31ec409b8f|1952a56c>

- Use protos of new kubeflow.pytorch plugin instead of legacy pytorch plugin (#1678) flyteorg/flytekit

1 new commit pushed to

<https://github.com/flyteorg/flytekit/tree/master|master>

by pingsutw

<https://github.com/flyteorg/flytekit/commit/06d95b805d36998b58cce93f3837f0bd0ec0b945|06d95b80>

- More time info for time line deck (#1680) flyteorg/flytekit

#357 Fix initial dask job state Pull request opened by bstadlbauer TL;DR When the

dask

plugin creates a

DaskJob

k8s resource, it will initially not have the

.Status.JobStatus

property set. So flyteplugins/go/tasks/plugins/k8s/dask/dask.go Line 316 in </flyteorg/flyteplugins/commit/de1d1d345f3bf487701b1f732b2c56f76e81e086|de1d1d3> will return an empty string until the

DaskOperator

sets the status for the first time. While this period is very brief, we've seen it happening a few times. This PR adds support for the

""

state, effectively handling it the same as being queued/initializing. Type ☑︎ Bug Fix ☐ Feature ☐ Plugin Are all requirements met? ☐ Code completed ☐ Smoke tested ☑︎ Unit tests added ☐ Code documentation added ☐ Any pending items have an associated Issue flyteorg/flyteplugins Codecov: 62.62% (-0.21%) compared to 06866ee ✅ 6 other checks have passed 6/7 successful checks

#3758 flyte_binary not exposing all of propeller metrics Issue created by rxnandakumar We have datadog agent scraping prometheus metrics on k8s for annotated pods. On exposing the metrics port and adding the annotations, we can see the metrics on datadog. When trying to set up a dashboard based on the grafana propeller dashboard we found that the following metrics referenced in the grafana JSON are not exposed by flyte:

flyte:propeller:all:free_workers_count flyte:propeller:all:round:abort_error[5m] flyte:propeller:all:round:system_error_unlabeled[5m] flyte:propeller:all:node:plugin:.*_failure_unlabeled flyte:propeller:all:node:plugin:.*_success_unlabeled flyte:propeller:all:round:raw_unlabeled_ms[5m] flyte:propeller:all:round:raw_ms[5m] flyte:propeller:all:round:panic_unlabeled[5m] flyte:propeller:all:collector:flyteworkflow flyte:propeller:all:metastore:cache_hit flyte:propeller:all:metastore:cache_miss flyte:propeller:all:metastore:head_failure_unlabeled

We can only see the following in datadog when we search for 'propeller':

flyte_admin_admin_builder_flytepropeller_build_failures.count flyte_admin_admin_builder_flytepropeller_build_successes.count flyte_admin_admin_execution_manager_propeller_failures.count

These seem to be flyte admin logs not propeller logs. Expected result: All flyte propeller metrics should be exposed via the metrics port. flyteorg/flyte

1 new commit pushed to

<https://github.com/flyteorg/flyteplugins/tree/master|master>

by jeevb

<https://github.com/flyteorg/flyteplugins/commit/aa1ed678ec085a78f3295e51e6153fb56e9bf1ed|aa1ed678>

- [Bigquery] Add support for impersonation of GSA bound to task's KSA (#355) flyteorg/flyteplugins

Release - v1.0.66 New release published by flyte-bot Changelog • aa1ed67 [Bigquery] Add support for impersonation of GSA bound to task's KSA (#355) flyteorg/flyteplugins

#358 Fix duplicate env vars in container Pull request opened by hamersaw TL;DR Currently, when building a k8s Pod we make duplicate calls to

AddFlyteCustomizationsToContainer

(here and here. This PR updates the BuildRawPod function to call a refactored BuildRawContainer to ensure the

AddFlyteCustomizationsToContainer

is only called once so that env vars are only injected a single time. Type ☑︎ Bug Fix ☐ Feature ☐ Plugin Are all requirements met? ☑︎ Code completed ☑︎ Smoke tested ☐ Unit tests added • [ x] Code documentation added ☐ Any pending items have an associated Issue Complete description ^^^ Tracking Issue fixes flyteorg/flyte#3740 Follow-up issue NA flyteorg/flyteplugins ✅ All checks have passed 2/2 successful checks

#414 Add tags to execution spec Pull request opened by pingsutw TL;DR Add tags to execution spec Type ☐ Bug Fix ☑︎ Feature ☐ Plugin Are all requirements met? ☑︎ Code completed ☑︎ Smoke tested ☐ Unit tests added ☐ Code documentation added ☐ Any pending items have an associated Issue Complete description ^^^ Tracking Issue flyteorg/flyte#3320 Follow-up issue NA flyteorg/flyteidl GitHub Actions: Generate JS Code ✅ 8 other checks have passed 8/9 successful checks

#3759 [UI Feature] Update FE docs Issue created by jsonporter Motivation: Why do you think this is important? Our docs are currently out of date; this ticket will track updating for both setting up a local env as well as contribution. Goal: What should the final outcome look like, ideally? Our documentation should be complete and easy for OSS community members to understand so that contributing to the codebase is simpler. 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 flyteorg/flyte

#3760 update features list format Pull request opened by cosmicBboy Tracking issue Describe your changes Check all the applicable boxes ☐ I updated the documentation accordingly. ☐ All new and existing tests passed. ☐ All commits are signed-off. Screenshots Note to reviewers flyteorg/flyte ✅ All checks have passed 6/6 successful checks

1 new commit pushed to

<https://github.com/flyteorg/flyteplugins/tree/master|master>

by hamersaw

<https://github.com/flyteorg/flyteplugins/commit/2a7a6f9c6b888bc51352e6997cfd6cdffcc96d42|2a7a6f9c>

- Fix initial dask job state (#357) flyteorg/flyteplugins

Release - v1.0.67 New release published by flyte-bot Changelog • 2a7a6f9 Fix initial dask job state (#357) flyteorg/flyteplugins

#3356 [Docs] Find a place to document applying changes via helm chart across all namespaces and projects Issue created by ppiegaze Description The discussion begins here Need to sort through this thread and figure out where to document the essential points. Among other issues: The rbac given in values.yaml is wrong and had to be replaced with the rbac given in eks-production.yaml Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte

#3761 [Core feature] Wrap ImageSpec packages in quotes Issue created by cosmicBboy Motivation: Why do you think this is important? When using

ImageSpec

and

pyflyte build

, specifying packages like

transformers[torch,deepspeed]>=4.28.1,<5

will fail during the build step will fail and to fix it, the user needs to wrap the package dep in quotes

'transformers[torch,deepspeed]>=4.28.1,<5'

. Goal: What should the final outcome look like, ideally? To improve the ergonomics of this feature, packages deps should automatically be wrapped in quotes by flytekit. Describe alternatives you've considered Keeping the status quo, which would be inconvenient for end users. 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 flyteorg/flyte

#3762 Allow setting resources for cluster resource controller deployment Pull request opened by katrogan Tracking issue N/A Describe your changes This change allows setting optional resource requests & limits for the cluster resource deployment Testing Modified

charts/flyte-core/values.yaml

to add a resources block and verified that running

make helm

updated the generated helm chart:

# Source: flyte/charts/flyte/templates/clusterresourcesync/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: syncresources
  namespace: flyte
...
spec:
 ...
  template:
    metadata:
      annotations:
        configChecksum: "475154c41cdb06999025ab796aa1264fa3d235df51ac088a39c89c7ce300408"
      labels:
        <http://app.kubernetes.io/name|app.kubernetes.io/name>: flyteclusterresourcesync
        <http://app.kubernetes.io/instance|app.kubernetes.io/instance>: flyte
        <http://helm.sh/chart|helm.sh/chart>: flyte-v0.1.10
        <http://app.kubernetes.io/managed-by|app.kubernetes.io/managed-by>: Helm
    spec:
    ...
      serviceAccountName: flyteadmin
      resources:
          limits:
            cpu: 250m
            ephemeral-storage: 100Mi
            memory: 500Mi
          requests:
            cpu: 10m
            ephemeral-storage: 50Mi
            memory: 50Mi
      volumes:
        ...

Check all the applicable boxes ☐ I updated the documentation accordingly. ☐ All new and existing tests passed. ☐ All commits are signed-off. Screenshots N/A Note to reviewers N/A flyteorg/flyte ✅ All checks have passed 8/8 successful checks

#3763 [Docs] Only kuberay 0.3.0 is supported Issue created by eapolinario Description We've seen reports of different bugs in the latest few kuberay reports, more specifically: • 0.4: they changed reconcile logic in the operator. if you run the ray job, the status will always be pending. kuberay community didn’t test it, and release it. • 0.5: they inject init container into worker nodes, and didn’t set the resource (cpu, memory) for the init container. therefore, we can’t run the rayjob because there is k8s quota in every project-domain namespace, and quota requires every container to set the cpu, mem. We should make it apparent that the current ray extension only works with the version 0.3.0 of the kuberay operator. Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte

#3764 Update Flyte components Pull request opened by flyte-bot Updated flyte deployment • Updated GCP Flyte kustomize generated manifest file • Updated EKS Flyte kustomize generated manifest file • Updated Sandbox Flyte kustomize generated manifest file • Updated TEST Flyte kustomize generated manifest file • Updated GCP Flyte helm generated manifest file • Updated EKS Flyte helm generated manifest file • Updated Sandbox Flyte helm generated manifest file • Updated TEST Flyte helm generated manifest file • Auto-generated by [flyte-bot] flyteorg/flyte GitHub Actions: build-and-push-sandbox-bundled-image ✅ 11 other checks have passed 11/12 successful checks

1 new commit pushed to

<https://github.com/flyteorg/flytekit/tree/master|master>

by pingsutw

<https://github.com/flyteorg/flytekit/commit/8437023ad1a4fce367a2e1ac2368276154b5e927|8437023a>

- Rename external plugin to agent (#1666) flyteorg/flytekit

Release - v1.6.2b1 New release published by pingsutw What's Changed • Set a less strict deadline for hypothesis tests by @eapolinario in #1682 • Dep: Use protos of new

kubeflow.pytorch

plugin instead of legacy

pytorch

plugin by @fg91 in #1678 • More time info for time line deck by @Yicheng-Lu-llll in #1680 • Rename external plugin to agent by @pingsutw in #1666 Full Changelog: v1.6.2b0...v1.6.2b1 flyteorg/flytekit