Open Stack

Hi folks,

Last week I wrote a BluePrint and a spec [1] to propose to change the
way we used and managed the Plan in TripleO for the Deployment and the
Life cycle (update/upgrade and scale).

While I was working on trying to simplified the implementation of the
Update and Upgrade for a end user usage, I found very hard to follow all
the calls that the TripleO Client was doing to the HeatClient and
SwiftClient.

I traced the calls and found that we can safely and easily decrease the
number of calls and simplified the way that we are computing & rendering
the TripleO Heat Templates files.

I did a PoC to see what would be the problematic behind that and what we
could do without breaking the "standard" usage and all the particular
things that the current code handle (specific deployments and
configurations & so on).

By this refactoring I'm seeing another gain for the life cycle part of
TripleO, where we used to try to make thing simpler & safer but we
constantly failed due to this complexity and all the "special cases"
that we faced during the testing.

The result is that, when a user need to perform an update/upgrade of his
deployment, he really have to be careful, to pay a lot of attention of
all the options, -e environments files that he previously used  with the
risk to make a simple mistake, and totally mess up the deployment.

So my goals with this PoC and this BP is to try to addressed those
points by:

    simplify  and reduce the number of calls between the clients,

    have a simple way for creating and updating the Plan, even by
    amending the plan with only a particular files / config or Playbooks,

    store all the in formations provided by the user by uploading all
    the files outsides of the plan,

    keep the track of the environment files passed to the CLI,

    trace the life cycle story of the deployment.

So feel free to comment, add your concerns or feedback around this.

Cheer,

Mathieu

[1]

https://blueprints.launchpad.net/tripleo/+spec/tripleo-plan-management

https://review.openstack.org/599396 

[2]

 https://review.openstack.org/583145


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