Design Kyma CLI flow for basic kyma use case

[kwiatekus]

Description

Propose how to combine kyma CLI into the following scenario (not every step must necessarily mean a new kyma cli command).

I have empty cluster (SKR)

• explore what are available modules to enable
• explore what capabilities are available via api-gateway module (info)
• explore what CRDs are available via api-gateway module (API-Rule)
• enable module api-gateway
• check status of api-gateway (read config, state)
• explore what capabilities are available via btp-operator module (info)
• explore what CRDs are available via btp-operator module (Service Instance, Service Binding)
• enable module btp-operator
• check status of btp-operator (read config, state)
• explore what capabilities are available via docker-registry module (info)
• enable docker-registry
• explore what CRDs are available via CloudManager module (NFSStorage)
• enable module cloud-manager (& check status)
• create NFS storage via cloud manager
• inspect the status of nfs storage - learn the PVC name
• configure docker-registry (expose it and set the storage by referencing pvc from cloud manager)
• create reference instance to a shared btp object store service (this command already exists among alpha commands)
• create binding to the instance
• view the status of binding - learn the secret name
• Implement a simple CRUD service that use btp object store (consumes the mounted secret via sap cloud sdk) -> Dockerfile
• Read docker registry config (config.json) from docker registry CR
• Login into docker registry via Docker CLI (using config.json)
• push image (from dockerfile)
• create deployment for the service ( using image url)
• expose the service using api rule

Reason
The goal of this excercise is to design what could be the kyma CLI commands based on a real life scenario
Kyma cli should allow to interact with resources that kyma brings on top of kubernetes.

[pPrecel]

Commands

I collected all current commands and located them in three categories. This may help with designing new commands.

Current (grouped) commands

These commands should be still in the CLI but maybe we should refactor/redesign them

# utils/scripts
kyma alpha access # <- produce kubeconfig for given cluster 

# module management
kyma alpha modules # <- list available modules based on PB JSON
kyma alpha add # <- add deploy community-module based on PB JSON
kyma alpha add managed # <- add kyma-module to the Kyma CR
kyma alpha remove # <- remove deployed community-module based on PB JSON
kyma alpha remove managed # <- remove kyma-module from the Kyma CR

# module resources
kyma alpha image-import # <- import image from local docker daemon to the cluster using port-forward (kyma docker-registry image-import / import)
kyma alpha reference-instance # <- add instance ref to shared svc instance (btp) (kyma btp-operator reference-instance)

Comands to remove

As in the title

# utils??
kyma alpha provision # <- provision kyma on btp

Commands to redefine

We don't decided what to do with these commands

# utils/scripts
kyma alpha oidc # <- create kubeconfig with oidc token

# these commands are related with btp-operator but for example map looks like util/script
kyma alpha hana
kyma alpha hana check
kyma alpha hana credentials
kyma alpha hana delete
kyma alpha hana map
kyma alpha hana provision

[pPrecel]

Commands

Details

Together with Andrzej Pankowski (@Cortey), we've decided to design a new commands pallet based on three requirements, domain the cli will be focused on:

• Module management - contains all commands responsible for managing modules.
• Module resources - contains all commands focused on managing resources like Function, ApiRules, and so on
• Scripts/utils - contains all non-generic operations/automations/scripts that may be used in (for example) pipelines.

Module management

