Default modules and configurable module list in KEB

pbochynski commented 11 months ago

Description Provide a way to specify the default module list for new Kyma instances in KEB. The default list should be applied only if the user does not select modules. The default modules are applied once when Kyma resource is created by KEB in the KCP, and then applied in the SKR by lifecycle-manager. When Kyma resource is created in the SKR it becomes the single source of truth. Users can modify Kyma resources in SKR and even remove default modules later.

Reasons Almost all usage scenarios for Kyma Runtime require an ingress gateway and some BTP services. Therefore after creating Kyma instance users have to enable istio and btp-operator modules before they can deploy their applications. It is also not trivial to automate module installation as it requires kubeconfig for the created cluster. Default modules will make standard use cases (like deploying CAP applications) working out of the box. On the other hand, users who have specific module requirements can still get what they want. Examples:

Empty cluster (no modules)
```
 modules: []
```

Cluster with default modules:

<modules not configured in the instance parameters>

Selected modules with default configuration:

  modules: ["istio", "btp-operator", "telemetry", "serverless"]

Selected modules with custom configuration:

  modules: [
     {"name":"istio", "channel":"fast", "customResourcePolicy":"Ignore"},
     {"name":"serverless"}
  ]

Attachments

https://github.com/kyma-project/lifecycle-manager/issues/756

PK85 commented 11 months ago

Challenges:

[ ] 1) AC point 1 and 2 are not supported in the SAP Cockpit UI. If user does not provide a value this parameter is not send
[ ] 2) AC point 3, from where user get a list of available modules?
[ ] 3) AC point 4, what will be a flow when "customResourcePolicy":"Ignore" cause then if user wants to have any automation then they need to get kubeconfig and somehow use it and provide custom CR to the SKR. Which is the same flow as u describe in the description.

Alternative MVP solution:

Provide an input parameter "defaultModules": true/false.
Provide a way to get an SKR where then they have kubeconfig that has clientId, clientSecret flow: https://github.tools.sap/kyma/backlog/issues/2660

abbi-gaurav commented 11 months ago

Btp-operator would be required when extending SAP Cloud Solutions, especially with the S/4 Stack.

Currently, two major Cloud Solutions does not require use of BTP for extensibility

SAP Commerce Cloud
SAP Cloud for customer

With SAP Cloud for customer v2, this will change and it will also need BTP Service consumption.

PK85 commented 10 months ago

Implementation ticket: https://github.com/kyma-project/kyma-environment-broker/issues/48

PK85 commented 9 months ago

Decision: We decided together with @pbochynski @ukff that KEB will not validate if the module name exists on the server side. The user just provides module names and then KEB passes it to Kyma resource. Then KEB returns the status to the user that the Kyma cluster is provisioned successfully.

What needs to be done is to add technical module names to the documentation so that users will know what they can use. + We will provide some JSON input parameters examples of how to work with modules so that users can use it in the JSON view.

Reason 1) We want to avoid having the whole LM validation in the KEB component that we would need to keep in sync every time LM releases a new feature for module templates. 2) Assuming we have also "only for BETA" and "only for INTERNAL" modules available, we cannot recognize what users can or cannot use when providing input parameters to KEB. In that phase, KEB has no way to validate that.

kyma-bot commented 7 months ago

This issue or PR has been automatically marked as stale due to the lack of recent activity. Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

After 60d of inactivity, lifecycle/stale is applied
After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle stale
Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale

kyma-bot commented 7 months ago

This issue or PR has been automatically closed due to the lack of activity. Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

After 60d of inactivity, lifecycle/stale is applied
After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

Reopen this issue or PR with /reopen
Mark this issue or PR as fresh with /remove-lifecycle stale

If you think that I work incorrectly, kindly raise an issue with the problem.

/close

kyma-bot commented 7 months ago

@kyma-bot: Closing this issue.

In response to [this](https://github.com/kyma-project/control-plane/issues/3027#issuecomment-1850038494): >This issue or PR has been automatically closed due to the lack of activity. >Thank you for your contributions. > >This bot triages issues and PRs according to the following rules: >- After 60d of inactivity, `lifecycle/stale` is applied >- After 7d of inactivity since `lifecycle/stale` was applied, the issue is closed > >You can: >- Reopen this issue or PR with `/reopen` >- Mark this issue or PR as fresh with `/remove-lifecycle stale` > >If you think that I work incorrectly, kindly [raise an issue](https://github.com/kyma-project/test-infra/issues/new/choose) with the problem. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

kyma-project / control-plane

Default modules and configurable module list in KEB #3027