On 21.9.2017 12:31, Giulio Fidente wrote:
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
Alternatively we could do the main step loop in Ansible directly, and
have the tasks do whatever they need to get the particular service
deployed, from to launching a nested ansible-playbook run if that's
what it takes.
That way we could run the whole thing end-to-end via ansible-playbook,
or if needed one could execute smaller bits by themselves (steps or
nested playbook runs) -- that capability is not baked in by default, but
i think we could make it so.
Also the interface for services would be clean and simple -- it's always
the ansible tasks.
And Mistral-less use cases become easier to handle too (= undercloud
installation when Mistral isn't present yet, or development envs when
you want to tune the playbook directly without being forced to go
through Mistral).
Logging becomes a bit more unwieldy in this scenario though, as for the
nested ansible-playbook execution, all output would go into a task in
the outer playbook, which would be harder to follow and the log of the
outer playbook could be huge.
So this solution is no silver bullet, but from my current point of view
it seems a bit less conceptually foreign than using Mistral to provide
step loop functionality to Ansible, which should be able to handle that
on its own.
- 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.
Indeed that would be great :) IIUC, APBs are deployed by running a
short-lived container with Ansible inside, which then connects to
Kubernetes endpoint to create resources. So this should be a less
complicated case than running non-containerized external playbooks.
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/
[1]
https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/blob/master/docs/design.md#deploy
__________________________________________________________________________
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
