Release - v1.0.44 New release published by flyte-bot Changelog • 18a594e persisting k8s plugin phase, version, and reason (#331) flyteorg/flyteplugins

#3542 [BUG] Flyteconsole dynamic nodes don't update phase in execution views Issue created by jsonporter Describe the bug There is a bug where dynamic executions in the node execution view aren't updating their phase but the correct phases are shown on refresh. This bug was observed in all three views (list, graph and timeline) Expected behavior The phase of dynamic nodes should update without needing to refresh 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

#540 persisting k8s plugin state between evaluations Pull request opened by hamersaw TL;DR Persisting k8s plugin state by embedding it in the overall state stored for all k8s plugins. The exporting the

PluginStateReader

function through the

PluginContext

so that k8s plugin writers can retrieve plugin state the same way they do in other plugins, just that persistend (ie.

PluginStateWriter

) is performed underneath. 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#3440 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

#3543 [BUG] Flyteconsole: Validation causes infinite loop when trying to delete existing value Issue created by jsonporter Describe the bug When re-launching a workflow if the a user tries to delete a value from a text input the browser freezes. Steps to repo: • find a workflow with launch plan that has a text input (eg,

flytesnacks/development/human_in_the_loop.wf_dy

) • relaunch a previous execution • In the launch form, delete the text value (note: the bug only happens when a user hits backspace/delete; simply highlighting and over-typing a new value seems to work) Expected behavior Users should be able to delete a previous value and the validation message should appear... but the browser should not freeze. 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

#734 chore: allow custom subnav Pull request opened by ursucarina TL;DR Allows for passing custom subnavs through settings 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/flyteconsole GitHub Actions: Build & Push FlyteConsole Image GitHub Actions: Get Release Tag GitHub Actions: Generate Release ✅ 6 other checks have passed 6/9 successful checks

1 new commit pushed to

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

by jsonporter

<https://github.com/flyteorg/flyteconsole/commit/6ebd69fc6af1521c579c402fd43074fd663568cf|6ebd69fc>

