Skip to content

Releases: flyteorg/flyte

Flyte v1.6.2 milestone release

31 May 16:43
7a0021a
Compare
Choose a tag to compare

Flyte v1.6.2 Patch Release

Changes

Admin - v1.1.104

Flyte v1.6.1 milestone release

22 May 22:12
5ab8cb8
Compare
Choose a tag to compare

Flyte v1.6.1 Patch Release

Changes

Admin - v1.1.100

Console - v1.8.2

Propeller - v1.1.90

Flyte v1.6.0 milestone release

12 May 22:33
d391691
Compare
Choose a tag to compare

Flyte v1.6.0 release

In this release we're announcing support for writing backend plugins in python. This is in experimental state, feedback
and bug reports are welcome!

Database migrations

This release contains a database migration that remediates an issue that we discovered with very old installations of Flyte.
For more details, please read the Flyte [https://github.com/flyteorg/flyte/releases/tag/v1.5.1](1.5.1 release notes).

Platform

As mentioned in the previous release, we are working to improve performance investigations. In this release we're announcing:

  1. Runtime metrics UI
  2. Profile time spent in a task via @timeit decorator
  3. Lazy loading of flytekit dependencies

flytekit

Lots of features shipped in 1.6, including:

  1. Prettified pyflyte run logs
  2. Simplified image builds via ImageSpec
  3. External backed plugins

For a full changelog, go to https://github.com/flyteorg/flytekit/releases/tag/v1.6.0.

Console

Admin

Propeller

New Contributors

Flyte v1.5.1 milestone release

11 May 22:32
cd3f29d
Compare
Choose a tag to compare

Flyte 1.5.1 Patch Release

This is a patch release that only contains one change - flyteorg/flyteadmin#560
which cherry-picks flyteorg/flyteadmin#554.

PR #554 adds a migration that remediates an issue that we discovered with very old installations of Flyte. Basically one of the tables node_executions has a self-referencing foreign key. The main id column of the table is a bigint whereas the self-foreign-key parent_id was an int. This was a rooted in an early version of gorm and should not affect most users. Out of an abundance of caution however, we are adding a migration to patch this issue in a manner that minimizes any locking.

To Deploy

When you deploy this release of Flyte, you should make sure that you have more than one pod for Admin running. (If you are running the flyte-binary helm chart, this patch release does not apply to you at all. All those deployments should already have the correct column type.) When the two new migrations that #554 added runs, the first one may take an extended period of time (hours). However, this is entirely non-blocking as long as there is another Admin instance available to serve traffic.

The second migration is locking, but even on very large tables, this migration was over in ~5 seconds, so you should not see any noticeable downtime whatsoever.

The migration will also check to see that your database falls into this category before running (ie, the parent_id and the id columns in node_executions are mismatched). You can also do check this yourself using psql. If this migration is not needed, the migration will simply mark itself as complete and be a no-op otherwise.

Flyte v1.6.0-b1 milestone release

09 May 03:25
941fa41
Compare
Choose a tag to compare
Pre-release

Flyte v1.6.0-b1

What's Changed

Console

Admin

Propeller

Flyte v1.5.0 milestone release

06 Apr 17:29
bc521da
Compare
Choose a tag to compare

Flyte 1.5 release

Platform

We're laying the foundation for an improved experience to help performance investigations. Stay tuned for more details!

We can now submit Ray jobs to separate clusters (other than the one flytepropeller is running). Thanks to flyteorg/flyteplugins#321.

Several bug fixes, including:

Database Migrations

One of the improvements planned requires us to clean up our database migrations. We have done so in this release so you should see a series of new migrations.
These should have zero impact if you are otherwise up-to-date on migrations (which is why they are all labeled noop) but please be aware that it will add a minute or so to the
init container/command that runs the migrations in the default Helm charts. Notably, because these should be a no-op, they also do not come with any rollback commands.
If you experience any issues, please let us know.

Flytekit

Python 3.11 is now officially supported.

Revamped Data subsystem

The data persistence layer was completely revamped. We now rely exclusively on fsspec to handle IO.

Most users will benefit from a more performant IO subsystem, in other words,
no change is needed in user code.

The data persistence layer has undergone a thorough overhaul. We now exclusively utilize fsspec for managing input and output operations.

For the majority of users, the improved IO subsystem provides enhanced performance, meaning that no modifications are required in their existing code.

This change opened the door for flytekit to rely on fsspec streaming capabilities. For example, let's say we want to stream a file, now we're able to do:

@task
def copy_file(ff: FlyteFile) -> FlyteFile:
    new_file = FlyteFile.new_remote_file(ff.remote_path)
    with ff.open("r", cache_type="simplecache", cache_options={}) as r:
        with new_file.open("w") as w:
            w.write(r.read())
    return new_file

This feature is marked as experimental. We'd love feedback on the API!

Limited support for partial tasks

We can use functools.partial to "freeze"
some task arguments. Let's take a look at an example where we partially fix the parameter for a task:

@task
def t1(a: int, b: str) -> str:
    return f"{a} -> {b}"
    
t1_fixed_b = functools.partial(t1, b="hello")

@workflow
def wf(a: int) -> str:
    return t1_fixed_b(a=a)

Notice how calls to t1_fixed_b do not need to specify the b parameter.

This also works for MapTasks in a limited capacity. For example:

from flytekit import task, workflow, partial, map_task

@task
def t1(x: int, y: float) -> float:
    return x + y

@workflow
def wf(y: List[float]):
   partial_t1 = partial(t1, x=5)
   return map_task(partial_t1)(y=y)

We are currently seeking feedback on this feature, and as a result, it is labeled as experimental for now.

Also worth mentioning that fixing parameters of type list is not currently supported. For example, if we try to register this workflow:

from functools import partial
from typing import List
from flytekit import task, workflow, map_task

@task
def t(a: int, xs: List[int]) -> str:
    return f"{a} {xs}"

@workflow
def wf():
    partial_t = partial(t, xs=[1, 2, 3])
    map_task(partial_t)(a=[1, 2])

We're going to see this error:

❯ pyflyte run workflows/example.py wf
Failed with Unknown Exception <class 'ValueError'> Reason: Map tasks do not support partial tasks with lists as inputs.
Map tasks do not support partial tasks with lists as inputs.

Flyteconsole

Multiple bug fixes around waiting for external inputs.
Better support for dataclasses in the launch form.

Flyte v1.5.0-a0 milestone release

31 Mar 21:47
08f6959
Compare
Choose a tag to compare
Pre-release

Flyte v1.5.0-a0 Changelog

  • This is an alpha release to help test changes internally before the official release. *

Flyte v1.4.3 milestone release

22 Mar 19:07
7479b56
Compare
Choose a tag to compare

Flyte 1.4.3 release

This patch release pulls in the compiler changes necessary to compile gate nodes and the fix for StructuredDataset in flyteorg/flyteadmin#541.

Flyte v1.4.2 milestone release

17 Mar 19:56
9bef5ff
Compare
Choose a tag to compare

Flyte 1.4.2 release

This patch release pulls in flyteorg/flyteconsole#721

Flyte v1.4.1 milestone release

15 Mar 22:18
c3bdaa4
Compare
Choose a tag to compare