On Thu, Feb 2, 2017 at 6:56 AM, Jiri Tomasek <[email protected]> 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 > > 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/ > [2] https://review.openstack.org/#/c/409921/ > [3] https://review.openstack.org/#/c/409921/ > [4] > 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 > > > -- Jirka Sounds good to me! Thanks for sharing it. -- Emilien Macchi __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
