(cross-posting) James and I created this etherpad: https://etherpad.openstack.org/p/tripleo-config-download which tracks work in progress for the config download efforts.
Please let us know any question on that topic, On Mon, Sep 25, 2017 at 5:28 PM, Dan Prince <dpri...@redhat.com> wrote: > > > On Thu, Sep 21, 2017 at 8:53 AM, Jiří Stránský <ji...@redhat.com> wrote: >> >> 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. > > > This was the idea that had the most traction at the PTG when we discussed > it. Things can still be interleaved across the installers (stepwise) but we > effectively eliminate the complexity of having multiple tools involved > within the main deploy step loop as you described it. > > I think we should consider making it so that the main Ansible loop can call > any external installer in a stepwise fashion though. It doesn't have to be > just Ansible it calls. In this manner we would be supporting calling into > multiple phases of an external installer. > > During the undercloud deployment we get all the benefits of Ansible driving > our primary deployment loop and can still call into external installers like > Kubernetes if we want to. On the overcloud we'd still be leveraging the high > level Mistral workflow to kick off the initial Ansible playbooks... but once > that happens it would be Ansible driving any external installers directly. > > Dan > >> >> >> 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 > > > > __________________________________________________________________________ > 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 > -- Emilien Macchi __________________________________________________________________________ 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
