Compass Manager - prepare migration plan for moving from the architecture based on the Provisioner

[akgalwas]

In the current architecture the Provisioner is responsible for registering Runtimes and preparing Config Map for Compass Runtime Agent. There is a need to prepare a detailed plan how to switch from the current architecture to the new one based on the Compass Manager.

Cover the following:

• What will be the phases of migration?
• Would there be a need to distinguish Kyma resources representing new and migrated Runtimes? Would KEB need to behave differently?
• Consider whether we need to perform any steps in a maintenance window?

[kyma-bot]

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]

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]

@kyma-bot: Closing this issue.

In response to this:

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[akgalwas]

There are the following assumptions concerting the Compass Manager Operator:

• it watches Kyma resource
• it should start registration if Application Connector module is enabled
• it should handle registration, and configuration secret creation as follows:
  • register runtime, and create configuration secret for CRA if the runtime was not registered previously
  • fetch one time token from Compass, and update secret if the runtime was already registered

The open questions:

• Where the Compass Runtime ID will be stored? In the first approach we planned to label Kyma resource, but it was agreed to not do so. Should there be some additional resource? A: it makes sense to add a new resource storing a mapping:
  • it will store compass-runtime-id, ''subaccount-id` and 'runtime-id' in labels
  • it will have the same name as Kyma resource
• How we can verify whether Runtime was registered already? Mind that in trials scenario runtime may be removed and recreated at a later time. A: if the new custom resource exists we can assume that the runtime is registered already
• How long one time token for runtime lives? A: 1 h
• Is it possible to fetch one time token without runtimeID? Will subouccountID suffice? A: It is possible, but we need to have Compass Runtime ID to delete the runtime. A: runtimeID is not needed for fetching one time token
• How synchronisation between Kyma CR in runtime, and Control Plane works? A: changes done in SKR are propagated to the Control Plane.