On 2.2.2017 13:57, Ana Krivokapic wrote:
On Thu, Feb 2, 2017 at 1:46 PM, Emilien Macchi <emil...@redhat.com
<mailto:emil...@redhat.com>> wrote:
On Thu, Feb 2, 2017 at 6:56 AM, Jiri Tomasek <jtoma...@redhat.com
<mailto:jtoma...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
