[openstack-dev] [TripleO] Next steps for pre-deployment workflows (e.g derive parameters)

Steven Hardy shardy at redhat.com
Thu Nov 9 01:21:24 UTC 2017

On Wed, Nov 8, 2017 at 10:55 PM, James Slagle <james.slagle at gmail.com> wrote:
> On Wed, Nov 8, 2017 at 7:16 AM, James Slagle <james.slagle at gmail.com> wrote:
>> 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).
> After chatting with jtomasek on irc, I wanted to clarify that the part
> of this proposal I'm hesitant about.
> Specifically, it's adding an interface for any service to specify a
> mistral workflow, that in theory could do anything, as part of a
> pre_deploy interface "contract". If we do offer such an interface, I
> think it ought to be driven via ansible tasks/plays that are available
> as Heat stack outputs to match the config-download pattern.

Thanks for the feedback, yes I agree if we can do this with pure
ansible that would be great, but we'll have to take a closer look at
the existing implementation, e.g as mentioned by Saravanan there is an
existing integration with mistral workflows, which we'll either have
to maintain or migrate away from.

> Perhaps for just deriving parameters, having a way to specify
> workflows for the UI is Ok. It's more of the generic interface I'm not
> so keen on. As it relates to your example of downloading container
> images, it seems we could have a generic ansible task to do that, that
> could then be executed with Mistral for API purposes instead of
> specifying the Mistral workflow directly in the templates/roles_data.

Yeah good point, and also the point about CI moving towards undercloud
deploy is a good one - if we can work out a way to do this via ansible
(even if that means ansible running a mistral workflow as a
transitional step?) that would certainly be easier.

Hopefully we can chat more about this on IRC next week and prototype
the ansible approach to see how it could work.



More information about the OpenStack-dev mailing list