In multicloud-deployment/labs/6.md a command is given to deploy the app,

cd assets/app/acm
oc --context hub apply -f .

This doesn't match the repo as it is.

After cloning, the path would be labs/multicloud-deployment/acm

As it stands, the multicloud lab successfully deploys a simple app to each cluster, but does not use an Application object to manage it.

Hi @mvazquezc - great lab, we are working through to validate it.
I'm wondering if it would be too much effort to ask that we remove (at least as much as possible) your mvazquezc shortname from the name of the resources? eg, rather than:

A Channel named mvazquez-gitops-github

we would instead choose "A Channel named acm-gitops-github" ...

See this for notes and instructions:

https://github.com/openshift/federation-dev/blob/master/labs/7.md#deploying-haproxy

In the multicloud example, placement rules and subscriptions are namespaced to the appropriate cloud based app namespaces, e.g. aws-apache-test The 01_general_channel.yaml is not namespaced, and ends up in default. Looking in the UI -> Applications -> Resources tab, you can see the apache-channel with 0 subscriptions.

Creating another instance of the apache-channel from 01_general_channel.yaml in the aws-apache-test namespace does succeed in attaching the subscription at which point the application deploys.

There is a link in multicloud-deployment/labs/1.md to https://quay.io/open-cluster-management/multiclusterhub-operator-index
which is 403 for me.

Based on some Slack chat, I think the link may no longer be appropriate given downstream release. fyi

In multicloud-deployment/labs/6.md, cluster contexts are set up first as $cloudprovider-spoke but then used later as $cloudprovider-admin. I actually reflexively set up my own contexts first as -admin because it made sense to, e.g. s/admin/aws-admin/ Perhaps that's the best choice, though -spoke is clearer.