<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 2.2.2017 13:57, Ana Krivokapic
wrote:<br>
</div>
<blockquote
cite="mid:CAOUEErq85WWj_iu1dFkUBrg7FfEJYpqp2qVNZQ5cU2nRbcvbDg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Feb 2, 2017 at 1:46 PM,
Emilien Macchi <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:emilien@redhat.com"
target="_blank">emilien@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">On Thu, Feb 2, 2017 at 6:56 AM, Jiri
Tomasek <<a moz-do-not-send="true"
href="mailto:jtomasek@redhat.com">jtomasek@redhat.com</a>>
wrote:<br>
> Hello all,<br>
><br>
> there has been several ongoing efforts in TripleO
regarding Deployment Plans<br>
> management and Deployment configuration itself. A
lot of this work is done<br>
> to satisfy certain individual requirements but I
think some further<br>
> discussion needs to happen to make sure the
solutions we create are<br>
> 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<br>
> 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<br>
> 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<br>
> capabilities<br>
> - mistral environment - json structure in Mistral
which we use as a backend<br>
> store accessible by mistral actions and workflows
(tripleo-common)<br>
><br>
> Currently, only possibility to configure roles
and networks is by creating<br>
> or updating the plan with changed meta files. We
need to create Mistral<br>
> actions to handle manipulating roles and networks
so GUI (also CLI) can<br>
> retrieve current roles/networks configuration and
update it, which in turn<br>
> will regenerate related templates. Now, the
question arises: Do we want to<br>
> use roles_data.yaml in Swift container as a
storage for this information? I<br>
> thought we agreed on using Mistral environment to
store plan related data.<br>
> (See here for additional context [3] )<br>
><br>
> This means that on plan creation, we use
roles_data.yaml (and<br>
> network_data.yaml etc.) to populate Mistral
environment and generate<br>
> templates using this data. roles_data.yaml (and
others) then need to be<br>
> discarded because from this point on, the data
will be updated in Mistral<br>
> environment through tripleo-common actions.
roles_data.yaml is therefore<br>
> used just as a default which is used when plan is
created (or updated).<br>
><br>
> Now, plan export comes into play [4]. We want to
be able to pull down the<br>
> plan and deploy it using CLI directly (which
creates/updates plan as far as<br>
> during deploy command), We want to be able to
reuse the plan in other<br>
> deployments or use it as a reference architecture
for subsequent<br>
> deployments. This means we don't only want to
download the contents of Swift<br>
> container, but also configuration stored in
Mistral environment.<br>
><br>
> So Plan export action pulls down files from Swift
container, adds meta<br>
> files: roles_data.yaml, network_data.yaml...
which it populates by looking<br>
> at appropriate keys in Mistral environment +
plan_environment.yaml which<br>
> includes remaining data from Mistral environment
such as parameter values,<br>
> environments etc. All of those are then returned
in a single tarball.<br>
> Question to consider is whether to split all this
data into separate files<br>
> or keep it in single one.<br>
><br>
> Plan Import [5] then allows to provide
plan_environment.yaml to enable<br>
> populating parameter values and environments
selection during plan creation.<br>
<br>
</div>
</div>
For which cycle would you target this blueprint?<br>
We need to update it accordingly:<br>
<a moz-do-not-send="true"
href="https://blueprints.launchpad.net/tripleo/+spec/enhance-plan-creation-with-plan-environment-json"
rel="noreferrer" target="_blank">https://blueprints.launchpad.<wbr>net/tripleo/+spec/enhance-<wbr>plan-creation-with-plan-<wbr>environment-json</a></blockquote>
<div><br>
</div>
<div>I think it should be targeted for Pike 1.</div>
</div>
</div>
</div>
</blockquote>
+1<br>
<br>
<blockquote
cite="mid:CAOUEErq85WWj_iu1dFkUBrg7FfEJYpqp2qVNZQ5cU2nRbcvbDg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<span class=""><br>
><br>
> Alternative solution is to store meta files
(roles_data.yaml,<br>
> network_data.yaml...) in Swift container and use
those files as a data store<br>
> which IMHO does not comply with decision to use
Mistral environment as a<br>
> plan data store. In that case we should probably
get rid of using Mistral<br>
> environment altogether and use
plan_environment.yaml file in Swift container<br>
> to store data which we currently store in Mistral
environment. I am quite<br>
> convinced that there have been good reasons to not
to do this and use<br>
> Mistral environment.<br>
><br>
><br>
> [1] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/409920/"
rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/409920/</a><br>
> [2] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/409921/"
rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/409921/</a><br>
> [3] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/409921/"
rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/409921/</a><br>
> [4]<br>
> <a moz-do-not-send="true"
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/<wbr>openstack/tripleo-specs/specs/<wbr>ocata/gui-plan-import-export.<wbr>html#problem-description</a><br>
> [5]<br>
> <a moz-do-not-send="true"
href="https://blueprints.launchpad.net/tripleo/+spec/enhance-plan-creation-with-plan-environment-json"
rel="noreferrer" target="_blank">https://blueprints.launchpad.<wbr>net/tripleo/+spec/enhance-<wbr>plan-creation-with-plan-<wbr>environment-json</a><br>
><br>
><br>
> -- Jirka<br>
<br>
</span>Sounds good to me! Thanks for sharing it.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Emilien Macchi<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>Regards,</div>
<div>Ana Krivokapic</div>
<div>Senior Software Engineer</div>
<div>OpenStack team</div>
<div>Red Hat Inc.</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>