- Add REJECT support for ApprovedCondition for GateNodes (#733) flyteorg/flyteconsole

#3346 [UI Feature] Add support for ApprovedCondition for GateNodes Issue created by cosmicBboy Motivation: Why do you think this is important? Signal UX needs to add support for a third type of gate node -

ApproveCondition

. ApprovedCondition only accepts

true

(boolean) as an input and should be presented to the user as displaying the incoming input and the simply allowing them to click on 'resume' in the Signal Form. Currently, these nodes (correctly) show the incoming inputs but the resume button is greyed out. Note: the shape of ApprovedCondition gate nodes is a little different in the

CompiledWorkflowClosure

-- look for

gateNode

and

approve

. Here is an example from core.control_flow.human_in_the_loop.mainwf

// Example of ApprovedCondition
{
    "gateNode": {
        "approve": {
            "signalId": "approvalfory"
        }
    }
}

IDL: Link to ApprovedCondition in IDL Goal: What should the final outcome look like, ideally? Acceptance Criteria: • Renders incoming inputs (this currently works just make sure the fix doesn't break it) • Allows user to click "resume" (this is currently greyed out) • Sends

true

as value Propose: Link/Inline OR Additional context This was ported over from this other board: unionai/cloud#1518 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/flytekit/tree/master|master>

by eapolinario

<https://github.com/flyteorg/flytekit/commit/28ce9396af2d28a06c45d889372645241afa021f|28ce9396>

- Device auth flow / Headless auth (#1552) flyteorg/flytekit

#977 Add reference launch plan example Pull request opened by samhita-alla This PR documents reference launch plan. flyteorg/flytesnacks GitHub Actions: Mark github pre-release as Release GitHub Actions: Publish artifacts to github release GitHub Actions: Create Prerelease GitHub Actions: Bump Version ✅ 26 other checks have passed 26/30 successful checks

#3544 [Housekeeping] Remove barrier transitions from FlytePropeller Issue created by hamersaw Describe the issue Currently, FlytePropeller manages plugin execution by processing a sequence of transitions that are either ephemeral or barrier. The barrier types are meant to ensure that the associated transition is reported before moving to another plugin transition. However, these transitions are stored in an in-memory cache and are therefore lost between restarts. So, they are essentially a very good best effort. It is not clear that these are useful and only result in additional overhead and complexity. What if we do not do this? The current situations results in a minimal amount of unnecessary overhead for every execution, inflated memory costs in the barrier cache, and useless complexity in the codebase. Related component(s) No response Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte

#336 Deprecated TransitionTypeBarrier Pull request opened by hamersaw TL;DR This PR deprecates

TransitionTypeBarrier

in support of removing support for

BarrierTicks

in FlytePropeller. 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#3544 Follow-up issue NA flyteorg/flyteplugins Codecov: 62.65% (-0.10%) compared to 60d345d Codecov: 25.00% of diff hit (target 62.75%) ✅ 4 other checks have passed 4/6 successful checks

#545 Remove BarrierTick Pull request opened by hamersaw TL;DR This PR removes support for Barrier type transitions. It is not clear they are useful and only result in additional overhead and complexity. 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#3544 Follow-up issue NA flyteorg/flytepropeller GitHub Actions: Build & Push Flytepropeller Image GitHub Actions: Goreleaser GitHub Actions: Bump Version ✅ 11 other checks have passed 11/14 successful checks

1 new commit pushed to

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

by pingsutw

<https://github.com/flyteorg/flytekit/commit/db7d1eb480cea24504d94419981859bfc9ef6c62|db7d1eb4>

- support python 3.11 (#1557) flyteorg/flytekit

#3312 [Core feature] Support Python 3.11 Issue created by cosmicBboy Motivation: Why do you think this is important? Currently flytekit does not support python 3.11 for many reasons, the mains ones being that: 1. upstream dependencies in the flytekit dev environment do not support 3.11 currently, such as

tensorflow

and others don't support 3.11 2. certain parts of the the flytekit codebase (such as the parts that use dataclasses) need to be updated to support 3.11 Python 3.7 will be EOL'd on June 2023, which will ease the transition to 3.11 because we can unpin certain restrictions. Goal: What should the final outcome look like, ideally? A user should be able to install and use flytekit on python 3.11 Describe alternatives you've considered NA 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

#3545 [Core feature] Allow flyte-binary to specify SeedProjects Issue created by ossareh Motivation: Why do you think this is important? I'd like to be able to set adminServer.SeedProjects via the flyte-binary helm chart values.yaml so that I can make our flyte installation more declarative. This allows a separation of concerns so that a system operator (me) can create k8s resources (namespaces, etc) and flyte resources (project/domain) in one configuration file which is under SCM. Goal: What should the final outcome look like, ideally? A user of the flyte-binary helm chart should be able to set

configuration.admin.seedProjects

to a list of project names and (default value = ["flytesnacks"]) Describe alternatives you've considered 1. Creating a

flyte-operator

which knows how to read a CRD of desired flyte projects 2. Hooking flytectl into our pulumi powered k8s management The first option is.. just a lot of work! The second option is far less work, viable and a completely valid path forward. After discussing with jeev and Yee it seemed both thought the proposed solution is acceptable. Propose: Link/Inline OR Additional context Discussed here: https://flyte-org.slack.com/archives/C01P3B761A6/p1679937303586009 I'll go ahead and create a PR for it in the coming days. Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte

#1566 url encode secret in client credentials flow Pull request opened by wild-endeavor TL;DR With url unsafe characters in the secret, we were getting errors like

The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. The client secret in the HTTP authorization header could not be decoded from 'application/x-www-form-urlencoded'.

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 url encode flyteorg/flytekit Codecov: 50.00% of diff hit (target 69.66%) ✅ 29 other checks have passed 29/30 successful checks

#3546 [BUG] Start controller-runtime manager in single binary even if webhook is disabled Issue created by hamersaw Describe the bug Currently the single binary only starts the controller-runtime manager if the propeller webhook is enabled. This means in the case where webhook is disabled propeller is unable to be notified of k8s resource updates and in turn has much worse performance in workflow evaluations because it only evaluates workflows using the reeval duration. Expected behavior The controller-runtime manager should be started in single binary even if the propeller webhook is disabled. Additional context to reproduce Disable the propeller webhook in single binary using the

disableWebhook

configuration option and start single binary. Screenshots No response Are you sure this issue hasn't been raised already? ☑︎ Yes Have you read the Code of Conduct? ☑︎ Yes flyteorg/flyte

#546 Moved controller-runtime start out of webhook Run function Pull request opened by hamersaw TL;DR This PR moves starting the controller-runtime manager outside of the webhook

Run

function. This is useful to ensure the controller-runtime manager starts in single binary even if the webhook is disabled. 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#3546 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

1 new commit pushed to

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

by eapolinario

<https://github.com/flyteorg/flytekit/commit/dd7fbe90ed5e9566e9b19d0e8b8bb8011770d835|dd7fbe90>

- url encode secret in client credentials flow (#1566) flyteorg/flytekit

1 new commit pushed to

<https://github.com/flyteorg/flytekit-python-template/tree/main|main>

by zeryx

<https://github.com/flyteorg/flytekit-python-template/commit/30606aacce4a30d0dc2506923be3bb17aecd8f45|30606aac>

- MNIST Pytorch Training Example (#22) flyteorg/flytekit-python-template

#735 [WIP] Add support fetching description entity Pull request opened by pingsutw TL;DR • fetch / list description entity • Add short description to SearchableTaskNameList • Add short description to SearchableWorkflowNameList • Add long description and source link to EntityDetails 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 NA Follow-up issue NA flyteorg/flyteconsole GitHub Actions: Build Flyteconsole Image / Push to Github Registry GitHub Actions: lint_project GitHub Actions: unit_tests_with_coverage GitHub Actions: extract_branch WIP: Title contains "WIP" ✅ 1 other check has passed 1/6 successful checks

#337 Set PrimaryContainerKey annotation by default Pull request opened by hamersaw TL;DR Setting the

PrimaryContainerKey

annotation by default so that (1)

Pods

may be marked as completed immediately after the container completes, rather than waiting for the

Pod

to be marked as completed as well and (2) users can inject sidecars outside of Flyte that will not halt the task from being marked completed. 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 NA Follow-up issue NA flyteorg/flyteplugins ✅ All checks have passed 6/6 successful checks

#3548 Update troubleshooting guide Pull request opened by davidmirror-ops Tracking issue Addresses #3340 Describe your changes Taking a bit of a different direction. Instead of creating a new section and moving the Troubleshooting guide contents, I'm updating that guide (which was largely out to date) and the resulting file could be relocated closer to the User Guide (now sitting under Community) 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 2/2 successful checks

1 new commit pushed to

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

by katrogan

<https://github.com/flyteorg/flyteidl/commit/bb5d4cd8c6ceebbd386137348fbbb2765c21370e|bb5d4cd8>

- Remove misleading token refresh logic from client credentials token source provider (#383) flyteorg/flyteidl

Release - v1.3.15 New release published by flyte-bot Changelog • bb5d4cd Remove misleading token refresh logic from client credentials token source provider (#383) flyteorg/flyteidl

#3549 [BUG] Flyte's internal logger logs as error before user code is run Issue created by ggydush Describe the bug When running Flyte on GCP, severity is marked as ERROR for all logs before user code is run. In my user code, I have something like the following that correctly marks severity:

class CustomJsonFormatter(jsonlogger.JsonFormatter):
    def add_fields(
        self, log_record: dict, record: logging.LogRecord, message_dict: dict
    ) -> None:
        super().add_fields(log_record, record, message_dict)
        log_record["severity"] = record.levelname

This works after user code is loaded, but all logs that are output before user code is run are still formatted incorrectly (see screenshot). Expected behavior Flyte's internal logs set severity to level that matches log record. 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/flytekit/tree/master|master>

by pingsutw

<https://github.com/flyteorg/flytekit/commit/12be8d871bb68d6d1dd6adc57288ab9b544e5536|12be8d87>

- Python run multiple files (#1559) flyteorg/flytekit

#3550 [BUG] Overwrite cached outputs flag doesn't work for reference launchplans Issue created by yubofredwang Describe the bug When I trigger a workflow with overwrite cached outputs flag, the reference launchplans does not respect that flag. The tasks in the reference workflow still read cache from previous executions. Expected behavior When overwrite cached outputs flag is enabled, the reference launchplans that triggered as sub-workflows should also overwrite the cache. If this is by design to have reference workflow to not respect the workflow, we should at least provide another flag/config to allow user to overwrite cache. Additional context to reproduce Create a workflow with reference workflow, enable caching on tasks and run with the overwrite cached outputs flag enabled. Code Example: File1

@task(
   cache=True,
   cache_version="1.0.0",
)
def fds_importer_parameter_serialization(a: str) -> str:
       return "hello" + a

@workflow
def fds_importer(a: str):
    fds_importer_parameter_serialization(a)

File2

@reference_launch_plan
def fds_importer(a: str):
    ...

@workflow
def my_workflow(a: str):
    fds_importer(a)

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

#220 Add JacksonSdkLiteralType Pull request opened by narape TL;DR Add a new implementation for SdkLiteralType: JacksonSdkLiteralType is able to take bean-like classes as literal types 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 We don't support arbitrary AutoValues as SdkLiteralTypes, but this PR fixes this for Java. Now Bean-like classes (Autovalues, JacksonBinding annotated classes, and the ones that follow the Java Bean spec) can be literal types. These bean objects will be translated to SDK Structs. Tracking Issue NA Follow-up issue We need to support the same for Scala flyteorg/flytekit-java ✅ All checks have passed 3/3 successful checks

1 new commit pushed to

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

by github-actions[bot]

<https://github.com/flyteorg/flytekit-java/commit/d8eaf53f4981efe58c1b7ba4a4c0860554c5711c|d8eaf53f>

- [maven-release-plugin] prepare release 0.4.14 flyteorg/flytekit-java