Post-modular CLI usage and strategy #872
Comments
|
Indeed with the kyma modularisation being almost complete, the current version of kyma cli with kyma deploy is almost of no use.
Re the third-party modules like the transparent proxy, we could opt for simplifying their kyma deploy installation by additionally allowing to provide a SAP repository technical user and password in the command line in line with the following official guidelines, namely: https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/using-transparent-proxy To undeploy, we would use PS. How to achieve 1 and 2 today:
it may take up to several minutes for the modules to become READY |
|
After some thought this is what I think any dedicated kyma cli should rather be an automation tools by category: Provisioning/deployment
Status / cluster health
mTLS communication with both kyma custom domain and business custom domain(s)
Applications |
|
For the modules command in the dev-ci section I think it makes sense to use native (existing) OCM tooling to create and verify module templates. |
|
@ptesny some remarks from my side:
We already have Gardener cluster provisioning functionality, the idea would be to have it as part of the dev toolkit as the main use case for it is the pipelines.
There is already an excellent overview in the Kyma Dashboard, do we want to duplicate it and present it as a text in the CLI? I am not a fan of that, the information in such an overview would be just an aggregation of simple commands like inspecting Kyma CR or using kubectl to get cluster nodes.
Is there anything besides deploying some YAMLs required? Or is it just creating Certificates and entries in the Istio Gateways?
Shouldn't it be covered as some kind of an example? I am not familiar with that scenario, I suppose it is already a workload deployment step not exactly tied to the logic of Kyma, are there any generic tools for Kubernetes that do that? Overall, my goal is to not duplicate functionalities of popular CLI tools such as kubectl. Looking at what Kyma is right now, after modularization there is nothing that would require such tooling as all the modules are separate entities and there is nothing to "deploy" as Kyma anymore. The tools that you've listed would be nice additions to some kind of examples or tools repository, in my opinion, this is not enough to qualify for the official Kyma CLI tooling (as those already interact with specific modules/scenarios or just aggregate and execute simple kubectl commands underneath). As I pointed out in the proposal I am not aware of any functionalities that would justify having a dedicated user-facing CLI for Kyma itself. It may be different for specific modules or business scenarios, but then - should it be a part of the CLI? If you are convinced such a tool would bring value it would be great to know all the requirements that are set by our users. Then, we will be able to discuss what and where should be added and whether it is worth keeping the CLI for that. 🙂 |
|
It is the list of commands for module management I would see in the CLI:
I think we need also commands for deploying applications and exposing them through API gateway, but I need to think a little bit more about them. |
|
One of the power and at the same time complexities with Kyma / K8s is being able to use storage. However, customers end up doing it wrong since they are not experts. e.g. using emptyDir instead of PVC. Perhaps there should be a simple way with Kyma CLI to set up a proper storage which hides all details and complexities |
|
Another challenge which many BTP customers faced is the development cycle. They want to develop their apps locally and then deploy them. But that implies a lot of mocking if they are consuming BTP services. Perhaps Kyma CLI can provide the credentials of BTP Services locally in easier fashion |
|
kyma api-proxy The api proxy use case. |
|
Then it would be clear to have the module-related commands and K8S stuff as the commands in the user-facing CLI (which would already justify having it as a "product" available to the end-users). I am a bit reluctant regarding the interaction with the BTP, should that be a part of Kyma CLI? Or should the BTP CLI be extended? To me it is a bit of a "grey area" and maintenance-wise it can be quite complicated, especially with changes and the need to align with their release cycle.
@abbi-gaurav @ptesny @kwiatekus do you have any insights on the usage of Serverless commands? I am wondering what should be the strategy regarding module-specific commands. @pbochynski do you have any opinions on the development part? Would you see it rather as a separate repository/CLI with a collection of scripts/commands? Or should those be somehow distributed across repositories? |
In my opinion, CLI should not be distributed across many repositories. Commands can be located in separate files. I am looking for a team (contributors) that can own the CLI as one consistent piece of software that provides a good interface for capabilities exposed by different kyma modules. |
|
@pbochynski What I meant is the module building, signing and verifying part, at first I would see it as a part of the Lifecycle Manager repository as a collection of scripts for the module development purposes. The raw OCM usage in the submission pipeline can later replace that. |
|
I think we have the overall direction and the further plans for the CLI already set, I will update this ticket with the decision and follow up regarding further developments in this topic. |
Created on {2023-12-29} by Jan Medrek (@janmedrek).
Decision log
Accepted on 2024-01-29ChoiceNoneContext
With the Modularization came changes to the Kyma ecosystem - it is no longer deployed as a single "monolithic" set of applications in a specifically prepared cluster. The requirements were loosened and interdependencies between components were removed. This leads to the (desired) situation where Kyma is just a set of loosely related components that coexist in almost any Kubernetes cluster.
With those changes, the requirements and needs for the proper tooling also shifted. A specialized set of commands that aim to deploy an environment fulfilling old Kyma requirements, and then install multiple related charts on top of that is no longer needed. Since that was the main responsibility of the Kyma CLI the strategy needs to be revisited.
The current set of commands in the CLI can be divided into two categories: end-user tools for interacting with the Kyma cluster and the ones that are used during the development of the modules or in the CI solutions.
The relevant (deprecated, outdated,
help, andversionomitted) command structure is:This makes a clear division, let's tackle the end-user part first:
kyma dashboardcommand deploys and opens up a Busola dashboard in the cluster, the need for this command is set in question since the introduction of the new community modules approach and dashboard.functionsection is a subset of commands strictly tied to one of the Kyma modules, Serverless in this case. The decision needed here is the strategy on the shipment channel for tooling brought by Kyma modules.modulesection is strictly tied to interacting with Kyma CR, which can be easily replaced by K8S commands or visual CR editing via some kind of K8S dashboard.Then, there is the dev-ci section:
kyma provision ...commands are used both in the teams' pipelines and during the development cycle of both Kyma Modules and the Modularization componentsmodulecommands are used mainly by the Module Submission Pipeline and to some extent by the infrastructure/security setup of the Control Plane clusters/resourcesDecision
Taking all of that into account, there are a few possible options for further development. Two decisions need to be taken - one for the user-facing CLI for modular Kyma and the other related to the toolkit used during development and pipeline execution.
For the end-user part, the options are simple:
A) Drop the end-user CLI completely and make Modules provide separate tooling for their features. This means that if the module wants to provide some functionalities via command line tools a separate binary is needed. Such a solution brings multiple tools that need to be used to interact with a single Kyma cluster containing various modules.
B) Have a dedicated CLI with functionalities related to the Kyma modules only. This makes it easier for the user to interact with the cluster, but the maintenance effort of a single cross-team repository is high and stands in opposition to what we wanted to achieve with modularisation (separation of components).
For the dev-toolkit part:
A) Divide the functionalities across different repositories and have them maintained by different teams. This brings multiple sources of truth and a de-centralised approach to such tooling.
B) Create a dedicated
dev-toolkitorcc-utilsrepository in the Kyma organization and contain the scripts/commands for the existing logic there.As for now, I am biased towards dropping the end-user CLI completely and just keeping the set of tools that are used by Kyma dev teams (which translates to the A) and B) respectively). As I've already written in the Context part - the requirements changed and I see no reason to maintain end-user-facing tooling (unless it is extensively used toward the Serverless component). For the second decision - I have no strong opinions, both results seem very similar to me - it is a rather cosmetic change but I lean towards having a single source of common CI-related commands (provisioning clusters, etc).
Summary
After the discussion, it is clear that business-oriented Kyma CLI is needed for the end-users. It should cover functionalities such as:
When it comes to the module development functionalities, those can be distributed across repositories where they fit best. Module submission pipeline can be based directly on the available OCM tooling while the infra tools should be taken over by respective teams.
Consequences
The text was updated successfully, but these errors were encountered: