Patches and Overlays¶
This page provides an overview of overlays and patches and how they work with kxi packaging in kdb Insights Enterprise.
Use templates for new parameterized packages
Package templates are the replacement for overlays when you are building a new parameterized package. Use the kxi package template command for that work. Overlays and patches are retained for compatibility with existing packages.
Patches are partial configuration blocks that can be overlaid onto a given package.
You can store them and ship them with a package to provide a quick way to modify settings and generate different packages from a given base package, overlaying patches on top until you get your desired state.
Patches work by utilizing the Package object model and manipulating it using kustomize.
The name parameter of the object being overlaid (for example: a database or table) is used as a key and array types are merged according to the strategic merge mechanism.
There is no mechanism to patch code files currently, only configuration files, which are databases and pipelines.
Using patches¶
Adding a pipeline¶
-
To create a patch, use the
addcommand and specifypatchas your new object:kxi package -q init mypkg --force kxi package -q add --to mypkg patch --name my-first-patch cat mypkg/patches/my-first-patch.yamlmetadata: name: target kind: Package apiVersion: pakx/v1 spec: manifest: {} tables: schemas: [] databases: [] pipelines: [] router: {} views: [] deployment_config: {}This adds a
patchfile to thepatchesdirectory. The new file includes the structure required for a patch file, but no pipeline.Be careful when you modify the
patchfile- Do not modify the headers above the
spec:field - It is good practice to remove everything inside
spec:except what you want to patch
- Do not modify the headers above the
-
You can see the patch object is now present in the manifest file:
kxi package info mypkg╭──────────────┬──────────────────────────────────────╮ │ Name │ Value │ ├──────────────┼──────────────────────────────────────┤ │ Package UUID │ 05cb7fbb-93d9-463a-ad50-4ffe043378ef │ │ Package Name │ mypkg (0.0.1) │ │ Owner │ - │ │ Components │ - │ │ Workloads │ - │ │ Dependencies │ - │ ╰──────────────┴──────────────────────────────────────╯ -
Modify the
patchto add a newpipeline. Keep the headers abovespec:unchanged, and leave only the section you want to patch insidespec::cat > mypkg/patches/my-first-patch.yaml <<'EOF' metadata: name: target kind: Package apiVersion: pakx/v1 spec: pipelines: - name: mynewpipeline spec: init.q EOF cat mypkg/patches/my-first-patch.yaml metadata: name: target kind: Package apiVersion: pakx/v1 spec: pipelines: - name: mynewpipeline spec: init.q -
Apply or "overlay" this patch onto your current package using the
overlaycommand:Without specifying any other information, the overlay command resolves All the patches found in the manifest:
kxi package overlay mypkg cat mypkg/manifest.yaml | grep pipelines: -A5 WARNING Creating mypkg/init.q with default spec pipelines: mynewpipeline: file: pipelines/mynewpipeline.yaml views: {} udf_namespaces: - udfOverlaying a patch can create a missing entrypoint file
A patch that references a source file which does not exist yet, such as the
spec: init.qabove, makesoverlaycreate that file with a default spec and print a warning. This is the one case whereinit.qappears without you adding it;kxi package initnever creates it.When you specify patches after the package name, you can select any valid patch file, they don't even need to be located inside a package.
kxi package overlay mypkg mypkg/patches/my-first-patch.yaml cat mypkg/manifest.yaml | grep pipelines: -A5RuntimeError Kustomize binaries not found To install the required dependencies, please run: `uv pip install pakxcli[kustomize]` N.B. you may need to supply `--extra-index-url` with credentials the above command pipelines: {} views: {} patches: - metadata: type: '' name: my-first-patch
Modifying tables¶
To modify a table, you must patch the Database because tables are contained inside the Database construct :
kxi package -q init mypkg --force
kxi package -q add --to mypkg database --name mydb
# This automatically populates a "default" table
kxi package -q add --to mypkg patch --name my-db-patch
# Write the complete patch file. The headers above `spec:` are unchanged from the
# generated file; only the section being patched is kept inside `spec:`.
cat > mypkg/patches/my-db-patch.yaml <<'EOF'
metadata:
name: target
kind: Package
apiVersion: pakx/v1
spec:
databases:
- name: mydb
tables:
schemas:
- name: default
description: We've changed the default table's description too!
type: basic
columns:
- name: myfloat
type: float
description: we've added a new float column called myfloat
- name: x2
type: symbol
description: The default x2 column has changed type
EOF
cat mypkg/patches/my-db-patch.yaml
kxi package overlay mypkg
echo ""
echo "----Resultant schema for 'default' table----"
echo "--------------------------------------------"
cat mypkg/databases/mydb/tables/default.yaml
WARNING Path mypkg already exists.
WARNING Overwriting existing package manifest at mypkg/manifest.yaml
metadata:
name: target
kind: Package
apiVersion: pakx/v1
spec:
databases:
- name: mydb
tables:
schemas:
- name: default
description: We've changed the default table's description too!
type: basic
columns:
- name: myfloat
type: float
description: we've added a new float column called myfloat
- name: x2
type: symbol
description: The default x2 column has changed type
----Resultant schema for 'default' table----
--------------------------------------------
# yaml-language-server: $schema=https://code.kx.com/insights/enterprise/packaging/schemas/package.json#/$defs/Table
columns:
- description: we've added a new float column called myfloat
name: myfloat
type: float
- description: The default x2 column has changed type
name: x2
type: symbol
description: We've changed the default table's description too!
name: default
type: basic
metadata:
apiVersion: v1
type: table
tags: []
Column ordering
After patching you can observe the columns have changed order. The new column has been added in at the top. If your application requires specific column ordering, then you need to do this manually.
Referencing dependency patches¶
You can also reference patches held in other packages to minimize the need to copy patch specs that you use regularly.
Dependency packages must be siblings of the target package
Dependency packages referenced by a patch must be available as sibling package directories in the same parent directory as the target package.
You do this in the following way:
# create mypkg and myotherpkg as siblings in the same parent directory
kxi package -q init mypkg --force
kxi package -q init myotherpkg --force
# add a patch to myotherpkg
kxi package -q add --to myotherpkg patch --name patch-from-afar
cat > myotherpkg/patches/patch-from-afar.yaml <<'EOF'
metadata:
name: target
kind: Package
apiVersion: pakx/v1
spec:
pipelines:
- name: mynewpipeline
spec: init.q
EOF
# add a dependency on myotherpkg to mypkg
kxi package add --to mypkg dep --name myotherpkg --version 0.0.1
# add a patch in mypkg referencing a patch in myotherpkg
kxi package add --to mypkg patch --name patch-from-afar --dep myotherpkg
kxi package overlay mypkg
# see that you have successfully used the patch adding a new pipeline from myotherpkg
cat mypkg/manifest.yaml | grep pipelines: -A5
WARNING Path mypkg already exists.
WARNING Overwriting existing package manifest at mypkg/manifest.yaml
pipelines:
mynewpipeline:
file: pipelines/mynewpipeline.yaml
views: {}
udf_namespaces:
- udf