st 20. 9. 2017 v 19:37 odesílatel James Slagle <james.sla...@gmail.com> napsal:
> 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. 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ 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