The use case is:
* given a set of VM instances on generic openstack cloud provider, deployed either as a heat stack or the like (for example, like Traas does for RDO cloud) and given access creds/url to that cloud;
* given a dynamic openstack inventory generated by openstack.py from ansible repo;
* given a custom ansible play comprising quickstart/extras roles, with custom vars included.
* to deploy a multinode (like tripleo-ci multinode scenarios do for nodepool), based on the deployed-server quickstart-extras role;
* and having applied the following shortcuts for development environments/hacking/testing WIP patches:
* No images/containers/packages to be built, no VMs provisioned with Ironic, and no repos or images to be injected (the deployed-server extras role covers that case, it seems)
Caveats:
* No tripleo-ci/quickstart shell scripts used, only ansible-playbook commands wanted.
* Deployment split into the steps: an undercloud may be deployed as a separate, then deployment continued to finish multinode overcloud as well.
Note, this is not related to OVB/CI devmode RFEs like https:/ /bugs.launchpad .net/tripleo/ +bug/1657191
The use case is: hacking/ testing WIP patches: containers/ packages to be built, no VMs provisioned with Ironic, and no repos or images to be injected (the deployed-server extras role covers that case, it seems)
* given a set of VM instances on generic openstack cloud provider, deployed either as a heat stack or the like (for example, like Traas does for RDO cloud) and given access creds/url to that cloud;
* given a dynamic openstack inventory generated by openstack.py from ansible repo;
* given a custom ansible play comprising quickstart/extras roles, with custom vars included.
* to deploy a multinode (like tripleo-ci multinode scenarios do for nodepool), based on the deployed-server quickstart-extras role;
* and having applied the following shortcuts for development environments/
* No images/
Caveats: ci/quickstart shell scripts used, only ansible-playbook commands wanted.
* No tripleo-
* Deployment split into the steps: an undercloud may be deployed as a separate, then deployment continued to finish multinode overcloud as well.