Skip to content

Releases: opst/knitfab

v1.6.1

03 Mar 07:43
c7694cc

Choose a tag to compare

  • Date: 2025-03-03

v1.6.1 is minor bugfix release.

Bugfix

Web-Console: Lineage Graph: Run-to-Log edges are visible

At v1.6.0, Edges in Lineage Graph was not visible dependeing on a case.

We have fixed it.

Upgrade Path

Knitfab System

Download the installer, and run

installer.sh --install

in the directory where you have installed Knitfab.

CLI knit

Download from assets of this release.

v1.6.1-beta

28 Feb 02:45
bb80a4a

Choose a tag to compare

v1.6.1-beta Pre-release
Pre-release

v1.6.1-beta

  • Date: 2025-02-28

v1.6.1 is minor bugfix release.

Bugfix

Web-Console: Lineage Graph: Run-to-Log edges are visible

At v1.6.0, Edges in Lineage Graph was not visible dependeing on a case.

We have fixed it.

How to Try

Knitfab System

Download the installer from branch develop/v1.6.1, and run

BRANCH=develop/v1.6.1 CHART_VERSION=v1.6.1-beta installer.sh --install

in the directory where you have installed Knitfab.

As mentioned above, you may need to renew & replace TLS certificates to access the Web Console.

CLI knit

Download from assets of this release.

What's Changed

Full Changelog: v1.6.0...v1.6.1-beta

v1.6.0

26 Feb 04:42
dd1f544

Choose a tag to compare

  • Date: 2025-02-26

v1.6.0 introduces a new feature: Web Console!

Important Changes

Web Console

