From d2fc989febd3d39e4584287f7a075692a7d4c523 Mon Sep 17 00:00:00 2001 From: Nicolas Bigler Date: Thu, 30 Nov 2023 15:38:24 +0100 Subject: [PATCH] Refactor docs Signed-off-by: Nicolas Bigler --- component/class/defaults.yml | 2 +- .../appcat/20_role_vshn_mariadb_restore.yaml | 2 +- .../runbooks/vshn-helm-debugging-partial.adoc | 45 +++++++++++++++++++ .../ROOT/pages/runbooks/vshn-mariadb.adoc | 45 +------------------ .../ROOT/pages/runbooks/vshn-minio.adoc | 45 +------------------ .../ROOT/pages/runbooks/vshn-redis.adoc | 45 +------------------ docs/modules/ROOT/partials/nav.adoc | 6 +++ 7 files changed, 59 insertions(+), 131 deletions(-) create mode 100644 docs/modules/ROOT/pages/runbooks/vshn-helm-debugging-partial.adoc diff --git a/component/class/defaults.yml b/component/class/defaults.yml index 6b2749421..c5dc71e7f 100644 --- a/component/class/defaults.yml +++ b/component/class/defaults.yml @@ -71,7 +71,7 @@ parameters: - apiGroups: - vshn.appcat.vshn.io resources: - - vshnredis + - "*" verbs: - get - apiGroups: diff --git a/component/tests/golden/vshn/appcat/appcat/20_role_vshn_mariadb_restore.yaml b/component/tests/golden/vshn/appcat/appcat/20_role_vshn_mariadb_restore.yaml index 6bf02c92f..fa13213fa 100644 --- a/component/tests/golden/vshn/appcat/appcat/20_role_vshn_mariadb_restore.yaml +++ b/component/tests/golden/vshn/appcat/appcat/20_role_vshn_mariadb_restore.yaml @@ -9,7 +9,7 @@ rules: - apiGroups: - vshn.appcat.vshn.io resources: - - vshnredis + - '*' verbs: - get - apiGroups: diff --git a/docs/modules/ROOT/pages/runbooks/vshn-helm-debugging-partial.adoc b/docs/modules/ROOT/pages/runbooks/vshn-helm-debugging-partial.adoc new file mode 100644 index 000000000..5d0f81c60 --- /dev/null +++ b/docs/modules/ROOT/pages/runbooks/vshn-helm-debugging-partial.adoc @@ -0,0 +1,45 @@ +=== icon:bug[] Steps for debugging + +Failed probes can have a multitude of reasons, but in general there are two different kinds of issue classes. +Either the instance itself is failing or provisioning or updating the instance failed. + +In any case, you should first figure out where the effected instance runs. +The alert will provide you with three labels: `cluster_id`, `namespace`, and `name`. +Connect to the Kubernetes cluster with the provided `cluster_id` and get the effected claim. + +[source,shell,subs="attributes"] +---- +export NAMESPACE={{ namespace }} +export NAME={{ name }} + +export COMPOSITE=$(kubectl -n $NAMESPACE get {service} $NAME -o jsonpath="{.spec.resourceRef.name}") +kubectl -n $NAMESPACE get {service} $NAME +---- + +If the claim is not `SYNCED` this might indicate that there is an issue with provisioning. +If it is synced there is most likely an issue with the instance itself, you can skip to the next subsection. + +==== Debugging Provisioning + +To figure out what went wrong with provisioning it usually helps to take a closer look at the composite. + +[source,shell,subs="attributes"] +---- +kubectl --as cluster-admin describe x{service} $COMPOSITE +---- + +If there are sync issues there usually are events that point to the root cause of the issue. + +Furthermore, it can help to look at the `Object` resources that are created for this instance or the `releases.helm.crossplane.io` object associated with the instance. + +[source,shell] +---- +kubectl --as cluster-admin get object -l crossplane.io/composite=$COMPOSITE +kubectl --as cluster-admin get object $OBJECT_NAME +kubectl --as cluster-admin get releases.helm.crossplane.io -l crossplane.io/composite=$COMPOSITE +kubectl --as cluster-admin describe releases.helm.crossplane.io -l crossplane.io/composite=$COMPOSITE +---- + +If any of them are not synced, describing them should point you in the right direction. + +Finally, it might also be helpful to look at the logs of various crossplane components in namespace `syn-crossplane`. diff --git a/docs/modules/ROOT/pages/runbooks/vshn-mariadb.adoc b/docs/modules/ROOT/pages/runbooks/vshn-mariadb.adoc index 64d29bc8d..02c57d80e 100644 --- a/docs/modules/ROOT/pages/runbooks/vshn-mariadb.adoc +++ b/docs/modules/ROOT/pages/runbooks/vshn-mariadb.adoc @@ -24,49 +24,8 @@ A ticket alert should have a label `severity: warning`. * A page alert means that the error rate is significantly higher than the objective. Immediate action is necessary to not miss the objective. -=== icon:bug[] Steps for debugging - -Failed probes can have a multitude of reasons, but in general there are two different kinds of issue clases. -Either the instance itself is failing or provisioning or updating the instance failed. - -In any case, you should first figure out where the effected instance runs. -The alert will provide you with three labels: `cluster_id`, `namespace`, and `name`. - -Connect to the Kubernetes cluster with the provided `cluster_id` and get the effected claim. - -[source,shell] ----- -export NAMESPACE={{ namespace }} -export NAME={{ name }} - -export COMPOSITE=$(kubectl -n $NAMESPACE get vshnmariadb $NAME -o jsonpath="{.spec.resourceRef.name}") -kubectl -n $NAMESPACE get vshnmariadb $NAME ----- - -If the claim is not `SYNCED` this might indicate that there is an issue with provisioning. -If it is synced there is most likely an issue with the instance itself, you can skip to the next subsection. - -==== Debugging Provisioning - -To figure out what went wrong with provisioning it usually helps to take a closer look at the composite. - -[source,shell] ----- -kubectl --as cluster-admin describe xvshnmariadb $COMPOSITE ----- - -If there are sync issues there usually are events that point to the root cause of the issue. - -Further it can help to look at the `Object` resources that are created for this instance. - -[source,shell] ----- -kubectl --as cluster-admin get object -l crossplane.io/composite=$COMPOSITE ----- - -If any of them are not synced, describing them should point you in the right direction. - -Finally, it might also be helpful to look at the logs of various crossplane components in namespace `syn-crossplane`. +:service: vshnmariadb +include::vshn-helm-debugging-partial.adoc[] ==== Debugging MariaDB Instance diff --git a/docs/modules/ROOT/pages/runbooks/vshn-minio.adoc b/docs/modules/ROOT/pages/runbooks/vshn-minio.adoc index 148fc70c6..bdfe67b8c 100644 --- a/docs/modules/ROOT/pages/runbooks/vshn-minio.adoc +++ b/docs/modules/ROOT/pages/runbooks/vshn-minio.adoc @@ -24,49 +24,8 @@ A ticket alert should have a label `severity: warning`. * A page alert means that the error rate is significantly higher than the objective. Immediate action is necessary to not miss the objective. -=== icon:bug[] Steps for debugging - -Failed probes can have a multitude of reasons, but in general there are two different kinds of issue clases. -Either the instance itself is failing or provisioning or updating the instance failed. - -In any case, you should first figure out where the effected instance runs. -The alert will provide you with three labels: `cluster_id`, `namespace`, and `name`. - -Connect to the Kubernetes cluster with the provided `cluster_id` and get the effected claim. - -[source,shell] ----- -export NAMESPACE={{ namespace }} -export NAME={{ name }} - -export COMPOSITE=$(kubectl -n $NAMESPACE get vshnminio $NAME -o jsonpath="{.spec.resourceRef.name}") -kubectl -n $NAMESPACE get vshnminio $NAME ----- - -If the claim is not `SYNCED` this might indicate that there is an issue with provisioning. -If it is synced there is most likely an issue with the instance itself, you can skip to the next subsection. - -==== Debugging Provisioning - -To figure out what went wrong with provisioning it usually helps to take a closer look at the composite. - -[source,shell] ----- -kubectl --as cluster-admin describe xvshnminio $COMPOSITE ----- - -If there are sync issues there usually are events that point to the root cause of the issue. - -Further it can help to look at the `Object` resources that are created for this instance. - -[source,shell] ----- -kubectl --as cluster-admin get object -l crossplane.io/composite=$COMPOSITE ----- - -If any of them are not synced, describing them should point you in the right direction. - -Finally, it might also be helpful to look at the logs of various crossplane components in namespace `syn-crossplane`. +:service: vshnminio +include::vshn-helm-debugging-partial.adoc[] ==== Debugging MinIO Instance diff --git a/docs/modules/ROOT/pages/runbooks/vshn-redis.adoc b/docs/modules/ROOT/pages/runbooks/vshn-redis.adoc index 745f21aea..b934b3a26 100644 --- a/docs/modules/ROOT/pages/runbooks/vshn-redis.adoc +++ b/docs/modules/ROOT/pages/runbooks/vshn-redis.adoc @@ -24,49 +24,8 @@ A ticket alert should have a label `severity: warning`. * A page alert means that the error rate is significantly higher than the objective. Immediate action is necessary to not miss the objective. -=== icon:bug[] Steps for debugging - -Failed probes can have a multitude of reasons, but in general there are two different kinds of issue clases. -Either the instance itself is failing or provisioning or updating the instance failed. - -In any case, you should first figure out where the effected instance runs. -The alert will provide you with three labels: `cluster_id`, `namespace`, and `name`. - -Connect to the Kubernetes cluster with the provided `cluster_id` and get the effected claim. - -[source,shell] ----- -export NAMESPACE={{ namespace }} -export NAME={{ name }} - -export COMPOSITE=$(kubectl -n $NAMESPACE get vshnredis $NAME -o jsonpath="{.spec.resourceRef.name}") -kubectl -n $NAMESPACE get vshnredis $NAME ----- - -If the claim is not `SYNCED` this might indicate that there is an issue with provisioning. -If it is synced there is most likely an issue with the instance itself, you can skip to the next subsection. - -==== Debugging Provisioning - -To figure out what went wrong with provisioning it usually helps to take a closer look at the composite. - -[source,shell] ----- -kubectl --as cluster-admin describe xvshnredis $COMPOSITE ----- - -If there are sync issues there usually are events that point to the root cause of the issue. - -Further it can help to look at the `Object` resources that are created for this instance. - -[source,shell] ----- -kubectl --as cluster-admin get object -l crossplane.io/composite=$COMPOSITE ----- - -If any of them are not synced, describing them should point you in the right direction. - -Finally, it might also be helpful to look at the logs of various crossplane components in namespace `syn-crossplane`. +:service: vshnminio +include::vshn-helm-debugging-partial.adoc[] ==== Debugging Redis Instance diff --git a/docs/modules/ROOT/partials/nav.adoc b/docs/modules/ROOT/partials/nav.adoc index bfd915bcf..74f84e9e1 100644 --- a/docs/modules/ROOT/partials/nav.adoc +++ b/docs/modules/ROOT/partials/nav.adoc @@ -34,3 +34,9 @@ .Runbooks * xref:runbooks/vshn-postgresql.adoc[] +* xref:runbooks/vshn-redis.adoc[] +* xref:runbooks/vshn-minio.adoc[] +* xref:runbooks/vshn-mariadb.adoc[] +* xref:runbooks/vshn-generic.adoc[] + +