<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 8, 2017 at 6:09 AM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Today I had a productive hallway discussion with jtomasek and<br>
stevebaker re $subject, so I wanted to elaborate here for the benefit<br>
of those folks not present. Hopefully we can get feedback on the<br>
ideas and see if it makes sense to continue and work on some patches:<br>
<br>
The problem under discussion is how do we run pre-deployment workflows<br>
(such as those integrated recently to calculate derived parameters,<br>
and in future perhaps also those which download container images etc),<br>
and in particular how do we make these discoverable via the UI<br>
(including any input parameters).<br>
<br>
The idea we came up with has two parts:<br>
<br>
1. Add a new optional section to roles_data for services that require<br>
pre-deploy workflows<br>
<br>
E.g something like this:<br>
<br>
pre_deploy_workflows:<br>
- derive_params:<br>
workflow_name:<br>
tripleo.derive_params_<wbr>formulas.v1.dpdk_derive_params<br>
inputs:<br>
...<br>
<br>
This would allow us to associate a specific mistral workflow with a<br>
given service template, and also work around the fact that currently<br>
mistral inputs don't have any schema (only key/value input) as we<br>
could encode the required type and any constraints in the inputs block<br>
(clearly this could be removed in future should typed parameters<br>
become available in mistral).<br>
<br>
2. Add a new workflow that calculates the enabled services and returns<br>
all pre_deploy_workflows<br>
<br>
This would take all enabled environments, then use heat to validate<br>
the configuration and return the merged resource registry (which will<br>
require <a href="https://review.openstack.org/#/c/509760/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/509760/</a>), then we would<br>
iterate over all enabled services in the registry and extract a given<br>
roles_data key (e.g pre_deploy_workflows)<br>
<br>
The result of the workflow would be a list of all pre_deploy_workflows<br>
for all enabled services, which the UI could then use to run the<br>
workflows as part of the pre-deploy process.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>pre-deploy-workflows.yaml</div><div>- name: my.workflow</div><div> services: a, b, c, d</div><div><br></div><div>Maybe there is a better way, maybe this is not even needed. I am not sure. What do you think?<br></div><div><br></div><div><br></div><div>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.</div><div><br></div><div>The resulting deployment configuration steps in GUI would look following:</div><div><br></div><div>1/ Hardware (reg. nodes, introspect etc)</div><div><br></div><div>2/ High level deployment configuration (basically selecting additional environment files)</div><div><br></div><div>3/ Roles management (Roles selection, roles -> nodes assignment, roles configuration - setting roles_data properties)</div><div><br></div><div>4/ Network configuration - network configuration wizard: (I'll describe this in separate email)</div><div><br></div><div>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.</div><div><br></div><div>6/ Advanced deployment config - a view providing a way to review Environment/Roles/Services parameters, search and tweak them if needed.</div><div><br></div><div>7/ Deploy.</div><div><br></div><div>I believe these steps should cover anything we should need to do for deployment configuration.</div><div><br></div><div>-- Jirka</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If this makes sense I can go ahead and push some patches so we can<br>
iterate on the implementation?<br>
<br>
Thanks,<br>
<br>
Steve<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div></div>