mirror of
https://github.com/open-cluster-management-io/ocm.git
synced 2026-08-19 04:06:35 +00:00
doc: fix argocd pull solution not using the right context (#659)
Signed-off-by: Mike Ng <ming@redhat.com>
This commit is contained in:
@@ -21,3 +21,7 @@ The pull model may offers some advantages over the existing push model:
|
||||
|
||||
This ArgoCD pull model controller on the Hub cluster will create [ManifestWork](https://open-cluster-management.io/concepts/manifestwork/) objects wrapping Application objects as payload.
|
||||
The OCM agent on the Managed cluster will see the ManifestWork on the Hub cluster and pull the Application down.
|
||||
|
||||
## Quick Start
|
||||
|
||||
See the [Getting Started](./getting-started.md) for a quick start guide.
|
||||
|
||||
@@ -38,6 +38,7 @@
|
||||
|
||||
2. If your controller starts successfully, you should see:
|
||||
```
|
||||
$ kubectl config use-context kind-hub
|
||||
$ kubectl -n open-cluster-management get deploy | grep pull
|
||||
argocd-pull-integration-controller-manager 1/1 1 1 106s
|
||||
```
|
||||
@@ -45,6 +46,7 @@
|
||||
3. On the Hub cluster, create ArgoCD cluster secrets that represent the managed clusters. This step can be automated with [OCM auto import controller](https://github.com/open-cluster-management-io/multicloud-integrations/).
|
||||
|
||||
```
|
||||
kubectl config use-context kind-hub
|
||||
for i in "cluster1" "cluster2"
|
||||
do
|
||||
cat <<EOF | kubectl apply -f -
|
||||
@@ -80,6 +82,7 @@
|
||||
|
||||
6. On the Hub cluster, apply the `guestbook-app-set` manifest:
|
||||
```
|
||||
kubectl config use-context kind-hub
|
||||
kubectl apply -f example/guestbook-app-set.yaml
|
||||
```
|
||||
**Note:** The Application template inside the ApplicationSet must contain the following content:
|
||||
@@ -98,17 +101,19 @@
|
||||
|
||||
7. When this guestbook ApplicationSet reconciles, it will generate an Application for the registered managed clusters. For example:
|
||||
```
|
||||
$ kubectl config use-context kind-hub
|
||||
$ kubectl -n argocd get appset
|
||||
NAME AGE
|
||||
guestbook-app 84s
|
||||
$ kubectl -n argocd get app
|
||||
NAME SYNC STATUS HEALTH STATUS
|
||||
cluster1-guestbook-app Synced Healthy
|
||||
cluster2-guestbook-app Synced Healthy
|
||||
cluster1-guestbook-app
|
||||
cluster2-guestbook-app
|
||||
```
|
||||
|
||||
8. On the Hub cluster, the pull controller will wrap the Application with a ManifestWork. For example:
|
||||
```
|
||||
$ kubectl config use-context kind-hub
|
||||
$ kubectl -n cluster1 get manifestwork
|
||||
NAME AGE
|
||||
cluster1-guestbook-app-d0e5 2m41s
|
||||
@@ -116,6 +121,7 @@
|
||||
|
||||
9. On a managed cluster, you should see that the Application is pulled down successfully. For example:
|
||||
```
|
||||
$ kubectl config use-context kind-cluster1
|
||||
$ kubectl -n argocd get app
|
||||
NAME SYNC STATUS HEALTH STATUS
|
||||
cluster1-guestbook-app Synced Healthy
|
||||
@@ -126,9 +132,10 @@
|
||||
|
||||
10. On the Hub cluster, the status controller will sync the dormant Application with the ManifestWork status feedback. For example:
|
||||
```
|
||||
$ kubectl config use-context kind-hub
|
||||
$ kubectl -n argocd get app
|
||||
NAME SYNC STATUS HEALTH STATUS
|
||||
cluster1-guestbook-app Synced Healthy
|
||||
cluster2-guestbook-app Synced Healthy
|
||||
```
|
||||
If you have issues or need help troubleshooting, check out the [troubleshooting guide](./troubleshooting.md)
|
||||
If you have issues or need help troubleshooting, check out the [troubleshooting guide](./troubleshooting.md)
|
||||
|
||||
@@ -16,4 +16,3 @@ status:
|
||||
type: ErrorOccurred
|
||||
```
|
||||
Despite the type `ErrorOccurred`, the status is `"False"`, which means the ApplicationSet has been reconciled successfully. If the status is `"True"`, check the error message. If needed, check the `argocd-applicationset-controller` pod logs in the `argocd` namespace.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user