Open Stack

As discussed in IRC, I have collated all the important discussions to
the etherpad (gdoc was not publicly shareable).

https://etherpad.openstack.org/p/tripleo-derive-parameters-v2

Lets continue discussion on the etherpad to finalize.

Regards,
Saravanan KR

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