Installing, uninstalling, describing, checking status, updating. The goal was to prototype API based on high-level words that do not remind Kubectl operations. Input parameters for create/update operations and output values for get/list commands may be defined in the ConfigMap maintained by the module owners (like it's right now with busola extensions).

kyma list <--installed/--available/--managed>
kyma describe <MODULE_NAME> <--crds/--description/...>
kyma deploy <MODULE_NAME> <--overwrite> <FLAGS_FROM_CONFIGMAP> #<--namespace>
kyma undeploy <MODULE_NAME> #<--namespace>
kyma enable <MODULE_NAME> <--unmanaged> <--overwrite> <FLAGS_FROM_CONFIGMAP> #<--namespace>
kyma disable <MODULE_NAME> #<--namespace>
kyma configure <MODULE_NAME> <FLAGS_FROM_CONFIGMAP> #<--namespace>
kyma inspect <MODULE_NAME> <FLAGS_FROM_CONFIGMAP> <--output=text/json/yaml> #<--namespace>

Note: we don't know what with the --namespace flag. Is the namespace pre-defined for core/community modules?

Module resources

The goal is to create a generic API as close as possible to the Kubectl API (possibly the same words responsible for actions). Like in the Module management commands, configuration for all resource operations parameters may be located in the ConfigMap maintained by resource/module owners.

kyma create <RESOURCE_TYPE> <RESOURCE_NAME> <--overwrite/--namespace> <FLAGS_FROM_CONFIGMAP> 
kyma patch <RESOURCE_TYPE> <RESOURCE_NAME> <--overwrite/--namespace> <FLAGS_FROM_CONFIGMAP>
kyma delete <RESOURCE_TYPE> <RESOURCE_NAME> <--namespace>
kyma explain <RESOURCE_TYPE>
kyma status <RESOURCE_TYPE> <RESOURCE_NAME/--all> <--namespace> <--output=text/json/yaml>
kyma get <RESOURCE_TYPE/--all> <--all> <--namespace> <--output=text/json/yaml>

Scripts/Utils

These commands should be fully maintained by our team. The goal is to keep more advanced actions in one place to, for example, import a docker image to the in-cluster docker registry or create a BTP object store instance on the cluster. These operations do require more chained actions than creating/updating a single object.

Question: Maybe we should get rid of the run prefix? If these commands are responsible for specific use cases and we can group them together in help output, then maybe it's worth simplifying the commands tree?

kyma run
kyma run image-import
kyma run registry-config
kyma run reference-instance
kyma run hana-map
kyma run expose
kyma run access

Configmap

Every team responsible for the module (and its resources) should prepare configmap with command details. This configmap requires specific labels to be fetched by the cli.

For modules:

labels:
    kyma-cli/extension: module
    kyma-cli/extension-version: 0.1

and for resources:

labels:
    kyma-cli/extension: resource
    kyma-cli/extension-version: 0.1

output configmap should looks like this:

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    kyma-cli/extension: resource/module
    kyma-cli/extension-version: 0.1
  name: function.serverless.kyma-cli
  namespace: kyma-system
data:
    ...

Configmap data

In the following example, every team can define custom arguments and list of outputs for every module/resource:

info: |
    description: ...
    repoUrl: ...
    ...: ...
meta: |
    # singular: function
    # plural: functions
    # scope: namespaced
    kind: Function
    group: serverless.kyma-project.io
    version: v1alpha2
input: |
    runtime:
        shorthand: "r"
        path: ".spec.runtime"
        type: string
        description: "function runtime"
        default: "nodejs20"
        required: true
    replicas:
        path: ".spec.replicas"
        type: int
        description: "function replicas"
        default: 1
        required: false
    source:
        shorthand: "s"
        path: ".spec.source.inline.source"
        type: path
        description: "function source code"
        required: true
    dependencies:
        shorthand: "d"
        path: ".spec.source.inline.dependencies"
        type: path
        description: "function dependencies"
        required: false
output: |
    # maybe we can support languages like JSONata? :)
    runtime:
        path: ".status.runtime"
        type: string
    runtime-image:
        displayName: "Runtime Image"
        path: ".status.runtimeImage"
        type: string
    configured:
        path: ".status.conditions[0].status"
        type: string
    built:
        path: ".status.conditions[1].status"
        type: string
    running:
        path: ".status.conditions[2].status"
        type: string

In this example, a Function may have four flags used by the kyma create and kyma patch commands. For example:

> kyma create function my-function --runtime=nodejs20 --replicas=12 --source=/tmp/handler.js
Function my-function created.

> kyma patch function my-function --source=/tmp/handler-2.js
Function my-function patched.

> kyma patch function my-function --replicas=1
Function my-function patched.

The output section may define values that will be printed after running kyma get or kyma status commands. For example:

> kyma get function my-function --output json
{
    "runtime": "nodejs20",
    "runtimeImage": "some-image:0.1",
    "configured": "True",
    "built": "True",
    "running": "True"
}

or

> kyma get function my-function --runtime
nodejs20

Example kyma help

The kyma help command should group commands from these three groups and display them in right categories:

Description:
    Kyma CLI is a command line tool which supports Kyma users.

Usage:
    kyma [ACTION] [ARGS] [FLAGS]

Module actions:
    list - list modules available for the cluster
    describe - print details about module
    deploy - apply community module based on template
    undeploy - remove community module resources based on temaplte
    enable - enable core module in the Kyma CR
    disable - disable core module in the Kyma CR
    configure - configure module cr
    inspect - inspect module status

Resources actions:
    create - create kyma resource
    patch - patch specified field of a resource
    delete - delete kyma resource
    explain - get documentation of a resource
    status - print kyma resource status
    get - get one or many kyma resources

Utils actions:
    run - group of useful scripts/automations

General actions:
    completion - generate autocompletion script
    alpha - group of non-production ready and alpha commands
    help - helm about commands

Use "kyma [ACTION] --help" for more information about an action.

Script

We've prototyped the script described in the ticket using the conception from this comment:

kyma list

kyma describe api-gateway
kyma enable api-gateway
kyma inspect api-gateway

kyma describe btp-operator
kyma enable btp-operator
kyma inspect btp-operator

kyma describe docker-registry
kyma enable docker-registry

kyma describe cloud-manager
kyma enable cloud-manager
kyma inspect cloud-manager

kyma create gcpnfsvolume \
    my-vol --namespace default --location us-west1-a --capacity-gb 1024
export PVC_NAME=$(kyma status gcpnfsvolume \
    my-vol --namespace default \
    --output json | jq ".pvcName")
kyma configure docker-registry \
    --external-access=true --storage-type=pvc --storage-pvc-name=$PVC_NAME

kyma run reference-instance \
    --name my-instance --namespace default ...
kyma create servicebinding \
    my-binding --namespace default --instance-name my-instance ...
kyma status servicebinding \
    my-binding --namespace default

# create apps Dockerfile

kyma run registry-config --output config.json
export REGISTRY_URL=$(kyma run registry-config --external-url)
# or: export REGISTRY_URL=$(kyma inspect docker-registry --output json | jq '.externalUrl')
docker build "$REGISTRY_URL/my-app:0.1" .
docker --config=. push "$REGISTRY_URL/my-app:0.1"

export REGISTRY_SECRET_NAME=$(kyma inspect docker-registry --external-access-secret)
kubectl run my-pod --image="$REGISTRY_URL/my-app:0.1"   --overrides="{ \"spec\": { \"imagePullSecrets\": [ { \"name\": \"${REGISTRY_SECRET_NAME}\" } ] } }"

kubectl expose pod my-pod --port=80 --target=8080 --name=my-svc
kyma create apirule \
    --name my-apirule --namespace default \
    --svc-name my-svc --svc-namespace default \
    --svc-port 8000 --path "/.*" --methods "GET,POST"
# or: kyma run expose my-svc --namespace --path="/.*" --methods="GET,POST"...

Questions

1. Modules are singletons? What if a user wants to deploy three docker-registries?
2. Modules have pre-defined namespace?

[pPrecel]

Conclusions

Steps for the enable

1. add module to the Kyma CR with ignore policy (--default to disable ignore policy and to skip 3.)
2. wait for module to be ready/warning (--no-wait to enable no-wait mode)
3. add default module CR with additional configuration from flags

Steps for the disable:

If ignore policy is enabled

1. warn if module resources exist (--remove-resources to remove them)
2. remove module CR
3. wait for CR removal
4. remove the module from the Kyma CR

If ignore policy is disabled

1. warn if module resources exist (--remove-resources to remove them)
2. remove the module from the Kyma CR

Commands

Propose a new API with merged module and resources commands into one commands list

[pPrecel]

V2

Version No. 2 proposes the same functionality but with different commands API. The idea is to use same commands for module and resource management.

Commands

In this variant, modules and resources are managed by the same action words but depending on the context they offere different flags and functionality

Modules

kyma create/add <MODULE_NAME> <--no-wait> <--unmanage> <--default-cr> <--overwrite> <FLAGS_FROM_CONFIGMAP> 
kyma patch <MODULE_NAME> <--no-wait>  <--unmanage> <--default-cr> <--overwrite> <FLAGS_FROM_CONFIGMAP> 
kyma delete/remove <MODULE_NAME>  <--remove-resources>
kyma explain <MODULE_NAME> <--crds/--description/...>
kyma status <MODULE_NAME> <--all> <--output=text/json/yaml>
kyma get modules <--installed/--available/--managed> <--output=text/json/yaml>

Commands:

• create/add - depending of module type (community/core) add module to the Kyma CR or deploy it's manager. Decide if deploy module without, with default or with custom configured module CR
• path - change module CR configuration or it's representation in the Kyma CR
• delete/remove - remove core module from kyma CR or remove it's resource and controller from cluster for community module
• explain - describe what module will add to your cluster (functionality, crds, ...)
• status - get module/s status based on the output field in the configmap
• get - get module/s based on fielters

Flags:

• --no-wait - do not wait for module to be state ready
• --unmanage - add module to the Kyma CR with the managed set to false (only for managed modules)
• --default-cr - add module to the Kyma CR with the customResourcePolicy set to CreateAndDelete instead of Ingore. This flag can't be used with the --overwrite and with FLAGS_FROM_CONFIGMAP.
• --overwrite - generic way to patch any field in the default CR to change it
• FLAGS_FROM_CONFIGMAP - additional flags defined in the ConfigMap to patch default CR
• --remove-resources - do not fail when module resources (like functions) are on the cluster and remove them first

Resources

kyma create/add <RESOURCE_TYPE> <RESOURCE_NAME> <--namespace> <--overwrite> <FLAGS_FROM_CONFIGMAP> 
kyma patch <RESOURCE_TYPE> <RESOURCE_NAME> <--namespace> <--overwrite> <FLAGS_FROM_CONFIGMAP>
kyma delete/remove <RESOURCE_TYPE> <RESOURCE_NAME> <--namespace>
kyma explain <RESOURCE_TYPE>
kyma status <RESOURCE_TYPE> <RESOURCE_NAME/--all> <--namespace> <--output=text/json/yaml>
kyma get <RESOURCE_TYPE/--all> <--all> <--namespace> <--output=text/json/yaml>

Script

kyma get modules

kyma explain api-gateway
kyma add api-gateway
kyma status api-gateway

kyma explain btp-operator
kyma add btp-operator
kyma status btp-operator

kyma explain docker-registry
kyma add docker-registry

kyma explain cloud-manager
kyma add cloud-manager
kyma status cloud-manager

kyma add gcpnfsvolume \
    my-vol --namespace default --location us-west1-a --capacity-gb 1024
export PVC_NAME=$(kyma status gcpnfsvolume \
    my-vol --namespace default \
    --output json | jq ".pvcName")
kyma patch docker-registry \
    --external-access=true --storage-type=pvc --storage-pvc-name=$PVC_NAME

kyma run reference-instance \
    --name my-instance --namespace default ...
kyma add servicebinding \
    my-binding --namespace default --instance-name my-instance ...
kyma status servicebinding \
    my-binding --namespace default

# create apps Dockerfile

kyma run registry-config --output config.json
export REGISTRY_URL=$(kyma run registry-config --external-url)
# or: export REGISTRY_URL=$(kyma status docker-registry --output json | jq '.externalUrl')
docker build "$REGISTRY_URL/my-app:0.1" .
docker --config=. push "$REGISTRY_URL/my-app:0.1"

export REGISTRY_SECRET_NAME=$(kyma inspect docker-registry --external-access-secret)
kubectl run my-pod --image="$REGISTRY_URL/my-app:0.1"   --overrides="{ \"spec\": { \"imagePullSecrets\": [ { \"name\": \"${REGISTRY_SECRET_NAME}\" } ] } }"

kubectl expose pod my-pod --port=80 --target=8080 --name=my-svc
kyma add apirule \
    my-apirule --namespace default \
    --svc-name my-svc --svc-namespace default \
    --svc-port 8000 --path "/.*" --methods "GET,POST"
# or: kyma run expose my-svc --namespace --path="/.*" --methods="GET,POST"...

[pbochynski]

I tend to like the most the explicit module command with sub actions.

kyma module list <--installed/--available/--managed>
kyma module describe <MODULE_NAME> <--crds/--description/...>
kyma module deploy <MODULE_NAME> <--overwrite> <FLAGS_FROM_CONFIGMAP> #<--namespace>
kyma module undeploy <MODULE_NAME> #<--namespace>
kyma module add <MODULE_NAME> <--unmanaged> <--overwrite> <FLAGS_FROM_CONFIGMAP> #<--namespace>
kyma module remove <MODULE_NAME> #<--namespace>
kyma module configure <MODULE_NAME> <FLAGS_FROM_CONFIGMAP> #<--namespace>
kyma module inspect <MODULE_NAME> <FLAGS_FROM_CONFIGMAP> <--output=text/json/yaml> #<--namespace>

And other actions also should have subject in front. Example:

kyma function deploy
kyma function scale
kyma function expose --function name --create-service --create-api-rule

kyma deployment expose --create-service --create-api-rule 

kyma gcpnfsvolume create ...

kyma service-binding create  <name> --create-reference <reference-name>

This way we can introduce more verbs that describe actions (not only CRUD). Using a limited number of verbs makes kyma CLI similar to kubectl (and somehow not needed as we can do everything with kubectl). Kyma CLI should help in the cases where you need multiple kubectl commands or complex configuration files.

[pPrecel]

V3

This comment describes the new idea of extendable cli API.

The main idea is to keep [ACTION] from the first proposition but make them less generic and close in specific a noun representing resource/module.

The second idea is to improve API extensions described in the configmap.

Module management

We should offer a generic API allowing to manage core/community modules without the possibility of extending its functionality. List of commands:

kyma module list <--installed/--available/--managed>
kyma module describe <MODULE_NAME> <--crds/--description/...>
kyma module deploy <MODULE_NAME> #<--namespace>
kyma module undeploy <MODULE_NAME> #<--namespace>
kyma module enable <MODULE_NAME> <--unmanaged> #<--namespace>
kyma module disable <MODULE_NAME> #<--namespace>
kyma module configure <MODULE_NAME> <FLAGS_FROM_CONFIGMAP> #<--namespace>
kyma module inspect <MODULE_NAME> <FLAGS_FROM_CONFIGMAP> <--output=text/json/yaml> #<--namespace>

Configmap

Flags for configuration/inspection should be the only way to extensible module command responsible for specific modules:

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    kyma-cli/extension: module
    kyma-cli/extension-version: 0.1
  name: serverless.kyma-cli
  namespace: kyma-system
data:
  additionalConfiguration: |
    configure: 
      flags:
      - name: resourcePreset
        shorthand: "r"
        path: ".spec.resourcePreset"
        type: string
        description: "resource preset used by default to all functions"
        default: "L"
      - name: enableInternal
        shorthand: "i"
        path: ".spec.dockerRegistry.enableInternal"
        type: bool
        description: "enable in-cluster docker-regsitry"
        default: true
    inspect: 
      parameters:
        - name: state
          path: ".status.state"
          type: string
        - name: internalRegistry
          path: ".status.intenralRegistry.enabled"
          type: bool
        - name: resourcePreset
          path: ".status.resourcePreset"
          type: string

This will cause cli users to configure configure and inspect commands like this:

> kyma module configure serverless --resourcePreset XL --enableInternal false
Module Serverless configured.

> kyma module inspect serverless
state: Ready
internalRegistry: false
resourcePreset: XL

> kyma module inspect serverless --state
state: Ready

> kyma module inspect serverless --json
{
  "state": "Ready",
  "internalRegistry": false,
  "resourcePreset": "XL"
}

Module specific actions

The idea is to get rid of resource-specific commands (kubectl-like) to not support generic CRUD operations. We can offer teams supporting generic operations (like create, delete, edit, view) but the team responsible for a module should specify which commands and with which flags should be added to the CLI dynamically. It should look like this:

1. The module team creates configmap with cli commands group.
2. Cli will fetch all configmaps from the cluster and build command tree based on them.
3. The user now has access to new functionality in his cli based on the cluster he is connected to.

For example, after adding module serverless using kyma module enable serverless, installed serverless will add configmap with additional functionalities to the cluster, so the user now should have extended cli with additional commands:

example flow:

> kyma --help

<DESCRIPTION>

Commands:
    module - module management
    completion - generate autocompletion script
    alpha - group of non-production ready and alpha commands
    help - helm about commands

> kyma module enable serverless --wait --default-cr
Module serverless enabled.
Waiting for module to be ready.
Applying default CR.

> kyma --help

<DESCRIPTION>

Commands:
    module - manage modules
    function - manage functions <-- new command group
    completion - generate autocompletion script
    alpha - group of non-production ready and alpha commands
    help - helm about commands

> kyma function --help

<DESCRIPTION>

Commands:
    create - create function
    list - list functions
    delete - delete functions
    expose - expose function with ApiRule
    subscribe - subscribe function to events

Configuration

It's not a good idea to support all generic use cases (CRUD operations) for all resources by default. Additionally, some resources/groups may have their own custom scripts. It's not possible to support writing scripts in configmaps without huge consequences, so we can perform three types of resource/group commands extensibility:

• templates - we can create generic functionality for most CRUD operations to keep functional code in the cli, but its configuration (flags, flags defaults, and so on) in the configmap. Additionally, a team can decide if a resource needs, for example, a status operation (print formatted status in a given format) or not. Example command templates: create, delete, get, status, explain, patch.
• core logic in cli - some resources/modules may need additional complex scripts that can't be stored in configmap, these should be written in the cli, but configmap should contain information that this command is enabled on this cluster.
• custom logic on-demand - custom scripts/functionalities may be also called from inside of the cluster. Configmap can contain a configuration that points to the svc/deploy/pod inside the cluster, which should be called with specific parameters specified by command flags (flags also defined in the CM). This allows us to support custom-user scripts that are not a part of cli, and additionally, these scripts will be always compatible with a module because will be a part of it. This concept is similar to this described here.

ConfigMap

This is the proposition of the new version of the CM:

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"

NODE: This is only a proposition, for every flag we can implement more details like usage, examples, or descriptionLong, but I would not go too much into the details :)

