Pending review on flyteorg/flyteplugins - Manage reminder [#347] Fix double http in the Spark Driver UI Link (mucahitkantepe) 5 days stale · 2 months old · Waiting on _ pingsutw_

#3825 Include k8s pod events in DemystifyPending Issue created by andrewwdye Motivation: Why do you think this is important? It can be difficult to understand delays in task start up. We recently added runtime metrics to the timeline view to better surface where time is spent, and PodCondition reasons are included in the task state tooltip to explain state transitions. The full text of this tooltip is of the form

7/3/2023 6:41:18 PM UTC task submitted to K8s

7/3/2023 6:41:18 PM UTC Unschedulable:0/5 nodes are available: 1 node(s) were unschedulable, 4 node(s) didn't match Pod's node affinity/selector. preemption: 0/5 nodes are available: 5 Preemption is not helpful for scheduling.

7/3/2023 6:42:20 PM UTC [ContainersNotReady|ContainerCreating]: containers with unready status: [aqrp2plhk79cj5dwzg5z-n0-0]|

However this doesn't indicate ongoing node allocation or image pull, two of the most common delays in "happy path" task start up. By comparison

kubectl get events

has much richer information.

❯ kubectl get events -n flytesnacks-development --sort-by='{.metadata.creationTimestamp}' --field-selector involvedObject.name=aqrp2plhk79cj5dwzg5z-n0-0
LAST SEEN   TYPE      REASON                 OBJECT                          MESSAGE
6m57s       Warning   FailedScheduling       pod/aqrp2plhk79cj5dwzg5z-n0-0   0/5 nodes are available: 1 node(s) were unschedulable, 4 node(s) didn't match Pod's node affinity/selector. preemption: 0/5 nodes are available: 5 Preemption is not helpful for scheduling.
6m50s       Normal    TriggeredScaleUp       pod/aqrp2plhk79cj5dwzg5z-n0-0   pod triggered scale-up: [{eks-opta-oc-production-nodegroup1-d7fdbb758a882b40-dec46029-5e1e-5bf0-4999-238661b4dc51 0->1 (max: 5)}]
5m55s       Normal    Scheduled              pod/aqrp2plhk79cj5dwzg5z-n0-0   Successfully assigned flytesnacks-development/aqrp2plhk79cj5dwzg5z-n0-0 to ip-10-0-148-239.us-east-2.compute.internal
5m53s       Normal    Pulling                pod/aqrp2plhk79cj5dwzg5z-n0-0   Pulling image "<http://cr.flyte.org/flyteorg/flytekit:py3.9-latest|cr.flyte.org/flyteorg/flytekit:py3.9-latest>"
5m52s       Normal    TaintManagerEviction   pod/aqrp2plhk79cj5dwzg5z-n0-0   Cancelling deletion of Pod flytesnacks-development/aqrp2plhk79cj5dwzg5z-n0-0
5m23s       Normal    Pulled                 pod/aqrp2plhk79cj5dwzg5z-n0-0   Successfully pulled image "<http://cr.flyte.org/flyteorg/flytekit:py3.9-latest|cr.flyte.org/flyteorg/flytekit:py3.9-latest>" in 30.158785098s
5m23s       Normal    Created                pod/aqrp2plhk79cj5dwzg5z-n0-0   Created container aqrp2plhk79cj5dwzg5z-n0-0
5m23s       Normal    Started                pod/aqrp2plhk79cj5dwzg5z-n0-0   Started container aqrp2plhk79cj5dwzg5z-n0-0

Goal: What should the final outcome look like, ideally? The execution closer should include task-specific event details, including scheduling attempts, node allocations, and image pulls. Describe alternatives you've considered A more complete solution may overhaul event information in the execution closure so that reasons are not coupled to Flyte state transitions and could instead surface a sink of structured or unstructured event information. This is beyond the scope of this particular issue, but the proposal below does not preclude such an investment in the future. Propose: Link/Inline OR Additional context As a potential solution, update DemystifyPending to interleave k8s pod events alongside existing PodCondition reasons. Note the reporting interface assumes a single-event per state; however, a recent change made it possible to report multiple events using a phase version. A relatively naive solutions proposed by @hamersaw might be: • Have propeller keep a watch on k8s events. I assume the kube-client has this functionality. Store these in a local cache (with configurable size) and keyed on the object or Flyte task they are associated with. • When sending a TaskExecutionEvent we could lookup the k8s events and instead of a singular reason, return a list of reasons (probably update the name) containing all unreported k8s events (use some kind of lastSeen indicator - timestamp, revisionVersion, hash of message, etc). • Merge the k8s events into the ExecutionClosure. 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/flyte/tree/master|master>

by davidmirror-ops

<https://github.com/flyteorg/flyte/commit/4d7b656dae66a75da3480722c3d214ed8ea4f0d1|4d7b656d>

- [RFC] Config Override (#3553) flyteorg/flyte

#3553 [RFC] Config Override Pull request opened by ByronHsu Tracking issue #475 Describe your changes Add RFC Note to reviewers Need discussion on the UI part! flyteorg/flyte DCO: DCO ✅ 5 other checks have passed 5/6 successful checks

#3826 [Housekeeping] Add templates to flyte-core to handle auth Issue created by davidmirror-ops Motivation: Why do you think this is important? When using the

flyte-core

chart with

auth

enabled, even with the internal auth server, a user needs to manually: 1. Edit the

flyte-admin-secrets

secret and add the

oidc_client_secret

2. Edit the

flyte-admin-base-config

configmap to add the required information for OIDC 3. Rollout the deployments to make Flyte components aware of the changes If using an External auth server, more manual edits to the configmap have to be done. Goal: What should the final outcome look like, ideally? Similar to how

flyte-binary

works, whenever a user enables

auth

, they should be able to provide the parameters in the values file and then Helm templates should do the work to update the secret and configmap without user intervention. Describe alternatives you've considered None 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

#3827 [Core feature] Enable flyte-binary to be deployed without cluster-wide permissions Issue created by davidmirror-ops Motivation: Why do you think this is important? Mutliple users (like here and here) are struggling to deploy

flyte-binary

chart to K8s environments where they don't have cluster-wide permissions but are more or less constrained to what can be done on a single namespace. As a way to prepare Flyte for enterprise environments where potential attack surface is a concern and the principle of least privilege is observed, creating a path for single-namespace deployment of Flyte would be useful. Goal: What should the final outcome look like, ideally? Make he RBAC to be namespaced, flyte-binary/flytepropeller set to watch a single namespace, and namespace mapping for project/domains fixed to the single namespace Describe alternatives you've considered None 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

#3829 [Plugin] Flux Operator Issue created by vsoch Hi! 👋 I develop the Flux operator https://flux-framework.org/flux-operator/ which conceptually is like the MPI operator, but it brings up a Flux Framework cluster (that acts as a job) to run a scoped piece of work, akin the MPI operator. I'm interested in adding it as a plugin (and can also do the development work for it) but I wanted to check first about the order of operations. I had first cloned https://github.com/flyteorg/flyteplugins, and I started adding the operator under k8s until I noticed that the others (e.g., dask) had a DaskJob that is also defined under the flyteidl repository. So I think the correct order of operations (and what I want to check here) is: • Add the MiniClusterJob to https://github.com/flyteorg/flyteidl (and specificaily I'm interested in the purpose of these protos (example for dask) and what content to put there relative to the Flux Operator MiniCluster CRD) • Then add the MiniCluster plugin to https://github.com/flyteorg/flyteplugins using the above Are there any more pieces? Thanks for the help! I tried flyte out this week and really loved it - it already has support for several CRD I've been hoping to see in one place, so I'm eager to see support for our operator here as well. flyteorg/flyte

#1013 Flyte Getting started guide updated for new contributors Pull request opened by litmus-zhang I updated the getting started guide to ensure new contributors and users can get up to speed with flyte flyteorg/flytesnacks DCO: DCO ✅ 1 other check has passed 1/2 successful checks

#3830 Fix broken links Pull request opened by pingsutw Fix broken links flyteorg/flyte ✅ All checks have passed 2/2 successful checks

#1719 Set log-cli-level to error Pull request opened by pingsutw TL;DR Please replace this text with a description of what this PR accomplishes. 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 GitHub Actions: docs GitHub Actions: Docs Warnings ✅ 2 other checks have passed 2/4 successful checks

1 new commit pushed to

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

by pingsutw

<https://github.com/flyteorg/flytekit/commit/da21782caac8b182489f869f265342d201ed12b9|da21782c>

- Add requirements to imageSpec (#1698) flyteorg/flytekit

#3831 [BUG] undefined optional argument in a dynamic task is a `Promise`, should be `None` Issue created by alekpikl Describe the bug An empty

Optional[SomeType] = None

argument in a

dynamic

task is a

Promise

during execution. A reproducer:

from typing import Optional

from flytekit import dynamic, workflow


@dynamic
def my_task(opt: Optional[int] = None):
    print(opt)  # Promise(node:.opt)


@workflow
def workflow():
    my_task()

In

my_task,

opt

is a

Promise(node:.opt).

Works as expected locally but not in a cluster. Expected behavior The argument should be

None

during execution. 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/flytepropeller/tree/master|master>

by hamersaw

<https://github.com/flyteorg/flytepropeller/commit/357bf0906d7dc759b0ae36feb5ed6313116ebefd|357bf090>

- Update

flyteplugins

(#578) flyteorg/flytepropeller

#3832 [BUG] Pending kubernetes task pods of cancelled executions are not removed on workflow cancellation Issue created by victorchurikovcommonground Describe the bug I have a workflow that runs multiple @dynamics that call other @tasks, on cancellation of the workflow either from UI or from flytekit FlyteRemote.terminate(execution, reason), the pods that were pending due to being unschedulable remain after the workflow was cancelled. Pending pods remaining after cancellation is a problem because a kubernetes autoscaler (GKE's in this case) still periodically makes attempts to satisfy their scheduling requirements, and if autoscaling conditions are satisfied later, the pod may even trigger a scale up of additional nodes even when it is not desirable because the workflow is cancelled. Expected behavior Cancelling a workflow should clean up leftover pending pods, perhaps by deleting them Additional context to reproduce 1. Create a workflow with tasks that make unsatisfiable scheduling requests (such as high amounts of cpu/mem that is not available) 1.1 If not reproducible, have it call tasks from a @dynamic 2. Execute the workflow and wait for task pods to become Pending 3. Cancel the workflow either from UI or from FlyteRemote.terminate() 4. Observe that the pending pods are not removed and kubernetes still periodically attempts to satisfy their requests (can be seen with kubectl describe pod or kubectl events) Screenshots In this example some pods can be seen Pending 4 hours after their workflow has been cancelled: Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte

#1720 Carry over hash from literal maps in cache key computation Pull request opened by nicholasjng TL;DR Until now, the hash of a literal map is not carried over into the representative literal map entering the cache key computation, despite the code clearly stating so. This commit enables carrying hashes from `LiteralMap`s over by explicitly setting the hashes on the representer literal map. Also fixes a shadowing bug in the key-value loop over the literal map, which happened since the value argument and the input name were both

literal

. 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 (there aren't any I guess) Complete description This came up during internal tests, where it broke existing tests when I changed from a single

Literal

to a

LiteralMap

in a type transformer with an explicitly set hash value. Minimal reproducer:

# test.py
from flytekit import Literal
from flytekit.core.local_cache import _recursive_hash_placement
from flytekit.models.literals import LiteralMap, Scalar, Primitive

lit = Literal(
    map=LiteralMap(
        literals={
            "hello": Literal(scalar=Scalar(primitive=Primitive(string_value="hello"))),
        }
    ),
    hash="0xffff",
)

if __name__ == "__main__":
    print(lit)
# --> prints <FlyteLiteral map { literals { key: "hello" value { scalar { primitive { string_value: "hello" } } } } } hash: "0xffff">
    print(_recursive_hash_placement(lit))
# --> prints <FlyteLiteral map { literals { key: "hello" value { scalar { primitive { string_value: "hello" } } } } }>

This means that the

_recursive_hash_placement

function, which facilitates part of the hash key computation, silently scrubs hash values from input literal maps, which can cause involuntary cache hits if the values inside the map stay the same. I would be happy for a discussion - maybe the repro can go in as a unit test in a suitable location. Tracking Issue N/A Follow-up issue N/A flyteorg/flytekit DCO: DCO ✅ 1 other check has passed 1/2 successful checks

#3833 [BUG] pyflyte run fails when ContainerTask is executed locally Issue created by zeryx Describe the bug When using pyflyte run on a workflow that contains a ContainerTask, the ContainerTask and WF fails during tracing when attempting to run locally. When either passing

--remote

or registering a workflow with pyflyte register to a flyte cluster, no error is reported.

TypeError: Error encountered while executing 'proxy_registration_wf':                            
                                      Failed to convert outputs of task 'register' at position output:                               
                                      Python value cannot be None, expected <class 'str'>/<FlyteLiteral simple:                      
                                    STRING>                                                                                          
Failed with Unknown Exception <class 'TypeError'> Reason: Error encountered while executing 'proxy_registration_wf':
  Failed to convert outputs of task 'register' at position output:
  Python value cannot be None, expected <class 'str'>/<FlyteLiteral simple: STRING>
Error encountered while executing 'proxy_registration_wf':
  Failed to convert outputs of task 'register' at position output:
  Python value cannot be None, expected <class 'str'>/<FlyteLiteral simple: STRING>

Expected behavior either throw an error stating that ContainerTasks are not supported with local pyflyte run execution, or provide support for executing ContainerTasks locally. Additional context to reproduce https://gist.github.com/zeryx/b3d4cca7594de252a08ae8a02c2d5d6b create a WF (or dynamic task) that triggers a ContainerTask define the ContainerTask to have inputs and outputs execute an arbitrary step within the ContainerTask (not reading or writing from pipes) trigger the workflow with

pyflyte run

without

--remote

Screenshots No response Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte

#1014 fix formatting, add references Pull request opened by cosmicBboy flyteorg/flytesnacks GitHub Actions: Serialize & Register Flytesnacks workflow / Register example to sandbox GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/whylogs_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/type_system) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/sql_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/sagemaker_training_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/sagemaker_pytorch_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/ray_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/pima_diabetes) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/papermill_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/pandera_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/onnx_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/nlp_processing) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/modin_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/mnist_classifier) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/mlflow_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/kftensorflow_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/kfpytorch_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/kfmpi_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/k8s_spark_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/k8s_pod_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/k8s_dask_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/image_spec) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/house_price_prediction) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/greatexpectations_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/forecasting_sales) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/feast_integration) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/exploratory_data_analysis) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/duckdb_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/dolt_plugin) GitHub Actions: Serialize & Register Flytesnacks workflow / Serialize Example (examples/dbt_plugin) ✅ No checks have passed 0/30 successful checks

1 new commit pushed to

<https://github.com/flyteorg/flyte-conference-talks/tree/main|main>

by cosmicBboy

<https://github.com/flyteorg/flyte-conference-talks/commit/48ea364c963c36400812689911a8bfe1a73146c0|48ea364c>

- update setup requirements flyteorg/flyte-conference-talks

1 new commit pushed to

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

by cosmicBboy

<https://github.com/flyteorg/flytesnacks/commit/a49ba5177b72b24601522c42654b91a062f1554d|a49ba517>

- fix formatting, add references (#1014) flyteorg/flytesnacks

1 new commit pushed to

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

by wild-endeavor

<https://github.com/flyteorg/flytekit/commit/7550109d106d4c22689986f32be8d1d3d20d0ef7|7550109d>

- Memory reduction change [ipython] (#1716) flyteorg/flytekit

#3834 providing validation for specialized FlyteFormat types Issue created by zeryx Motivation: Why do you think this is important? This issue revolves around the fact that today, specialized filetypes within Flyte are not validated to actually conform to the requested type - just the file type metadata is provided to s3. This means I could store a png image as a JPEGImageFile object, which could end up adding a lot of confusion to end users who may expect JPEGImageFile types to be validated. Goal: What should the final outcome look like, ideally? Ideally, there should be a mechanism at runtime that validates that a particular file actually corresponds to the format requested. If I had a PDFFile type, I would expect to be able to ensure that the actual serialized file is a PDF type. Describe alternatives you've considered https://en.wikipedia.org/wiki/File_(command) ^ Previously used this in other projects to verify image format and filetype. Checking file extensions is also a potential mechanism for validation (albeit a much worse one) Propose: Link/Inline OR Additional context example of a wf that succeeds (when it shouldn't) https://gist.github.com/zeryx/31266bbe21d4dcfeca9f1b0e7dc3a883 Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte

#3835 fix links Pull request opened by cosmicBboy This PR fixes links that were broken as a result of flyteorg/flytesnacks#1011 flyteorg/flyte ✅ All checks have passed 6/6 successful checks

#583 [WIP] Flyte webhooks Pull request opened by pingsutw TL;DR Please replace this text with a description of what this PR accomplishes. 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#2317 Follow-up issue NA flyteorg/flyteadmin WIP: Title contains "WIP" ✅ 1 other check has passed 1/2 successful checks

#586 Fix usage of archive replacements Pull request opened by eapolinario TL;DR Produce archives using the recommended alternative for archives.replacements 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

archives.replacements

was deprecated and removed in the latest goreleaser version as per https://goreleaser.com/deprecations/#archivesreplacements. This PR follows the recommendation to use

name_template

to get the same effect. I removed the unused

{{ .Arm }}

block also. Tracking Issue _Remove the '_fixes_' keyword if there will be multiple PRs to fix the linked issue_ fixes https://github.com/flyteorg/flyte/issues/ Follow-up issue NA OR https://github.com/flyteorg/flyte/issues/ flyteorg/flytepropeller GitHub Actions: Goreleaser GitHub Actions: Build & Push Flytepropeller Image GitHub Actions: Bump Version ✅ 11 other checks have passed 11/14 successful checks

1 new commit pushed to

<https://github.com/flyteorg/flyte-conference-talks/tree/main|main>

by cosmicBboy

<https://github.com/flyteorg/flyte-conference-talks/commit/2d43f0df6b882054b9e4d98b025ff125684f738c|2d43f0df>

- deck url flyteorg/flyte-conference-talks

1 new commit pushed to

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

by cosmicBboy

<https://github.com/flyteorg/flyte/commit/37e99676dd5ef19bf2cd06842bfd175f59c58e39|37e99676>

- fix links (#3835) flyteorg/flyte

#3836 docs(flyte-binary): update plugins config Pull request opened by michaeltinsley Describe your changes Update the EKS configuration for the flyte-binary Helm chart. #3454 adds the bigquery plugin via agent, however without correct configuration this causes the agent to fail to become healthy. This PR updates the EKS example configs, and sets the plugins explicitly to disable the BigQuery plugin by default. 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 DCO: DCO ✅ 1 other check has passed 1/2 successful checks

#76 Bump grpcio from 1.27.2 to 1.53.0 in /flytetester Pull request opened by dependabot[bot] Bumps grpcio from 1.27.2 to 1.53.0. Release notes Sourced from grpcio's releases.

Release v1.53.0

This is release 1.53.0 (glockenspiel) of gRPC Core.

For gRPC documentation, see grpc.io. For previous releases, see Releases.

This release contains refinements, improvements, and bug fixes, with highlights listed below.

Core

• xDS: fix crash when removing the last endpoint from the last locality in weighted_target. (#32592)

• filter stack: pass peer name up via recv_initial_metadata batch. (#31933)

• [EventEngine] Add advice against blocking work in callbacks. (#32397)

• [http2] Dont drop connections on metadata limit exceeded. (#32309)

• xDS: reject aggregate cluster with empty cluster list. (#32238)

• Fix Python epoll1 Fork Support. (#32196)

• server: introduce ServerMetricRecorder API and move per-call reporting from a C++ interceptor to a C-core filter. (#32106)

• [EventEngine] Add invalid handle types to the public API. (#32202)

• [EventEngine] Refactoring the EventEngine Test Suite: Part 1. (#32127)

• xDS: fix WeightedClusters total weight handling. (#32134)

C++

• Update minimum MSVC version to 2019. (#32615)

• Use CMake variables for paths in pkg-config files. (#31671)

C#

• Grpc.Tools: Use x86 protoc binaries on arm64 Windows. (#32017)

Python

• Support python 3.11 on aarch64. (#32270)

• Include .pyi file. (#32268)

• De-experimentalize wait-for-ready. (#32143)

• De-experimentalize compression. (#32138)

Ruby

• [ruby]: add pre-compiled binaries for ruby 3.2; drop them for ruby 2.6. (#32089)

Release v1.53.0-pre2

This is a prerelease of gRPC Core 1.53.0 (glockenspiel).

For gRPC documentation, see grpc.io. For previous releases, see Releases.

... (truncated) Changelog _Sourced from grpcio's changelog._

gRPC Release Schedule

Below is the release schedule for gRPC Java, Go and Core and its dependent languages C++, C#, Objective-C, PHP, Python and Ruby.

Releases are scheduled every six weeks on Tuesdays on a best effort basis. In some unavoidable situations a release may be delayed or released early or a language may skip a release altogether and do the next release to catch up with other languages. See the past releases in the links above. A six-week cycle gives us a good balance between delivering new features/fixes quickly and keeping the release overhead low.

The gRPC release support policy can be found here.

Releases are cut from release branches. For Core and Java repos, the release branch is cut two weeks before the scheduled release date. For Go, the branch is cut just before the release. An RC (release candidate) is published for Core and its dependent languages just after the branch cut. This RC is later promoted to release version if no further changes are made to the release branch. We do our best to keep head of master branch stable at all times regardless of release schedule. Daily build packages from master branch for C#, PHP, Python, Ruby and Protoc plugins are published on packages.grpc.io. If you depend on gRPC in production we recommend to set up your CI system to test the RCs and, if possible, the daily builds.

Names of gRPC releases are here.

Commits • `358bfb5` Bump version to 1.53.0 (#32685) • `6e1ebe7` Backport: Ensure compatibility with the new custom kokoro win2019 image (#326... • `44a77f6` Backport 1.53: Update minimum MSVC version to 2019 (#32615) • `c11153c` backport to 1.53: xDS: fix crash when removing the last endpoint from the las... • `7c7712a` Bump version to 1.53.0-pre2. (#32545) • `a4017dc` backport to 1.53: [promises] Make Poll<T> its own type, not a variant<> (#32540) • `3f93c16` Fuzzer fix backport to v1.53 (#32511) • `5b244b2` Bump release version to 1.53.0-pre1 (#32428) • `6589340` Bump core version 202302161703 (#32416) • `d49e151` [backoff] Add random early detection classifier (#32354) • Additional commits viewable in compare view Dependabot compatibility score Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting

@dependabot rebase

. * * * Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: •

@dependabot rebase

will rebase this PR •

@dependabot recreate

will recreate this PR, overwriting any edits that have been made to it •

@dependabot merge

will merge this PR after your CI passes on it •

@dependabot squash and merge

will squash and merge this PR after your CI passes on it •

@dependabot cancel merge

will cancel a previously requested merge and block automerging •

@dependabot reopen

will reopen this PR if it is closed •

@dependabot close

will close this PR and stop Dependabot r… flyteorg/flytetools ✅ All checks have passed 2/2 successful checks

#584 Bump google.golang.org/grpc from 1.35.0 to 1.53.0 in /boilerplate/flyte/golang_support_tools Pull request opened by dependabot[bot] Bumps google.golang.org/grpc from 1.35.0 to 1.53.0. Release notes Sourced from google.golang.org/grpc's releases.

Release 1.53.0

API Changes

• balancer: support injection of per-call metadata from LB policies (#5853)

• resolver: remove deprecated field

resolver.Target.Endpoint

and replace with

resolver.Target.Endpoint()

(#5852)

• Special Thanks: `@​kylejb`

New Features

• xds/ringhash: introduce

GRPC_RING_HASH_CAP

environment variable to override the maximum ring size. (#5884)

• rls: propagate headers received in RLS response to backends (#5883)

Bug Fixes

• transport: drain client transport when streamID approaches MaxStreamID (#5889)

• server: after GracefulStop, ensure connections are closed when final RPC completes (#5968)

• server: fix a few issues where grpc server uses RST_STREAM for non-HTTP/2 errors (#5893)

• xdsclient: fix race which can happen when multiple load reporting calls are made at the same time. (#5927)

• rls: fix a data race involving the LRU cache (#5925)

• xds: fix panic involving double close of channel in xDS transport (#5959)

• gcp/observability: update method name validation (#5951)

Documentation

• credentials/oauth: mark

NewOauthAccess

as deprecated (#5882)

• Special Thanks: `@​buzzsurfr`

Release 1.52.3

Bug Fixes

• Fix user-agent version

Release 1.52.2

Bug Fixes

• xds: fix panic involving double close of channel in xDS transport (#5959)

Release 1.52.1

Bug Fixes

• grpclb: rename grpclbstate package back to state (#5963)

Release 1.52.0

New Features

• xdsclient: log node ID with verbosity INFO (#5860)

• ringhash: impose cap on

max_ring_size

to reduce possibility of OOMs (#5801)

Behavior Changes

... (truncated) Commits • `dba26e1` Change version to 1.53.0 (#5983) • `2a1e934` server: after GracefulStop, ensure connections are closed when final RPC comp... • `e2d69aa` tests: fix spelling of variable (#5966) • `a6376c9` xds/resolver: cleanup tests to use real xDS client 3/n (#5953) • `bf8fc46` xds/resolver: cleanup tests to use real xDS client 5/n (#5955) • `3930549` resolver: replace resolver.Target.Endpoint field with Endpoint() method (#5852) • `894816c` grpclb: rename

grpclbstate

package back to

state

(#5962) • `e5a0237` encoding: fix duplicate compressor names (#5958) • `4adb2a7` xds/resolver: cleanup tests to use real xDS client 2/n (#5952) • `52a8392` gcp/observability: update method name validation (#5951) • Additional commits viewable in compare view Dependabot compatibility score You can trigger a rebase of this PR by commenting

@dependabot rebase

. * * * Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: •

@dependabot rebase

will rebase this PR •

@dependabot recreate

will recreate this PR, overwriting any edits that have been made to it •

@dependabot merge

will merge this PR after your CI passes on it •

@dependabot squash and merge

will squash and merge this PR after your CI passes on it •

@dependabot cancel merge

will cancel a previously requested merge and block automerging •

@dependabot reopen

will reopen this PR if it is closed •

@dependabot close

will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually •

@dependabot ignore this major version

will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this minor version

will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this dependency

will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page.

Note > Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

flyteorg/flyteadmin GitHub Actions: Build & Push Flytescheduler Image GitHub Actions: Build & Push Flyteadmin Image GitHub Actions: Goreleaser GitHub Actions: Bump Version ✅ 8 other checks have passed 8/12 successful checks

#585 Bump google.golang.org/grpc from 1.46.0 to 1.53.0 Pull request opened by dependabot[bot] Bumps google.golang.org/grpc from 1.46.0 to 1.53.0. Release notes Sourced from google.golang.org/grpc's releases.

Release 1.53.0

API Changes

• balancer: support injection of per-call metadata from LB policies (#5853)

• resolver: remove deprecated field

resolver.Target.Endpoint

and replace with

resolver.Target.Endpoint()

(#5852)

• Special Thanks: `@​kylejb`

New Features

• xds/ringhash: introduce

GRPC_RING_HASH_CAP

environment variable to override the maximum ring size. (#5884)

• rls: propagate headers received in RLS response to backends (#5883)

Bug Fixes

• transport: drain client transport when streamID approaches MaxStreamID (#5889)

• server: after GracefulStop, ensure connections are closed when final RPC completes (#5968)

• server: fix a few issues where grpc server uses RST_STREAM for non-HTTP/2 errors (#5893)

• xdsclient: fix race which can happen when multiple load reporting calls are made at the same time. (#5927)

• rls: fix a data race involving the LRU cache (#5925)

• xds: fix panic involving double close of channel in xDS transport (#5959)

• gcp/observability: update method name validation (#5951)

Documentation

• credentials/oauth: mark

NewOauthAccess

as deprecated (#5882)

• Special Thanks: `@​buzzsurfr`

Release 1.52.3

Bug Fixes

• Fix user-agent version

Release 1.52.2

Bug Fixes

• xds: fix panic involving double close of channel in xDS transport (#5959)

Release 1.52.1

Bug Fixes

• grpclb: rename grpclbstate package back to state (#5963)

Release 1.52.0

New Features

• xdsclient: log node ID with verbosity INFO (#5860)

• ringhash: impose cap on

max_ring_size

to reduce possibility of OOMs (#5801)

Behavior Changes

... (truncated) Commits • `dba26e1` Change version to 1.53.0 (#5983) • `2a1e934` server: after GracefulStop, ensure connections are closed when final RPC comp... • `e2d69aa` tests: fix spelling of variable (#5966) • `a6376c9` xds/resolver: cleanup tests to use real xDS client 3/n (#5953) • `bf8fc46` xds/resolver: cleanup tests to use real xDS client 5/n (#5955) • `3930549` resolver: replace resolver.Target.Endpoint field with Endpoint() method (#5852) • `894816c` grpclb: rename

grpclbstate

package back to

state

(#5962) • `e5a0237` encoding: fix duplicate compressor names (#5958) • `4adb2a7` xds/resolver: cleanup tests to use real xDS client 2/n (#5952) • `52a8392` gcp/observability: update method name validation (#5951) • Additional commits viewable in compare view Dependabot compatibility score Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting

@dependabot rebase

. * * * Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: •

@dependabot rebase

will rebase this PR •

@dependabot recreate

will recreate this PR, overwriting any edits that have been made to it •

@dependabot merge

will merge this PR after your CI passes on it •

@dependabot squash and merge

will squash and merge this PR after your CI passes on it •

@dependabot cancel merge

will cancel a previously requested merge and block automerging •

@dependabot reopen

will reopen this PR if it is closed •

@dependabot close

will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually •

@dependabot ignore this major version

will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this minor version

will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this dependency

will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page. flyteorg/flyteadmin GitHub Actions: Build & Push Flytescheduler Image GitHub Actions: Build & Push Flyteadmin Image GitHub Actions: Goreleaser GitHub Actions: Bump Version GitHub Actions: End2End Test / End to End tests ✅ 9 other checks have passed 9/14 successful checks