Knitfab frontend server, also known as WebAPI server, publishes Knitfab Web Console on its root (https://<DOMAIN or HOST>:<PORT>/).
You can access Web Console with your web browser (we tested with Google Chrome).

The Web Console has:

  • "Data" tab: list and filter Data in your Knitfab
  • "Plan" tab: list and filter Plans in your Knitfab
  • "Run" tab: list and filter Runs in your Knitfab

Each item in the lists -- Data, Plan and Run --, has a button that shows a graph.
For Data and Run, it opens Lineage Graph (similar to knit data lineage) related to the Data or Run.
For Plan, it opens Plan Graph (similar to knit plan graph) related to the Plan.

Note

For Knitfab admins who have installed Knitfab with installer-generated TLS certificates:

For your users to access the Web Console, you need to renew & replace TLS certificates.
Follow the next section.

And, these TLS certificates are not authorized with any publicly trusted CA.
Your users may see a browser warning page the first time they access it.

Installer: Renew TLS certificates

With this release, our Installer now supports renewing TLS certificates.

Upgrade the Installer with

curl -LO https://raw.githubusercontent.com/opst/knitfab/refs/heads/develop/v1.6.0/installer/installer.sh
chmod +x ./installer.sh

in the directory where you have run installer Knitfab.

To renew and update certifications, follow admin-guide.

Bug Fix on Helm Chart: External RDB mode works.

knitfab-install-settings/values/knit-db-postgres.yaml has had an external parameter, but it did not work.

With this release, the parameter is effective. You can use PostgreSQL server that you provisioned for Knitfab.
This may help deploy Knitfab on cloud platforms and use managed RDBs.

For details of configurations, see the file generated by ./installer.sh --prepare (before that, backup your install configurations).

Other Changes

  • Golang used to build is upgraded to 1.24.0.
  • Kubernetes Client library "k8s.io/client-go" is upgraded to v0.32.0.
    • This release is tested with Kubernetes v1.32.
    • This may affect users who use al older version of Kubernetes.

License

Knitfab v1.6.0 is released under BSL 1.1, as written in the LICENSE file.

CHANGE DATE for v1.6.x is 2029-2-26.

Previous releases, v1.5.x or brefore, are not changed in their CHANGE DATE.

Upgrade Path

This release has breaking change, so upgrade both Knitfab system and CLI.

Knitfab System

Download the installer, and run

installer.sh --install

in the directory where you have installed Knitfab.

CLI knit

Download from assets of this release.

What's Changed

Full Changelog: v1.5.1...v1.6.0

v1.6.0-beta

21 Feb 09:15
30a14d8

Choose a tag to compare

v1.6.0-beta Pre-release
Pre-release
  • Date: 2025-02-21

v1.6.0-beta introduces a new feature: Web Console!

Important Changes

Web Console

Knitfab frontend server, also known as WebAPI server, publishes Knitfab Web Console on its root (https://<DOMAIN or HOST>:<PORT>/).
You can access Web Console with your web browser (we tested with Google Chrome).

The Web Console has:

  • "Data" tab: list and filter Data in your Knitfab
  • "Plan" tab: list and filter Plans in your Knitfab
  • "Run" tab: list and filter Runs in your Knitfab

Each item in the lists -- Data, Plan and Run --, has a button that shows a graph.
For Data and Run, it opens Lineage Graph (similar to knit data lineage) related to the Data or Run.
For Plan, it opens Plan Graph (similar to knit plan graph) related to the Plan.

Note

For Knitfab admins who have installed Knitfab with installer-generated TLS certificates:

For your users to access the Web Console, you need to renew & replace TLS certificates.
Follow the next section.

And, these TLS certificates are not authorized with any publicly trusted CA.
Your users may see a browser warning page the first time they access it.

Installer: Renew TLS certificates

With this release, our Installer now supports renewing TLS certificates.

Upgrade the Installer with

curl -LO https://raw.githubusercontent.com/opst/knitfab/refs/heads/develop/v1.6.0/installer/installer.sh
chmod +x ./installer.sh

in the directory where you have run installer Knitfab.

To renew and update certifications, follow admin-guide.

Bug Fix on Helm Chart: External RDB mode works.

knitfab-install-settings/values/knit-db-postgres.yaml has had an external parameter, but it did not work.

With this release, the parameter is effective. You can use PostgreSQL server that you provisioned for Knitfab.
This may help deploy Knitfab on cloud platforms and use managed RDBs.

For details of configurations, see the file generated by ./installer.sh --prepare (before that, backup your install configurations).

Other Changes

  • Golang used to build is upgraded to 1.24.0.
  • Kubernetes Client library "k8s.io/client-go" is upgraded to v0.32.0.
    • This release is tested with Kubernetes v1.32.
    • This may affect users who use al older version of Kubernetes.

How to Try

Knitfab System

Download the installer from branch develop/v1.6.0, and run

BRANCH=develop/v1.6.0 CHART_VERSION=v1.6.0-beta installer.sh --install

in the directory where you have installed Knitfab.

As mentioned above, you may need to renew & replace TLS certificates to access the Web Console.

CLI knit

Download from assets of this release.

What's Changed

Full Changelog: v1.5.1...v1.6.0-beta

v1.5.1

23 Dec 01:39
3af4a7a

Choose a tag to compare

  • Date: 2024-12-23

The v1.5.1 introduces the following updates:

  • Security Update
  • Bug Fixes

Important Changes

Security Update

Knitfab depends on echo,
and echo releases v4.13.3 addressing https://pkg.go.dev/vuln/GO-2024-3321 / https://www.cve.org/CVERecord?id=CVE-2024-45337 and https://pkg.go.dev/vuln/GO-2024-3333 / https://www.cve.org/CVERecord?id=CVE-2024-45338.

We upgraded echo.

Bug Fixes

knit plan template contained typo

Plan Definition file template generated from knit plan template contained typo.

The key resources was mistakenly written as resouce (missing the r).

This issue has been fixed.

knit plan find: There are cases in which --image flag did not work

The --image flag of the knit plan find command, which filters results based on the image of Plans, did not work correctly in some cases.

When an image with a port (e.g., example.com:5000/image:1.0) was provided, both the command and the Knitfab server (knitd) incorrectly parsed the image name as example.com with the tag 5000/image:1.0. As a result, no plans matching the specified image could be found.

This issue has been fixed.

Note: knit plan apply was unaffected, and registered Plans retained the correct image names and tags.

Upgrade Path

This release has breaking change, so upgrade both Knitfab system and CLI.

Knitfab System

Download the installer, and run

installer.sh --install

in the directory where you have installed Knitfab.

CLI knit

Download from assets of this release.

What's Changed

Full Changelog: v1.5.0...v1.5.1

v1.5.1-beta

20 Dec 05:16
9817deb

Choose a tag to compare

v1.5.1-beta Pre-release
Pre-release
  • Date: 2024-12-20

The v1.5.1-beta introduces the following updates:

  • Security Update
  • Bug Fixes

Important Changes

Security Update

Knitfab depends on echo,
and echo releases v4.13.3 addressing https://pkg.go.dev/vuln/GO-2024-3321 / https://www.cve.org/CVERecord?id=CVE-2024-45337 and https://pkg.go.dev/vuln/GO-2024-3333 / https://www.cve.org/CVERecord?id=CVE-2024-45338.

We upgraded echo.

Bug Fixes

knit plan template contained typo

Plan Definition file template generated from knit plan template contained typo.

The key resources was mistakenly written as resouce (missing the r).

This issue has been fixed.

knit plan find: There are cases in which --image flag did not work

The --image flag of the knit plan find command, which filters results based on the image of Plans, did not work correctly in some cases.

When an image with a port (e.g., example.com:5000/image:1.0) was provided, both the command and the Knitfab server (knitd) incorrectly parsed the image name as example.com with the tag 5000/image:1.0. As a result, no plans matching the specified image could be found.

This issue has been fixed.

Note: knit plan apply was unaffected, and registered Plans retained the correct image names and tags.

How to try

This release containing breaking changes, so please be sure to update both the Knitfab system AND CLI to try.

Knitfab System

Download the installer from branch develop/v1.5.0, and run

BRANCH=develop/v1.5.1 CHART_VERSION=v1.5.1-beta installer.sh --install

in the directory where you have installed Knitfab.

CLI knit

Download from assets of this release.

What's Changed

Full Changelog: v1.5.0...v1.5.1-beta

v1.5.0

20 Nov 02:18
55d1a4e

Choose a tag to compare

  • Date: 2024-11-20

The v1.5.0 release includes

  • knit plan show and knit plan find display direct upstreams/downstreams of each Plan
  • New command knit plan graph
  • Fix ambiguity of Data's upstream (breaking change)
  • Fix case inconsistency in JSON (breaking change)

Important Changes

knit plan showand knit plan find display direct upstreams/downstreams of each Plan

These commands show upstream/downstream neighboring Plans of a Plan. As shown below:

{
    "planId": ...
    ...
    "inputs": [
        {
            "path": "/in/1",
            "tags": [ ... ],
            "upstreams": [  // NEW!
              {
                  "plan": {
                      "planId": "...",
                      "image": "...",
                      "entrypoint": [ ... ],
                      "args": [ ... ],
                      "annotations": [ ... ]
                  },
                  "mountpoint": {  // this upstream is a normal output.
                      "path": "/out/1",
                      "tags": [ ... ]
                  }
              },
              {
                  "plan": {
                      "planId": "...",
                      "image": "...",
                      "entrypoint": [ ... ],
                      "args": [ ... ],
                      "annotations": [ ... ]
                  },
                  "log": {  // this upstream is a log.
                      "tags": [ ... ]
                  }
              },
            ]
        }
    ],
    "outputs": [
        {
            "path": "/out/1",
            "tags": [ ... ],
            "downstreams": [  // NEW!
                {
                    "plan": {
                        "planId": "...",
                        "image": "...",
                        "entrypoint": [ ... ],
                        "args": [ ... ],
                        "annotations": [ ... ]
                    },
                    "mountpoint": {
                        "path": "/in/2",
                        "tags": [ ... ]
                    }
                },
            ]
        }
    ],
    ...
}

Upstreams of a Plan Input are Plan Outputs or a Logs with matching Tags. If an Output (or Log) which has all Tags of the Input of another Plan, the Output is considered as Upstream of the Input. In other words, when Output or Log of a Plan A generates Data which can be assigned to an Input of Plan B, the Output/Log is upstream of the Input.

knit plan graph

The new command knit plan graph generates Plan Graph, which is an overview of your Plans, in dot format.

knit plan graph traverse Plans upstream and/or downstream Plans recursively and visualize the "pipeline" made by Plans.

See knit plan graph --help for more details.

Fix ambiguity of Data's upstream (breaking change)

Before this change, "upstream" of Data had not distinguished normal outputs and logs.
If the upstream of Data is a log, knit data find tells you the upstream has "path" (as /log).
However, the expression is identical to a that of normal output with the path /log, so with only knit data find, we could not know the upstream of Data is whether output or log.

By now, knit data find tells explicitly the upstream of Data is output or is log.

To do that, breaking changes are introduced. In JSON format of Data, "path" and "tags" are moved to a new field "mountpoint" (for normal outputs) or "log" (for log) .

{
    "knitId": "...",
    "tags": [ ... ],
    "upstream": {
        "mountpoint": {  // NEW!
            "path": "/upload",
            "tags": []
        },
        "run": {
            "runId": " ... ",
            "status": "done",
            "updatedAt": "2024-11-18T04:25:32.076+00:00",
            "plan": { ... }
        }
    },
    "downstreams": [
        {
            "mountpoint": {  // NEW!
                "path": "/in/dataset",
                "tags": [
                    "mode:training",
                    "project:first-knitfab",
                    "type:dataset"
                ]
            },
            "run": {
                "runId": "b7ed ... ",
                "status": "running",
                "updatedAt": "2024-11-18T04:44:06.008+00:00",
                "plan": { ... }
            }
        }
    ],
    "nomination": [ ... ]
}
{
    "knitId": "de17825d-16f3-4a5d-b3cb-16ef95379c0c",
    "tags": [
        "knit#id:de17825d-16f3-4a5d-b3cb-16ef95379c0c",
        "knit#timestamp:2024-11-18T05:12:32.075+00:00",
        "project:first-knitfab",
        "type:log"
    ],
    "upstream": {
        "log": {  // NEW!
            "tags": [
                "project:first-knitfab",
                "type:log"
            ]
        },
        "run": {
            "runId": "b7ed106b-cb49-4671-8979-4e85e249f15c",
            "status": "done",
            "updatedAt": "2024-11-18T05:12:32.075+00:00",
            "exit": {
                "code": 0,
                "message": ""
            },
            "plan": {
                "planId": "5770077f-e7a2-4b0f-8e8e-4d73d4b14144",
                "image": "localhost:30503/knitfab-first-train:v1.0",
                "entrypoint": [
                    "python",
                    "-u",
                    "train.py"
                ],
                "args": [
                    "--dataset",
                    "/in/dataset",
                    "--save-to",
                    "/out/model"
                ]
            }
        }
    },
    "downstreams": [],
    "nomination": []
}

Data with an "upstream" containing "mountpoint" represents a normal output, while one containing "log" represents a log.

Fix case inconsistency in JSON (breaking change)

Plan had log.Tag field. Differently than other fields, the first letter of the filed name is capitalized.

This inconcistency is not intended, so it has been fixed to log.tag.

{
    "planId": " ... ",
    "image": " ... ",
    // ...
    "log": {
        "tags": [  // renamed from "Tags".
            "project:first-knitfab",
            "type:log"
        ],
        "downstreams": []
    },
    // ...
}

License

Knitfab v1.5.0 is released under BSL 1.1, as written in the LICENSE file.

CHANGE DATE for v1.5.x is 2028-11-20.

Previous releases, v1.4.x or brefore, are not changed in their CHANGE DATE.

Upgrade Path

This release has breaking change, so upgrade both Knitfab system and CLI.

Knitfab System

Download the installer, and run

installer.sh --install

in the directory where you have installed Knitfab.

CLI knit

Download from assets of this release.

What's Changed

Full Changelog: v1.4.0...v1.5.0

v1.5.0-beta

18 Nov 08:18
9ca8b9a

Choose a tag to compare

v1.5.0-beta Pre-release
Pre-release
  • Date: 2024-11-18

The v1.5.0-beta release includes

  • knit plan show and knit plan find display direct upstreams/downstreams of each Plan
  • New command knit plan graph
  • Fix ambiguity of Data's upstream (breaking change)
  • Fix case inconsistency in JSON (breaking change)

Important Changes

knit plan showand knit plan find display direct upstreams/downstreams of each Plan

These commands show upstream/downstream neighboring Plans of a Plan. As shown below:

{
    "planId": ...
    ...
    "inputs": [
        {
            "path": "/in/1",
            "tags": [ ... ],
            "upstreams": [  // NEW!
              {
                  "plan": {
                      "planId": "...",
                      "image": "...",
                      "entrypoint": [ ... ],
                      "args": [ ... ],
                      "annotations": [ ... ]
                  },
                  "mountpoint": {  // this upstream is a normal output.
                      "path": "/out/1",
                      "tags": [ ... ]
                  }
              },
              {
                  "plan": {
                      "planId": "...",
                      "image": "...",
                      "entrypoint": [ ... ],
                      "args": [ ... ],
                      "annotations": [ ... ]
                  },
                  "log": {  // this upstream is a log.
                      "tags": [ ... ]
                  }
              },
            ]
        }
    ],
    "outputs": [
        {
            "path": "/out/1",
            "tags": [ ... ],
            "downstreams": [  // NEW!
                {
                    "plan": {
                        "planId": "...",
                        "image": "...",
                        "entrypoint": [ ... ],
                        "args": [ ... ],
                        "annotations": [ ... ]
                    },
                    "mountpoint": {
                        "path": "/in/2",
                        "tags": [ ... ]
                    }
                },
            ]
        }
    ],
    ...
}

Upstreams of a Plan Input are Plan Outputs or a Logs with matching Tags. If an Output (or Log) which has all Tags of the Input of another Plan, the Output is considered as Upstream of the Input. In other words, when Output or Log of a Plan A generates Data which can be assigned to an Input of Plan B, the Output/Log is upstream of the Input.

knit plan graph

The new command knit plan graph generates Plan Graph, which is an overview of your Plans, in dot format.

knit plan graph traverse Plans upstream and/or downstream Plans recursively and visualize the "pipeline" made by Plans.

See knit plan graph --help for more details.

Fix ambiguity of Data's upstream (breaking change)

Before this change, "upstream" of Data had not distinguished normal outputs and logs.
If the upstream of Data is a log, knit data find tells you the upstream has "path" (as /log).
However, the expression is identical to a that of normal output with the path /log, so with only knit data find, we could not know the upstream of Data is whether output or log.

By now, knit data find tells explicitly the upstream of Data is output or is log.

To do that, breaking changes are introduced. In JSON format of Data, "path" and "tags" are moved to a new field "mountpoint" (for normal outputs) or "log" (for log) .

{
    "knitId": "...",
    "tags": [ ... ],
    "upstream": {
        "mountpoint": {  // NEW!
            "path": "/upload",
            "tags": []
        },
        "run": {
            "runId": " ... ",
            "status": "done",
            "updatedAt": "2024-11-18T04:25:32.076+00:00",
            "plan": { ... }
        }
    },
    "downstreams": [
        {
            "mountpoint": {  // NEW!
                "path": "/in/dataset",
                "tags": [
                    "mode:training",
                    "project:first-knitfab",
                    "type:dataset"
                ]
            },
            "run": {
                "runId": "b7ed ... ",
                "status": "running",
                "updatedAt": "2024-11-18T04:44:06.008+00:00",
                "plan": { ... }
            }
        }
    ],
    "nomination": [ ... ]
}
{
    "knitId": "de17825d-16f3-4a5d-b3cb-16ef95379c0c",
    "tags": [
        "knit#id:de17825d-16f3-4a5d-b3cb-16ef95379c0c",
        "knit#timestamp:2024-11-18T05:12:32.075+00:00",
        "project:first-knitfab",
        "type:log"
    ],
    "upstream": {
        "log": {  // NEW!
            "tags": [
                "project:first-knitfab",
                "type:log"
            ]
        },
        "run": {
            "runId": "b7ed106b-cb49-4671-8979-4e85e249f15c",
            "status": "done",
            "updatedAt": "2024-11-18T05:12:32.075+00:00",
            "exit": {
                "code": 0,
                "message": ""
            },
            "plan": {
                "planId": "5770077f-e7a2-4b0f-8e8e-4d73d4b14144",
                "image": "localhost:30503/knitfab-first-train:v1.0",
                "entrypoint": [
                    "python",
                    "-u",
                    "train.py"
                ],
                "args": [
                    "--dataset",
                    "/in/dataset",
                    "--save-to",
                    "/out/model"
                ]
            }
        }
    },
    "downstreams": [],
    "nomination": []
}

Data with an "upstream" containing "mountpoint" represents a normal output, while one containing "log" represents a log.

Fix case inconsistency in JSON (breaking change)

Plan had log.Tag field. Differently than other fields, the first letter of the filed name is capitalized.

This inconcistency is not intended, so it has been fixed to log.tag.

{
    "planId": " ... ",
    "image": " ... ",
    // ...
    "log": {
        "tags": [  // renamed from "Tags".
            "project:first-knitfab",
            "type:log"
        ],
        "downstreams": []
    },
    // ...
}

How to try

This release containing breaking changes, so please be sure to update both the Knitfab system AND CLI to try.

Knitfab System

Download the installer from branch develop/v1.5.0, and run

BRANCH=develop/v1.5.0 CHART_VERSION=v1.5.0-beta installer.sh --install

in the directory where you have installed Knitfab.

CLI knit

Download from assets of this release.

What's Changed

Full Changelog: v1.4.0...v1.5.0-beta

v1.4.0

25 Oct 01:35
e3bfc68

Choose a tag to compare

  • Date: 2024-10-25

The v1.4.0 release includes

  • New fields on Plan
  • Dynamic Environmental Variable Injection to Run via Lifecycle Hook

Important Changes

New Fields on Plan

We added new fields to Plan.

Annotation

Now, Plan can be "annotated".

image: "example.com/train:v1.0"

annotation:
  - "key=value"
  - "description=annotation can have arbitrary text content"
  - "creator=takaoka.youta@opst.co.jp"

inputs:
  - ...

outputs:
  - ...

...

annotation is key=value formatted metadata of Plans itself.
They are not Tags, so Knitfab does not consider annotations when making new Runs.

You can use annotations to record arbitrary text content, for example, "What is the Plan?" or "Who is creator of the Plan?".

Annotations are mutable. To update them, use the knit plan annotate command.

Entrypoint and Args

image: "example.com/train:v1.0"

entrypoint: ["python", "main.py"]
args: ["--data", "/in/1/data", "--output", "/out/1/model"]

inputs:
  - path: /in/1/data
    tags:
      - "format:image/png"
      - "mode:train"
      - "type:dataset"
      - "project:example"

outputs:
  - path: /out/1/model
    tags:
      - "framework:pytorch"
      - "type:model"
      - "project:example"

...

With this change, Plan can have entrypoint and args which override default behavior of the image.

entrypoint overrides ENTRYPOINT directive in Dockerfile, and args overrides CMD directive.

These are optional, and by default, image will run as defined in its Dockerfile.

Service Account

image: "example.com/train:v1.0"

inputs:
  - ...

outputs:
  - ...

service_account: service_account_name

...

You can assign ServiceAccount of Kubernetes on Plans.

When a new Run based a Plan with service_account is created, the Pod of the Run is started with the ServiceAccount specified on the Plan.

Pods are started without ServiceAccount by default, which is sufficient for most Runs are self-contained within a Pod.

When your Run needs access to the Kubernetes API or cloud platforms managed services, this feature may be useful.

service_account is mutable. To update this, use knit plan serviceaccount command.

Dynamic Environmental Variable Injection to Run via Lifecycle Hook

Before this change, Knitfab ignores response bodies from Lifecycle Hooks.

With this change, Knitfab uses the response body of "Before starting" Lifecycle hook, if able.

If the response has Content-Type: application/json and contains the following structure,
Knitfab use knitfabExtension.env as environmental variables for the starting Pod.

{
  // ...
  "knitfabExtension": {
    "env": { [key: string]: string }
  }
  // ...
}

(the type notation is in TypeScript syntax)

If the response is not Content-Type: application/json or does not contain the structure,
it is ignored as it was.

You can write Lifecycle Hooks which determine envvars by the Run.

knit data tag: behavior change

new flag --remove-key

Now Tags of data can be removed by the key.

If you do below, all tags with key example-key are removed from Data identified with SOME-KNIT-ID.

knit data tag --remove-key example-key SOME-KNIT-ID

Unlike --remove, --remove-key does not consider the Value of Tag.
It is useful to change Tags with a very long note.

knit data --remove ... --add ...: remove and then add now

With this release, execution order of --add, --remove or --remove-key are changed.

Now, --removes and --remove-keys are effected first, and then --adds are effected.

The new behavior (remove first, then add) allows "update" Tags in atomic operation.

Example: update long description,

knit data tag --remove-key description --add "description:very long note of the Data" SOME-KNIT-ID

Example: update Tag referred by Plans in atomic operation.

knit data tag --remove version:latest --add version:3 SOME-KNIT-ID

License

Knitfab v1.4.0 is released under BSL 1.1, as written in the LICENSE file.

CHANGE DATE for v1.4.x is 2028-10-25.

Previous releases, v1.3.x or brefore, are not changed in their CHANGE DATE.

Upgrade Path

Knitfab System

Download the installer, and run

installer.sh --install

in the directory where you have installed Knitfab.

CLI knit

Download from assets of this release.

What's Changed

Full Changelog: v1.3.1...v1.4.0

v1.4.0-beta

23 Oct 05:49
931f028

Choose a tag to compare

v1.4.0-beta Pre-release
Pre-release
  • Date: 2024-10-23

The v1.4.0-beta release includes

  • New fields on Plan
  • Dynamic Environmental Variable Injection to Run via Lifecycle Hook

Important Changes

New Fields on Plan

We added new fields to Plan.

Annotation

Now, Plan can be "annotated".

image: "example.com/train:v1.0"

annotation:
  - "key=value"
  - "description=annotation can have arbitrary text content"
  - "creator=takaoka.youta@opst.co.jp"

inputs:
  - ...

outputs:
  - ...

...

annotation is key=value formatted metadata of Plans itself.
They are not Tags, so Knitfab does not consider annotations when making new Runs.

You can use annotations to record arbitrary text content, for example, "What is the Plan?" or "Who is creator of the Plan?".

Annotations are mutable. To update them, use the knit plan annotate command.

Entrypoint and Args

image: "example.com/train:v1.0"

entrypoint: ["python", "main.py"]
args: ["--data", "/in/1/data", "--output", "/out/1/model"]

inputs:
  - path: /in/1/data
    tags:
      - "format:image/png"
      - "mode:train"
      - "type:dataset"
      - "project:example"

outputs:
  - path: /out/1/model
    tags:
      - "framework:pytorch"
      - "type:model"
      - "project:example"

...

With this change, Plan can have entrypoint and args which override default behavior of the image.

entrypoint overrides ENTRYPOINT directive in Dockerfile, and args overrides CMD directive.

These are optional, and by default, image will run as defined in its Dockerfile.

Service Account

image: "example.com/train:v1.0"

inputs:
  - ...

outputs:
  - ...

service_account: service_account_name

...

You can assign ServiceAccount of Kubernetes on Plans.

When a new Run based a Plan with service_account is created, the Pod of the Run is started with the ServiceAccount specified on the Plan.

Pods are started without ServiceAccount by default, which is sufficient for most Runs are self-contained within a Pod.

When your Run needs access to the Kubernetes API or cloud platforms managed services, this feature may be useful.

service_account is mutable. To update this, use knit plan serviceaccount command.

Dynamic Environmental Variable Injection to Run via Lifecycle Hook

Before this change, Knitfab ignores response bodies from Lifecycle Hooks.

With this change, Knitfab uses the response body of "Before starting" Lifecycle hook, if able.

If the response has Content-Type: application/json and contains the following structure,
Knitfab use knitfabExtension.env as environmental variables for the starting Pod.

{
  // ...
  "knitfabExtension": {
    "env": { [key: string]: string }
  }
  // ...
}

(the type notation is in TypeScript syntax)

If the response is not Content-Type: application/json or does not contain the structure,
it is ignored as it was.

You can write Lifecycle Hooks which determine envvars by the Run.

knit data tag: behavior change

new flag --remove-key

Now Tags of data can be removed by the key.

If you do below, all tags with key example-key are removed from Data identified with SOME-KNIT-ID.

knit data tag --remove-key example-key SOME-KNIT-ID

Unlike --remove, --remove-key does not consider the Value of Tag.
It is useful to change Tags with a very long note.

knit data --remove ... --add ...: remove and then add now

With this release, execution order of --add, --remove or --remove-key are changed.

Now, --removes and --remove-keys are effected first, and then --adds are effected.

The new behavior (remove first, then add) allows "update" Tags in atomic operation.

Example: update long description,

knit data tag --remove-key description --add "description:very long note of the Data" SOME-KNIT-ID

Example: update Tag referred by Plans in atomic operation.

knit data tag --remove version:latest --add version:3 SOME-KNIT-ID

How to try

Knitfab System

Download the installer from branch develop/v1.4.0, and run

BRANCH=develop/v1.4.0 CHART_VERSION=v1.4.0-beta installer.sh --install

in the directory where you have installed Knitfab.

CLI knit

Download from assets of this release.

What's Changed

Full Changelog: v1.3.1...v1.4.0-beta