This configuration should cause the following commands structure:

> kyma --help

<DESCRIPTION>

Commands:
    module - manage modules
    function - manage functions <-- new command group
    completion - generate autocompletion script
    alpha - group of non-production ready and alpha commands
    help - help about commands

> kyma function --help

Description:
  manage functions # description of new commands group

Commands:
  create - create function
  patch - patch function
  get - get function/s
  delete - delete function
  explain - explain function resource
  expose - expose function using ApiRule
  demo - deploy demo Function subscribed for Events and exposed by ApiRule

> kyma function create --help

Description:
  create function

Flags:
  --namespace - resource namespace (default: default)
  --runtime, -r - function runtime (default: Nodejs20)
  --replicas - function replicas (default: 1)
  --source - path to file with functions code (required)
  --dependencies - path to file with functions dependencies
  --overrides - an inline JSON override for the generated object

[pPrecel]

V3 script

kyma module list

kyma module describe api-gateway
kyma module enable api-gateway
kyma module inspect api-gateway

kyma module describe btp-operator
kyma module enable btp-operator
kyma module inspect btp-operator

kyma module describe docker-registry
kyma module enable docker-registry

kyma module describe cloud-manager
kyma module enable cloud-manager
kyma module inspect cloud-manager

kyma gcpnfsvolume create \
    my-vol --namespace default --location us-west1-a --capacity-gb 1024
