search

kyma-project / community

Provides general guidelines, contributing, and maintaining rules for all who add content to Kyma.
https://kyma-project.io/community/
Apache License 2.0
44 stars 108 forks source link

Kyma CLI usage for module deployment #853

Closed pbochynski closed 11 months ago

pbochynski commented 1 year ago

Created on 2023-10-19 by Piotr Bochynski (@pbochynski)

Decision log

Name Description
Title Kyma CLI role after modularization
Due date 2023-10-31
Status Proposed on 2023-10-19, Accepted on 2023-12-06
Decision type Choice
Affected decisions New installation procedure for open source Kyma

Context

Kyma became a set of independent modules. Users can pick only those that are needed in their use case. In the managed Kyma Runtime people get some Kyma modules preinstalled and preconfigured in the new Kubernetes cluster (powered by Gardener). They can also add/delete modules by adding entries to the Kyma resource that is reconciled by the Kyma Lifecycle Manager (KLM) running in the central Kyma Control Plane (KCP). Open-source users cannot benefit from the module lifecycle management directly (without running own KCP), therefore it is recommended for them to install modules directly with kubectl commands deploying module managers and their default configuration. See: https://github.com/kyma-project/kyma/blob/main/docs/02-get-started/08-install-uninstall-upgrade-kyma-module.md#install-kyma-with-a-module. This is also the outcome of the decision record: https://github.com/kyma-project/community/issues/792

With the last Kyma component transformed into the module the current kyma deploy command does not make sense anymore. It has to be deleted or it has to be transformed to install modules selected by the user.

Option A

Deprecate and remove kyma deploy command and ask open source users to directly install modules as described here: install Kyma module During the deprecation period, we can already point users to the documentation printing the link in the CLI warning.

Pros: little effort for our team, users have full control over the installation procedure. Cons: more complex installation (2 commands per module)

Option B

Keep kyma deploy command but change the implementation to execute kubectl apply commands referenced in the documentation.

Pros: similar experience to not-modular Kyma Cons: the command can easily become unstable without managing possible upgrade paths (imagine users skipping some versions or downgrading components). Hiding module releases (and their release notes and migration steps) can lead to frustration and a bad impression of Kyma's quality.

Option C

Deprecate and remove kyma deploy command and overload the kyma add module command to execute kubectl apply commands in the open source scenario and add modules to the Kyma resource in the managed Kyma Runtime.

Pros: the same syntax for open source and managed Kyma Cons: this can lead to confusion. People would expect the same behavior but in fact, it will be completely different. Also, all the cons from option B apply here.

Decision

Deprecate and remove kyma deploy command and ask open source users to directly install modules as described here: install Kyma module (Option A)

Consequences

Related commands also should be removed: "kyma undeploy" and "kyma version".

janmedrek commented 1 year ago

Hey @pbochynski, some comments from my side:

Overall, I would question the idea of using CLI for general Kyma installation at all - we've already shifted away from the procedure that needs multiple steps executed in a specific order for the Kyma to be installed. It is now just a set of modules that can be installed separately and thus, I am not sure whether the whole Kyma can be shipped as a single "product" anymore.

With the approach we have now I'd lean towards option A - it does not make sense to me to ship the whole package anymore, to be honest. If we really need to deliver everything in a single package, then I'd rather go either for option B or deploy KLM with module templates in the target cluster and use the same flow as we have in the SKRs. Anyways, deploying the whole Kyma as one package is kind of the opposite of what we wanted to achieve with the modularization, and I think it should not be a valid use case anymore.

I am aware that we try to hide that layer (MTs, KLM, Kyma CR) from the users, managing different versions of commands (or even whole CLIs) for the OS and Managed is not worth it in my opinion so I am strongly against the option C.

a-thaler commented 1 year ago

What we always missed in the CLI was a clear focus on the user group and I think that should be the driving factor here to get to the decision. Which audience we want to reach? At the moment I see the following use cases realized in the CLI: Runtime feature:

Cluster management feature:

I think as a first step we should decide if the managed user needs a CLI at all and for which activities (ignoring local installation for now).

Afterwards, we can think of extending that to local installations as well (not so much OS usage) and how to develop locally and get the stuff synced/tested on the remote cluster. If we decide that this is valuable we need to think how that scenario should look like, LCM based or not. Then it will get also clear what is needed here.

If we don't want to support local usage, what should be the OS usage scenario? How much will it be different to local usage?

In my opinion we should not mix up the pure module development, that will confuse the end-user. I suggest to have a dedicated CLI if really needed supporting there the E2E module development flow.

Summarised: let's first identify the overall strategy of the CLI usage and derive from there the specific decision.

pbochynski commented 11 months ago

Few comments to the discussion:

  1. @janmedrek I agree with you that deploying kyma as a one package is not the valid use case.
  2. @a-thaler I agree that module development and testing is not in scope for kyma CLI
  3. For open source use case module installation with kubectl is simple enough and adding support in Kyma CLI will not make too much difference
  4. Managed Kyma Runtime can be provisioned with some modules enabled using service instance parameters (https://github.com/kyma-project/control-plane/issues/3027) and btp CLI.

With all the points above I propose to pick option A and remove kyma deploy command.

a-thaler commented 11 months ago

We should not forget "kyma undeploy" and "kyma version".

Also "kyma alpha deploy" can be very confusing..

What about the related "kyma import certs" and "kyma import hosts" which was useful in combination with the local api-gateway usage, probably also not relevant anymore

pbochynski commented 11 months ago

The Option A was choosen

janmedrek commented 11 months ago

@a-thaler I will be preparing a proposal with the new command structure for the CLI, but at that point, we should decide whether it is needed at all. There will be a discussion obviously.