On 04/12/15 23:04, Dmitry Tantsur wrote:
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).
This plan would be fine if Mitaka development was the only consideration
but I hope that it can be adapted a little bit to take into account the
Liberty branches, and the significant backports that will be happening
there. The rdomanager-plugin->tripleoclient transition made backports
painful, and having moved on for that it would be ideal if we didn't
create the same situation again.
What I would propose is the following:
- the tripleo_common repo is renamed to tripleo and consumed by Mitaka
- the tripleo_common repo continues to exist in Liberty
- the change to rename the package tripleo_common to tripleo occurs on
the tripleo repo in the master branch using oslo-style wildcard
imports[1], and initially no deprecation message
- this change is backported to the tripleo_common repo on the
stable/liberty branch
Once this is in place, stable/liberty tripleoclient can gradually move
from the tripleo_common to the tripleo package, and parts of then
tripleoclient -> tripleo_common business logic move can also be
backported where appropriate.
I'm planning on adding some liberty backportable commands as part of
blueprint tripleo-manage-software-deployments [2] and this approach
would greatly ease the backport process, and allow the business logic to
start in the tripleo repo.
* 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)
(here is my review comment on this change)
I'd like to propose that we have a period where the tripleo_common
package continues to be usable without a deprecation message.
Rather than using deprecated subclasses, can we just do oslo-style
wildcard imports [1] for this package transition?
If we did that then the test files could just be moved to tripleo,
rather than duplicating them.
What I am hoping is that this change can be backported to stable/liberty
of tripleo_co mmon so that stable/liberty tripleoclient can gradually
transition over, and the work to move business logic out of
tripleoclient can also have targeted backports to liberty
tripleo_common/tripleoclient.
* 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
What is the expected timeframe for tripleoclient to move from the
tripleo library to the REST API? If it isn't done by the end of Mitaka
then we'll end up with a client that indirectly depends on server
packages like Flask, keystonemiddleware, oslo.middleware. I realize
we've already made the repo split decision, I just wanted to make sure
that folk are aware of this consequence.
[1]
http://git.openstack.org/cgit/openstack/oslo.utils/tree/oslo/utils/importutils.py?h=stable/kilo
[2] https://review.openstack.org/#/c/251587
__________________________________________________________________________
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
