Open Stack

On 12/03/2015 08:45 PM, Tzu-Mainn Chen wrote:
> Hey all,
>
> Over the past few months, there's been a lot of discussion and work around
> creating a new REST API-supported TripleO deployment workflow.  However most
> of that discussion has been fragmented within spec reviews and weekly IRC
> meetings, so I thought it might make sense to provide a high-level overview
> of what's been going on.  Hopefully it'll provide some useful perspective for
> those that are curious!
>
> Thanks,
> Tzu-Mainn Chen
>
> ------------------------------------------------------------------------------
> 1. Explanation for Deployment Workflow Change
>
> TripleO uses Heat to deploy clouds.  Heat allows tremendous flexibility at the
> cost of enormous complexity.  Fortunately TripleO has the space to allow
> developers to create tools to simplify the process tremendously,  resulting in
> a deployment process that is both simple and flexible to user needs.
>
> The current CLI-based TripleO workflow asks the deployer to modify a base set
> of Heat environment files directly before calling Heat's stack-create command.
> This requires much knowledge and precision, and is a process prone to error.
>
> However this process can be eased by understanding that there is a pattern to
> these modifications; for example, if a deployer wishes to enable network
> isolation, a specific set of modifications must be made.  These  modification
> sets can be encapsulated through pre-created Heat environment files, and TripleO
> contains a library of these
> (https://github.com/openstack/tripleo-heat-templates/tree/master/environments).
>
> These environments are further categorized through the proposed environment
> capabilities map (https://review.openstack.org/#/c/242439).  This mapping file
> contains programmatic metadata, adding items such as user-friendly text around
> environment files and marking certain environments as mutually exclusive.
>
>
> 2. Summary of Updated Deployment Workflow
>
> Here's a summary of the updated TripleO deployment workflow.
>
>      1. Create a Plan: Upload a base set of heat templates and environment files
>         into a Swift container.  This Swift container will be versioned to allow
>         for future work with respect to updates and upgrades.
>
>      2. Environment Selection: Select the appropriate environment files for your
>         deployment.
>
>      3. Modify Parameters: Modify additional deployment parameters.  These
>         parameters are influenced by the environment selection in step 2.
>
>      4. Deploy: Send the contents of the plan's Swift container to Heat for
>         deployment.
>
> Note that the current CLI-based workflow still fits here: a deployer can modify
> Heat files directly prior to step 1, follow step 1, and then skip directly to
> step 4.  This also allows for trial deployments with test configurations.
>
>
> 3. TripleO Python Library, REST API, and GUI
>
> Right now, much of the existing TripleO deployment logic lives within the TripleO
> CLI code, making it inaccessible to non-Python based UIs.   Putting both old and
> new deployment logic into tripleo-common and then creating a REST API on top of
> that logic will enable modern Javascript-based GUIs to create cloud deployments
> using TripleO.
>
>
> 4. Future Work - Validations
>
> A possible next step is to add validations to the TripleO toolkit: scripts that
> can be used to check the validity of your deployment pre-, in-, and  post-flight.
> These validations will be runnable and queryable through a  REST API.  Note that
> the above deployment workflow should not be a requirement for validations to be
> run.
>
>
> 5. In-Progress Development
>
> The initial spec for the tripleo-common library has already been approved, and
> various people have been pushing work forward.  Here's a summary:
>
> * Move shared business logic out of CLI
>    * https://review.openstack.org/249134 - simple validations (WIP)

When is this going to be finished? It's going to get me a huge merge 
conflict in https://review.openstack.org/#/c/250405/ (and make it 
impossible to backport to liberty btw).

>    * https://review.openstack.org/228991 - deployment code (ready for review)
>
> * Additional TripleO business logic
>    * rename tripleo-common repo to tripleo
>      * https://review.openstack.org/#/c/249521/ (ready for review)
>      * https://review.openstack.org/#/c/249524/ (ready for review)
>      * https://review.openstack.org/#/c/247834/ (ready for review)
>    * https://review.openstack.org/#/c/242439 - capabilities map (ready for review)
>    * https://review.openstack.org/#/c/227297/ - base tripleo library code (ready for review)
>    * https://review.openstack.org/#/c/232534/ - utility functions to manage environments (ready for review)
>    * after the above is merged, plan.py will need to be updated to include environment methods
>
> * TripleO API
>    * https://review.openstack.org/#/c/230432/ - API spec (ready for review)
>    * https://review.openstack.org/#/c/243737/  - API (WIP)
>    * after the library code is fully merged, API will need to be updated to allow access
>      to a plan's environment manipulation methods
>
> __________________________________________________________________________
> 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
>