Open Stack

On 2.2.2017 13:57, Ana Krivokapic wrote:
>
>
> On Thu, Feb 2, 2017 at 1:46 PM, Emilien Macchi <emilien at redhat.com 
> <mailto:emilien at redhat.com>> wrote:
>
>     On Thu, Feb 2, 2017 at 6:56 AM, Jiri Tomasek <jtomasek at redhat.com
>     <mailto:jtomasek at redhat.com>> wrote:
>     > Hello all,
>     >
>     > 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.
>     >
>     > There are several goals / features we currently aim for:
>     > - Define and manage custom Roles (GUI/CLI)
>     > - Define and manage networks (CLI/GUI)
>     > - Import/Export Deployment plans so it is possible to reuse them
>     or use them
>     > as a reference/starting point
>     >
>     > Currently the Deployment plan stored in Swift consist of:
>     > - tripleo heat templates
>     > - roles_data.yaml - meta file used as an input to define roles
>     (and assign
>     > networks to roles [1])
>     > - network_data.yaml - meta file used as input to define networks [2]
>     > - capabilities-map.yaml - meta file to describe THT environment
>     files
>     > capabilities
>     > - mistral environment - json structure in Mistral which we use
>     as a backend
>     > store accessible by mistral actions and workflows (tripleo-common)
>     >
>     > 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] )
>     >
>     > 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).
>     >
>     > 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.
>     >
>     > 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.
>     >
>     > Plan Import [5] then allows to provide plan_environment.yaml to
>     enable
>     > populating parameter values and environments selection during
>     plan creation.
>
>     For which cycle would you target this blueprint?
>     We need to update it accordingly:
>     https://blueprints.launchpad.net/tripleo/+spec/enhance-plan-creation-with-plan-environment-json
>     <https://blueprints.launchpad.net/tripleo/+spec/enhance-plan-creation-with-plan-environment-json>
>
>
> I think it should be targeted for Pike 1.
+1

>
>
>     >
>     > 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.
>     >
>     >
>     > [1] https://review.openstack.org/#/c/409920/
>     <https://review.openstack.org/#/c/409920/>
>     > [2] https://review.openstack.org/#/c/409921/
>     <https://review.openstack.org/#/c/409921/>
>     > [3] https://review.openstack.org/#/c/409921/
>     <https://review.openstack.org/#/c/409921/>
>     > [4]
>     >
>     http://specs.openstack.org/openstack/tripleo-specs/specs/ocata/gui-plan-import-export.html#problem-description
>     <http://specs.openstack.org/openstack/tripleo-specs/specs/ocata/gui-plan-import-export.html#problem-description>
>     > [5]
>     >
>     https://blueprints.launchpad.net/tripleo/+spec/enhance-plan-creation-with-plan-environment-json
>     <https://blueprints.launchpad.net/tripleo/+spec/enhance-plan-creation-with-plan-environment-json>
>     >
>     >
>     > -- Jirka
>
>     Sounds good to me! Thanks for sharing it.
>     --
>     Emilien Macchi
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> -- 
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170202/e87bd8cd/attachment.html>