As the output of the Design Kyma CLI flow for basic kyma use case we decided to allow extending the kyma-cli v3 API using yaml configuration hosted by teams in ConfigMaps.
As a first step, we should prototype a mechanism fetching Configmaps from a cluster with expecting labels (required for every Configmap extending cli API).
We can start implementing the first features enabled in such a configuration, like command templates. For now, we can start with one of create, delete, get, status, explain, or patch.
AC
[x] kyma cli is fetching config maps by label in order to offer commands
[x] kyma cli offers at least one "template command" command that is sourced from a config map, i.e kyma alpha function explain that explains function CR based on the config map
[x] STRETCH cli offers exemplary "custom commands" that is sourced from a config map, i.e kyma alpha registry config and/or kyma alpha registry image-import
[x] introduce error handling for config-map parsing
Proposition how such configmap could look like for now:
apiVersion: v1
kind: ConfigMap
metadata:
labels:
kyma-cli/extension: resource
kyma-cli/extension-version: 0.1
name: function.serverless.kyma-cli
namespace: kyma-system
data:
metadata: |
name: function # name of new commands group
description: manage functions # description of new commands group
resource: |
singular: function
plural: functions
scope: namespaced
kind: Function
group: serverless.kyma-project.io
version: v1alpha2
templateCommands: |
create:
description: create function
customFlags:
- name: runtime
shorthand: "r"
path: ".spec.runtime"
type: string
description: "function runtime"
default: "nodejs20"
required: true
- name: replicas
path: ".spec.replicas"
type: int
description: "function replicas"
default: 1
required: false
- name: source
shorthand: "s"
path: ".spec.source.inline.source"
type: path
description: "function source code"
- name: dependencies
shorthand: "d"
path: ".spec.source.inline.dependencies"
type: path
description: "function dependencies"
required: false
patch:
description: patch function
customFlags:
- name: runtime
shorthand: "r"
path: ".spec.runtime"
type: string
description: "function runtime"
default: "nodejs20"
- name: replicas
path: ".spec.replicas"
type: int
description: "function replicas"
default: 1
required: false
- name: source
shorthand: "s"
path: ".spec.source.inline.source"
type: path
description: "path to file with functions code"
- name: dependencies
shorthand: "d"
path: ".spec.source.inline.dependencies"
type: path
description: "path to file with functions dependencies"
required: false
delete:
description: delete function
explain:
description: explain function resource
info: |-
this resource allows you to deploy code as a service without taking care of architecture and Kubernetes resources
...
get:
description: get function/s
parameters:
- name: runtime
path: ".status.runtime"
type: string
- name: runtime-image
displayName: "Runtime Image"
path: ".status.runtimeImage"
type: string
- name: configured
path: ".status.conditions[0].status"
type: string
- name: built
path: ".status.conditions[1].status"
type: string
- name: running
path: ".status.conditions[2].status"
type: string
coreCommands: |
- name: expose
coreFuncID: expose-function # enables functionality defined for this resource in the cli under name defined in the `name` field
description: expose function using ApiRule
- name: migrate # example only
coreFuncID: migrate-function
description: migrate something to something...
- ...
customCommands: |
- name: demo
description: deploy demo Function subscribed for Events and exposed by ApiRule
target:
svcName: serverless-controller
port: 8080
endpoint: "/cli/demo"
token:
fromSecret:
name: serverless-controller-cli
item: token # `.data` field name
parameters:
- name: functionName
flag:
name: name
shorthand: "n"
type: string
description: "function name"
required: true
- name: functionRuntime
flag:
name: runtime
shorthand: "r"
type: string
description: "function runtime"
default: "nodejs20"
- name: gateway
flag:
name: gateway
shorthand: "g"
type: string
description: "istio gateway"
default: "kyma-system/kyma-gateway"
- name: eventType
flag:
name: event-type
shorthand: "e"
type: string
description: "event type"
default: "demo-function-type"
Description
As the output of the
Design Kyma CLI flow for basic kyma use case
we decided to allow extending the kyma-cli v3 API using yaml configuration hosted by teams in ConfigMaps.As a first step, we should prototype a mechanism fetching Configmaps from a cluster with expecting labels (required for every Configmap extending cli API).
We can start implementing the first features enabled in such a configuration, like command templates. For now, we can start with one of
create
,delete
,get
,status
,explain
, orpatch
.AC
kyma alpha function explain
that explains function CR based on the config mapkyma alpha registry config
and/orkyma alpha registry image-import
Proposition how such configmap could look like for now: