Open Stack

On 11/8/17 6:09 AM, Steven Hardy 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?

I apologise for a generic/non-techy comment: it would be nice to keep 
required workflows near the services' definition templates, to keep it 
as much self-contained as possible. IIUC, that's covered by #1.
For future steps, I'd like to see all of the "bulk processing" to sit in 
those templates as well.

> 
> Thanks,
> 
> Steve
> 
> __________________________________________________________________________
> 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
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando