[openstack-dev] [TripleO] Next steps for pre-deployment workflows (e.g derive parameters)
skramaja at redhat.com
Tue Nov 14 10:40:31 UTC 2017
As discussed in IRC, I have collated all the important discussions to
the etherpad (gdoc was not publicly shareable).
Lets continue discussion on the etherpad to finalize.
On Thu, Nov 9, 2017 at 11:05 AM, Saravanan KR <skramaja at redhat.com> wrote:
> On Thu, Nov 9, 2017 at 2:57 AM, Jiri Tomasek <jtomasek at redhat.com> wrote:
>> On Wed, Nov 8, 2017 at 6: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:
>>> - derive_params:
>>> 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.
>> As I think about this more, we may find out that matching a service to
>> workflow is not enough as workflow may require several services (together
>> defining a feature) So maybe doing it in separate file would help. E.g.
>> - name: my.workflow
>> services: a, b, c, d
>> Maybe there is a better way, maybe this is not even needed. I am not sure.
>> What do you think?
> Currently, HCI derive parameters workflow is invoked if a role has
> both NovaCompute and CephOSD services enabled.
>> What I really like about this proposal is that it provides a standard way to
>> configure deployment features and provides clear means to add additional
>> such configurations.
>> The resulting deployment configuration steps in GUI would look following:
>> 1/ Hardware (reg. nodes, introspect etc)
>> 2/ High level deployment configuration (basically selecting additional
>> environment files)
>> 3/ Roles management (Roles selection, roles -> nodes assignment, roles
>> configuration - setting roles_data properties)
>> 4/ Network configuration - network configuration wizard: (I'll describe
>> this in separate email)
>> 5/ Deployment Features configuration (This proposal) - a list of features to
>> configure, the list is nicely generated from information provided in
>> previous steps, user has all the information to configure those features at
>> hand and can go through these step by step.
> Agreed on the UI workflow.
> For DPDK and SR-IOV, there are common host specific parameters to be
> derived. It has been added as a separate host-specific parameters
> workflow. And both DPDK and SR-IOV workflow execution should follow
> host-specific workflow.
> In case of DPDK and HCI in same role, it is expected that DPDK
> workflow is executed before HCI. And the service configuration should
> provide this order to UI.
> I am not able to realize how this information will be provided and
> processed in UI with user. Do you have a UI wire frame for this
>> 6/ Advanced deployment config - a view providing a way to review
>> Environment/Roles/Services parameters, search and tweak them if needed.
>> 7/ Deploy.
>> I believe these steps should cover anything we should need to do for
>> deployment configuration.
>> -- Jirka
>>> If this makes sense I can go ahead and push some patches so we can
>>> iterate on the implementation?
> Saravanan KR
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev