Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resorting Instance CR .md #466

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 30 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -950,7 +950,37 @@ Do not call this API with the service-operator-access plan credentials.

<b>Attention: **Use this option only for cleanup purposes for a cluster that's no longer available.** Applying it to an active and available cluster may result in unintended resource leftovers in your cluster.</b>

### I can see my service instance in SAP BTP, but not its corresponding custom resource in a cluster. What can I do?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see my service instance in SAP BTP, but not its corresponding custom resource my cluster. How can I restore it in the cluster?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kerenlahav I think Avi wanted a more generally-worded question, but I changed.


Let's break down how to recover your Kubernetes custom resource that exists in SAP BTP but not in your Kubernetes cluster:

#### Background

The service instance in SAP BTP acts as the source of truth for your CR's configuration and state. By recreating the CR in Kubernetes with the exact same name, namespace, and cluster ID, you do not trigger the provisioning of a new service instance, but essentially re-establish the link between the Kubernetes representation and its existing counterpart in SAP BTP.

#### Steps

1. Retrieve CR Details:

a) Access the service instance representing your CR in SAP BTP.

b) Obtain the following details from the service instance:

- The name of the custom resource.
- The Kubernetes namespace where the CR should reside.
- If applicable, retrieve the cluster ID or context associated with the CR in SAP BTP. This ensures the CR is recreated in the correct environment.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kerenlahav I assume you are talking about removing the third one.


2. Recreate the CR:

a) If you have a YAML definition or manifest for your CR, ensure it includes the exact name, namespace, and (if applicable) cluster ID you retrieved from the SAP BTP service instance.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cluster id is not configurable in the CR yaml, it is part of the deployment config.
the cluster id usally does not change (we have a code that ensures that) so i would not put this step, i would mention it only if verification step failed. (if the instance in the cluster does not have the same instance id as the BTP instance verify the cluster id matches (it is part of the context and visibile in the cockpit or btp cli), if it does not match then configure the cluster with the right id...)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kerenlahav pls check the new commit. Thanks


b) Use `kubectl apply -f <your_cr_manifest.yaml>` to create the CR in your Kubernetes cluster.

3. Verify:

a) Use `kubectl get <your_cr_kind> <your_cr_name> -n <your_namespace>` to verify that the CR is successfully created in Kubernetes.

b) Check the service instance in SAP BTP to confirm that it now recognizes the re-established connection with the CR in Kubernetes.


You're welcome to raise issues related to feature requests, or bugs, or give us general feedback on this project's GitHub Issues page.
Expand Down
Loading