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