<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 2 February 2017 at 11:56, Jiri Tomasek <span dir="ltr"><<a href="mailto:jtomasek@redhat.com" target="_blank">jtomasek@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
there has been several ongoing efforts in TripleO regarding Deployment Plans management and Deployment configuration itself. A lot of this work is done to satisfy certain individual requirements but I think some further discussion needs to happen to make sure the solutions we create are effective for all parts of TripleO.<br>
<br>
There are several goals / features we currently aim for:<br>
- Define and manage custom Roles (GUI/CLI)<br>
- Define and manage networks (CLI/GUI)<br>
- Import/Export Deployment plans so it is possible to reuse them or use them as a reference/starting point<br>
<br>
Currently the Deployment plan stored in Swift consist of:<br>
- tripleo heat templates<br>
- roles_data.yaml - meta file used as an input to define roles (and assign networks to roles [1])<br>
- network_data.yaml - meta file used as input to define networks [2]<br>
- capabilities-map.yaml - meta file to describe THT environment files capabilities<br>
- mistral environment - json structure in Mistral which we use as a backend store accessible by mistral actions and workflows (tripleo-common)<br>
<br>
Currently, only possibility to configure roles and networks is by creating or updating the plan with changed meta files. We need to create Mistral actions to handle manipulating roles and networks so GUI (also CLI) can retrieve current roles/networks configuration and update it, which in turn will regenerate related templates. Now, the question arises: Do we want to use roles_data.yaml in Swift container as a storage for this information? I thought we agreed on using Mistral environment to store plan related data. (See here for additional context [3] )<br></blockquote><div><br></div><div>We did agree that, I do wonder if we should revisit that decision. Nobody else uses Mistral as a permanent, long term store. It wasn't designed for that purpose and I am not aware of anyone else using it like this. It also doesn't really give us any advantages (in reality, Mistral environments have far less features than Swift). Accessing Swift is just probably just as easy if not easier. So I think it might be worth considering moving everything to Swift and keeping everything in one place.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This means that on plan creation, we use roles_data.yaml (and network_data.yaml etc.) to populate Mistral environment and generate templates using this data. roles_data.yaml (and others) then need to be discarded because from this point on, the data will be updated in Mistral environment through tripleo-common actions. roles_data.yaml is therefore used just as a default which is used when plan is created (or updated).<br></blockquote><div><br></div><div>I think one of the mistakes we have made is to never fully model the data, we don't have any code in tripleo-common that abstracts the storage and defines how everything is stored. Instead we have a collection of actions that understand how the structure should look in different places. This means that as we have added new features, they all do everything a bit differently and I can see it becoming hard to maintain and update.<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Now, plan export comes into play [4]. We want to be able to pull down the plan and deploy it using CLI directly (which creates/updates plan as far as during deploy command), We want to be able to reuse the plan in other deployments or use it as a reference architecture for subsequent deployments. This means we don't only want to download the contents of Swift container, but also configuration stored in Mistral environment.<br></blockquote><div><br></div><div>If we did put everything in Swift, this bit would be much easier.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So Plan export action pulls down files from Swift container, adds meta files: roles_data.yaml, network_data.yaml... which it populates by looking at appropriate keys in Mistral environment + plan_environment.yaml which includes remaining data from Mistral environment such as parameter values, environments etc. All of those are then returned in a single tarball. Question to consider is whether to split all this data into separate files or keep it in single one.<br>
<br>
Plan Import [5] then allows to provide plan_environment.yaml to enable populating parameter values and environments selection during plan creation.<br>
<br>
<br>
Alternative solution is to store meta files (roles_data.yaml, network_data.yaml...) in Swift container and use those files as a data store which IMHO does not comply with decision to use Mistral environment as a plan data store. In that case we should probably get rid of using Mistral environment altogether and use plan_environment.yaml file in Swift container to store data which we currently store in Mistral environment. I am quite convinced that there have been good reasons to not to do this and use Mistral environment.<br></blockquote><div><br></div><div>I am not convinced. Can you remember any of these reasons? I can't?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
[1] <a href="https://review.openstack.org/#/c/409920/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/409920/</a><br>
[2] <a href="https://review.openstack.org/#/c/409921/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/409921/</a><br>
[3] <a href="https://review.openstack.org/#/c/409921/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/409921/</a><br>
[4] <a href="http://specs.openstack.org/openstack/tripleo-specs/specs/ocata/gui-plan-import-export.html#problem-description" rel="noreferrer" target="_blank">http://specs.openstack.org/ope<wbr>nstack/tripleo-specs/specs/oca<wbr>ta/gui-plan-import-export.html<wbr>#problem-description</a><br>
[5] <a href="https://blueprints.launchpad.net/tripleo/+spec/enhance-plan-creation-with-plan-environment-json" rel="noreferrer" target="_blank">https://blueprints.launchpad.n<wbr>et/tripleo/+spec/enhance-plan-<wbr>creation-with-plan-environment<wbr>-json</a><br>
<br>
<br>
-- Jirka<br>
<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote></div><br></div></div>