Open Stack

st 20. 9. 2017 v 19:37 odesílatel James Slagle <james.slagle at gmail.com>
napsal:

> On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente <gfidente at 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.


Mistral workflow's input could hold a list of steps that would define which
deploy steps ansible is going to go through. Is that correct assumption? On
undercloud installation list of steps would be provided by CLI.


>
> 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.


Could an external playbook be triggered as a custom step provided in
Mistral workflow input I mention above?


>
> >> - 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.
>
>
> --
> -- James Slagle
> --


-- Jiri Tomasek


> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170921/7d528d21/attachment.html>