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 <skram...@redhat.com> wrote: > On Thu, Nov 9, 2017 at 2:57 AM, Jiri Tomasek <jtoma...@redhat.com> wrote: >> >> >> On Wed, Nov 8, 2017 at 6:09 AM, Steven Hardy <sha...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev