Clarify the ansible playbook vs cloud-init

Document use cases for custom post-provision ansible hooks
vs cloud-init runcmd shell commands. Rename to
openshift_openstack_cloud_init_runcmd.

Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>

1 files changed, 27 insertions, 3 deletions

diff --git a/playbooks/openstack/advanced-configuration.md b/playbooks/openstack/advanced-configuration.md
index fee402b32..788a74f45 100644
--- a/playbooks/openstack/advanced-configuration.md
+++ b/playbooks/openstack/advanced-configuration.md
@@ -273,9 +273,33 @@ openshift_openstack_cluster_node_labels:
     mylabel: myvalue
 ```
 
-`openshift_openstack_provision_user_commands` allows users to execute
-additional post-provisioning commands for all of the created Nova servers in
-the Heat stack. It configures the `runcmd` directive via cloud-init.
+`openshift_openstack_cloud_init_runcmd` allows users to execute
+shell commands via cloud-init for all of the created Nova servers in
+the Heat stack, before they are available for SSH connections.
+Note that you should better off using custom ansible playbooks whenever
+possible, like this `provision_install_custom.yml` example playbook:
+```
+- import_playbook: openshift-ansible/playbooks/openstack/openshift-cluster/provision.yml
+
+- name: My custom actions
+  hosts: cluster_hosts
+  tasks:
+  - do whatever you want here
+
+- import_playbook: openshift-ansible/playbooks/openstack/openshift-cluster/install.yml
+```
+The playbook leverages a two existing provider interfaces: `provision.yml` and
+`install.yml`. For some cases, like SSH keys configuration and coordinated reboots of
+servers, the cloud-init runcmd directive may be a better choice though. User specified
+shell commands for cloud-init need to be lists, for example:
+```
+- openshift_openstack_cloud_init_runcmd:
+  - ['echo', 'foo']
+  - ['reboot']
+```
+The commands should not use JSON escaped characters: `> < & '`. So the command
+`['foo', '>', '"bar"', '<', "'baz'", "&"]` is a bad one, while
+`['echo', '"${HOME}"']` is OK.
 
 The `openshift_openstack_nodes_to_remove` allows you to specify the numerical indexes
 of App nodes that should be removed; for example, ['0', '2'],