export PVC_NAME=$(kyma gcpnfsvolume status \
    my-vol --namespace default \
    --output json | jq ".pvcName")
kyma module configure docker-registry \
    --external-access=true --storage-type=pvc --storage-pvc-name=$PVC_NAME

kyma btp reference-instance \
    --name my-instance --namespace default ...
kyma servicebinding create \
    my-binding --namespace default --instance-name my-instance ...
kyma servicebinding status \
    my-binding --namespace default

# create apps Dockerfile

kyma registry config --output config.json
export REGISTRY_URL=$(kyma registry config --external-url)
# or: export REGISTRY_URL=$(kyma module inspect docker-registry --output json | jq '.externalUrl')
docker build "$REGISTRY_URL/my-app:0.1" .
docker --config=. push "$REGISTRY_URL/my-app:0.1"

export REGISTRY_SECRET_NAME=$(kyma module inspect docker-registry --external-access-secret)
kubectl run my-pod --image="$REGISTRY_URL/my-app:0.1"   --overrides="{ \"spec\": { \"imagePullSecrets\": [ { \"name\": \"${REGISTRY_SECRET_NAME}\" } ] } }"

kubectl expose pod my-pod --port=80 --target=8080 --name=my-svc
kyma apirule create \
    --name my-apirule --namespace default \
    --svc-name my-svc --svc-namespace default \
    --svc-port 8000 --path "/.*" --methods "GET,POST"
# or: kyma workload/deployment/pod/api-gateway expose my-svc --namespace --path="/.*" --methods="GET,POST"...