Open Stack

On Wed, Nov 8, 2017 at 12:09 AM, Steven Hardy <shardy at redhat.com> wrote:
> Hi all,
>
> Today I had a productive hallway discussion with jtomasek and
> stevebaker re $subject, so I wanted to elaborate here for the benefit
> of those folks not present.  Hopefully we can get feedback on the
> ideas and see if it makes sense to continue and work on some patches:
>
> The problem under discussion is how do we run pre-deployment workflows
> (such as those integrated recently to calculate derived parameters,
> and in future perhaps also those which download container images etc),
> and in particular how do we make these discoverable via the UI
> (including any input parameters).
>
> The idea we came up with has two parts:
>
> 1. Add a new optional section to roles_data for services that require
> pre-deploy workflows
>
> E.g something like this:
>
>      pre_deploy_workflows:
>         - derive_params:
>               workflow_name:
> tripleo.derive_params_formulas.v1.dpdk_derive_params
>               inputs:
>                   ...
>
> This would allow us to associate a specific mistral workflow with a
> given service template, and also work around the fact that currently
> mistral inputs don't have any schema (only key/value input) as we
> could encode the required type and any constraints in the inputs block
> (clearly this could be removed in future should typed parameters
> become available in mistral).
>
> 2. Add a new workflow that calculates the enabled services and returns
> all pre_deploy_workflows
>
> This would take all enabled environments, then use heat to validate
> the configuration and return the merged resource registry (which will
> require https://review.openstack.org/#/c/509760/), then we would
> iterate over all enabled services in the registry and extract a given
> roles_data key (e.g pre_deploy_workflows)
>
> The result of the workflow would be a list of all pre_deploy_workflows
> for all enabled services, which the UI could then use to run the
> workflows as part of the pre-deploy process.
>
> If this makes sense I can go ahead and push some patches so we can
> iterate on the implementation?

Instead of using mistral to express the pre_deploy workflows could we
just use pure ansible tasks/playbooks? We already use pure ansible for
upgrade and deploy, it seems disjointed to then require Mistral for
pre-deploy.

I think we should continue to move in the direction that the output
from Heat is ansible, which can then be driven via either Mistral or
ad-hoc via ansible-playbook. That pattern is more aligned with the
existing work around config-download as well. So, we would have a
Mistral workflow that automates what you describe above, *except* for
the detail that pre_deploy_workflows becomes either pre_deploy_tasks
or pre_deploy_playbooks, and the output of the Heat validation step is
pure ansible.

>From the UI's perspective, whether the output from Heat is pure
ansible or mistral workflows should be an implementation detail hidden
behind a higher level mistral workflow that automates the full
"generation" of all pre_deploy stuff.

Also keep in mind Emilien's proposal to switch all scenario testing to
be driven via undercloud deploy. In that environment, there is no
Mistral, and everything is driven via config-download. What you're
proposing (unless I misunderstand) creates a tight coupling between
the Heat/Mistral ordering and requires one to use Mistral as part of
the deployment. Right now, we have no such requirement, and are able
to drive a deployment with only an ephemeral Heat and
ansible-playbook, which is the basis of how undercloud deploy works.

-- 
-- James Slagle
--