<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div class="moz-cite-prefix">On 04/12/15 23:04, Dmitry Tantsur wrote:<br></div><blockquote cite="mid:56616520.9080503@redhat.com">On 12/03/2015 08:45 PM, Tzu-Mainn Chen wrote: <br><blockquote>Hey all, <br><br> Over the past few months, there's been a lot of discussion and work around <br> creating a new REST API-supported TripleO deployment workflow. However most <br> of that discussion has been fragmented within spec reviews and weekly IRC <br> meetings, so I thought it might make sense to provide a high-level overview <br> of what's been going on. Hopefully it'll provide some useful perspective for <br> those that are curious! <br><br> Thanks, <br> Tzu-Mainn Chen <br><br> ------------------------------------------------------------------------------ <br> 1. Explanation for Deployment Workflow Change <br><br> TripleO uses Heat to deploy clouds. Heat allows tremendous flexibility at the <br> cost of enormous complexity. Fortunately TripleO has the space to allow <br> developers to create tools to simplify the process tremendously, resulting in <br> a deployment process that is both simple and flexible to user needs. <br><br> The current CLI-based TripleO workflow asks the deployer to modify a base set <br> of Heat environment files directly before calling Heat's stack-create command. <br> This requires much knowledge and precision, and is a process prone to error. <br><br> However this process can be eased by understanding that there is a pattern to <br> these modifications; for example, if a deployer wishes to enable network <br> isolation, a specific set of modifications must be made. These modification <br> sets can be encapsulated through pre-created Heat environment files, and TripleO <br> contains a library of these <br> (<a class="moz-txt-link-freetext" href="https://github.com/openstack/tripleo-heat-templates/tree/master/environments" target="_blank" data-mce-href="https://github.com/openstack/tripleo-heat-templates/tree/master/environments">https://github.com/openstack/tripleo-heat-templates/tree/master/environments</a>). <br><br> These environments are further categorized through the proposed environment <br> capabilities map (<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/242439" target="_blank" data-mce-href="https://review.openstack.org/#/c/242439">https://review.openstack.org/#/c/242439</a>). This mapping file <br> contains programmatic metadata, adding items such as user-friendly text around <br> environment files and marking certain environments as mutually exclusive. <br><br><br> 2. Summary of Updated Deployment Workflow <br><br> Here's a summary of the updated TripleO deployment workflow. <br><br> 1. Create a Plan: Upload a base set of heat templates and environment files <br> into a Swift container. This Swift container will be versioned to allow <br> for future work with respect to updates and upgrades. <br><br> 2. Environment Selection: Select the appropriate environment files for your <br> deployment. <br><br> 3. Modify Parameters: Modify additional deployment parameters. These <br> parameters are influenced by the environment selection in step 2. <br><br> 4. Deploy: Send the contents of the plan's Swift container to Heat for <br> deployment. <br><br> Note that the current CLI-based workflow still fits here: a deployer can modify <br> Heat files directly prior to step 1, follow step 1, and then skip directly to <br> step 4. This also allows for trial deployments with test configurations. <br><br><br> 3. TripleO Python Library, REST API, and GUI <br><br> Right now, much of the existing TripleO deployment logic lives within the TripleO <br> CLI code, making it inaccessible to non-Python based UIs. Putting both old and <br> new deployment logic into tripleo-common and then creating a REST API on top of <br> that logic will enable modern Javascript-based GUIs to create cloud deployments <br> using TripleO. <br><br><br> 4. Future Work - Validations <br><br> A possible next step is to add validations to the TripleO toolkit: scripts that <br> can be used to check the validity of your deployment pre-, in-, and post-flight. <br> These validations will be runnable and queryable through a REST API. Note that <br> the above deployment workflow should not be a requirement for validations to be <br> run. <br><br><br> 5. In-Progress Development <br><br> The initial spec for the tripleo-common library has already been approved, and <br> various people have been pushing work forward. Here's a summary: <br><br> * Move shared business logic out of CLI <br> * <a class="moz-txt-link-freetext" href="https://review.openstack.org/249134" target="_blank" data-mce-href="https://review.openstack.org/249134">https://review.openstack.org/249134</a> - simple validations (WIP) <br></blockquote><br> When is this going to be finished? It's going to get me a huge merge conflict in <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/250405/" target="_blank" data-mce-href="https://review.openstack.org/#/c/250405/">https://review.openstack.org/#/c/250405/</a> (and make it impossible to backport to liberty btw). <br><br></blockquote>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.<br><br> What I would propose is the following:<br> - the tripleo_common repo is renamed to tripleo and consumed by Mitaka<br> - the tripleo_common repo continues to exist in Liberty<br> - 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<br> - this change is backported to the tripleo_common repo on the stable/liberty branch<br></blockquote><div><br></div><div>Heya - apologies for the bit of churn here. I re-visited the repo-renaming issue in IRC, and it sounds like</div><div>the vast majority of people are actually in favor of putting the relevant library and API code in the</div><div>tripleo-common repository, and revisiting the creation of a tripleo repository later, once code has had a<br></div><div>chance to settle. I personally like this idea, as it reduces some disruptive activity at a time when we're trying</div><div>to add quite a bit of new code.<br></div><div><br></div><div>I double-checked with the people who originally raised objections to the idea of putting API code into</div><div>tripleo-common. One said that his objection had to do with package naming, and he removed his objection</div><div>once it was realized that the package name could be independent of the repo name. The other clarified his</div><div>objection as simply a consistency issue that he thought was okay to resolve until after the API code settled a</div><div>bit.<br></div><div><br></div><div>So: I'm putting the idea of *not* creating a tripleo repo just quite yet out there on the mailing list, and I'm<br></div><div>hopeful we can come to agreement in Tuesday's tripleo weekly IRC meeting. That would resolve a lot of the<br></div><div>concerns mentioned here, correct?<br></div><div><br></div><div><br></div><div>Mainn<br></div><div><br></div><div><br></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"> 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.<br><br> 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.<br><blockquote cite="mid:56616520.9080503@redhat.com"><blockquote> * <a class="moz-txt-link-freetext" href="https://review.openstack.org/228991" target="_blank" data-mce-href="https://review.openstack.org/228991">https://review.openstack.org/228991</a> - deployment code (ready for review) <br><br> * Additional TripleO business logic <br> * rename tripleo-common repo to tripleo <br> * <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/249521/" target="_blank" data-mce-href="https://review.openstack.org/#/c/249521/">https://review.openstack.org/#/c/249521/</a> (ready for review) <br> * <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/249524/" target="_blank" data-mce-href="https://review.openstack.org/#/c/249524/">https://review.openstack.org/#/c/249524/</a> (ready for review) <br> * <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/247834/" target="_blank" data-mce-href="https://review.openstack.org/#/c/247834/">https://review.openstack.org/#/c/247834/</a> (ready for review) <br></blockquote></blockquote>(here is my review comment on this change)<br><p style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em;
color: rgb(0, 0, 0); font-family: sans-serif; font-size: small;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: 1; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255);" data-mce-style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em; color: #000000; font-family: sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: #ffffff;">I'd like to propose that we have a period where the tripleo_common package continues to be usable without a deprecation message.</p><p style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em;
color: rgb(0, 0, 0); font-family: sans-serif; font-size: small;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: 1; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255);" data-mce-style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em; color: #000000; font-family: sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: #ffffff;">Rather than using deprecated subclasses, can we just do oslo-style wildcard imports [1] for this package transition?</p><p style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em;
color: rgb(0, 0, 0); font-family: sans-serif; font-size: small;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: 1; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255);" data-mce-style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em; color: #000000; font-family: sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: #ffffff;">If we did that then the test files could just be moved to tripleo, rather than duplicating them.</p><p style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em;
color: rgb(0, 0, 0); font-family: sans-serif; font-size: small;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: 1; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255);" data-mce-style="-webkit-margin-before: 0px; -webkit-margin-after: 0.3em; color: #000000; font-family: sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: #ffffff;">What I am hoping is that this change can be backported to stable/liberty of tripleo_co <span style="color: rgb(0, 0, 0); font-family: sans-serif;
font-size: small; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: 1;
word-spacing: 0px; -webkit-text-stroke-width: 0px; display:
inline !important; float: none; background-color: rgb(255, 255,
255);" data-mce-style="color: #000000; font-family: sans-serif; font-size: small; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none; background-color: #ffffff;">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.</span></p><br><blockquote cite="mid:56616520.9080503@redhat.com"><blockquote> * <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/242439" target="_blank" data-mce-href="https://review.openstack.org/#/c/242439">https://review.openstack.org/#/c/242439</a> - capabilities map (ready for review) <br> * <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/227297/" target="_blank" data-mce-href="https://review.openstack.org/#/c/227297/">https://review.openstack.org/#/c/227297/</a> - base tripleo library code (ready for review) <br> * <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/232534/" target="_blank" data-mce-href="https://review.openstack.org/#/c/232534/">https://review.openstack.org/#/c/232534/</a> - utility functions to manage environments (ready for review) <br> * after the above is merged, plan.py will need to be updated to include environment methods <br><br> * TripleO API <br> * <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/230432/" target="_blank" data-mce-href="https://review.openstack.org/#/c/230432/">https://review.openstack.org/#/c/230432/</a> - API spec (ready for review) <br> * <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/243737/" target="_blank" data-mce-href="https://review.openstack.org/#/c/243737/">https://review.openstack.org/#/c/243737/</a> - API (WIP) <br> * after the library code is fully merged, API will need to be updated to allow access <br> to a plan's environment manipulation methods <br></blockquote></blockquote>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.<br><br> [1] <a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/oslo.utils/tree/oslo/utils/importutils.py?h=stable/kilo" target="_blank" data-mce-href="http://git.openstack.org/cgit/openstack/oslo.utils/tree/oslo/utils/importutils.py?h=stable/kilo">http://git.openstack.org/cgit/openstack/oslo.utils/tree/oslo/utils/importutils.py?h=stable/kilo</a><br> [2] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/251587" target="_blank" data-mce-href="https://review.openstack.org/#/c/251587">https://review.openstack.org/#/c/251587</a><br><div><br></div>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote><div><br></div></div></body></html>