On 09/20/2017 07:36 PM, James Slagle wrote: > On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente <gfide...@redhat.com> wrote: >> On 09/18/2017 05:37 PM, James Slagle wrote: >>> - The entire sequence and flow is driven via Mistral on the Undercloud >>> by default. This preserves the API layer and provides a clean reusable >>> interface for the CLI and GUI. >> >> I think it's worth saying that we want to move the deployment steps out >> of heat and in ansible, not in mistral so that mistral will run the >> workflow only once and let ansible go through the steps >> >> I think having the steps in mistral would be a nice option to be able to >> rerun easily a particular deployment step from the GUI, versus having >> them in ansible which is instead a better option for CLI users ... but >> it looks like having them in ansible is the only option which permits us >> to reuse the same code to deploy an undercloud because having the steps >> in mistral would require the undercloud installation itself to depend on >> mistral which we don't want to >> >> James, Dan, please comment on the above if I am wrong > > That's correct. We don't want to require Mistral to install the > Undercloud. However, I don't think that necessarily means it has to be > a single call to ansible-playbook. We could have multiple invocations > of ansible-playbook. Both Mistral and CLI code for installing the > undercloud could handle that easily. > > You wouldn't be able to interleave an external playbook among the > deploy steps however. That would have to be done under a single call > to ansible-playbook (at least how that is written now). We could > however have hooks that could serve as integration points to call > external playbooks after each step.
the benefits of driving the steps from mistral are that then we could also interleave the deployment steps and we won't need the ansible-playbook hook for the "external" services: 1) collect the ansible tasks *and* the workflow_tasks (per step) from heat 2) launch the stepN deployment workflow (ansible-playbook) 3) execute any workflow_task defined for stepN (like ceph-ansible playbook) 4) repeat 2 and 3 for stepN+1 I think this would also provide a nice interface for the UI ... but then we'd need mistral to be able to deploy the undercloud >>> - It would still be possible to run ansible-playbook directly for >>> various use cases (dev/test/POC/demos). This preserves the quick >>> iteration via Ansible that is often desired. >>> >>> - The remaining SoftwareDeployment resources in tripleo-heat-templates >>> need to be supported by config download so that the entire >>> configuration can be driven with Ansible, not just the deployment >>> steps. The success criteria for this point would be to illustrate >>> using an image that does not contain a running os-collect-config. >>> >>> - The ceph-ansible implementation done in Pike could be reworked to >>> use this model. "config download" could generate playbooks that have >>> hooks for calling external playbooks, or those hooks could be >>> represented in the templates directly. The result would be the same >>> either way though in that Heat would no longer be triggering a >>> separate Mistral workflow just for ceph-ansible. >> >> I'd say for ceph-ansible, kubernetes and in general anything else which >> needs to run with a standard playbook installed on the undercloud and >> not one generated via the heat templates... these "external" services >> usually require the inventory file to be in different format, to >> describe the hosts to use on a per-service basis, not per-role (and I >> mean tripleo roles here, not ansible roles obviously) >> >> About that, we discussed a more long term vision where the playbooks >> (static data) needd to describe how to deploy/upgrade a given service is >> in a separate repo (like tripleo-apb) and we "compose" from heat the >> list of playbooks to be executed based on the roles/enabled services; in >> this scenario we'd be much closer to what we had to do for ceph-ansible >> and I feel like that might finally allow us merge back the ceph >> deployment (or kubernetes deployment) process into the more general >> approach driven by tripleo >> >> James, Dan, comments? > > Agreed, I think this is the longer term plan in regards to using > APB's, where everything consumed is an external playbook/role. > > We definitely want to consider this plan in parallel with the POC work > that Flavio is pulling together and make sure that they are aligned so > that we're not constantly reworking the framework. > > I've not yet had a chance to review the material he sent out this > morning, but perhaps we could work together to update the sequence > diagram to also have a "future" state to indicate where we are going > and what it would look like with APB's and external paybooks. this would be awesome, note that it isn't only ceph and kubernetes anymore in this scenario ... I just spotted a submission for the Skydive composable service and it uses the same mistral/ansible-playbook approach ... so it's already 3 looking forward for this! https://review.openstack.org/#/c/502353/ -- Giulio Fidente GPG KEY: 08D733BA __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
