Open Stack

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:
>>
>>      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.
>
>
> 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.
>
> pre-deploy-workflows.yaml
> - 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
workflow?

>
> 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?
Agreed.

Regards,
Saravanan KR

>>
>> 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
>
>
>
> __________________________________________________________________________
> 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
>