----- Original Message ----- > On 12/07/2015 04:33 AM, Tzu-Mainn Chen wrote: > > ------------------------------------------------------------------------ > > > > On 04/12/15 23:04, Dmitry Tantsur wrote: > > > > On 12/03/2015 08:45 PM, Tzu-Mainn Chen wrote: > > > <snip> > > > > > > 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 > > > > > > Heya - apologies for the bit of churn here. I re-visited the > > repo-renaming issue in IRC, and it sounds like > > the vast majority of people are actually in favor of putting the > > relevant library and API code in the > > tripleo-common repository, and revisiting the creation of a tripleo > > repository later, once code has had a > > chance to settle. I personally like this idea, as it reduces some > > disruptive activity at a time when we're trying > > to add quite a bit of new code. > > > > I double-checked with the people who originally raised objections to the > > idea of putting API code into > > tripleo-common. One said that his objection had to do with package > > naming, and he removed his objection > > once it was realized that the package name could be independent of the > > repo name. The other clarified his > > objection as simply a consistency issue that he thought was okay to > > resolve until after the API code settled a > > bit. > > > > So: I'm putting the idea of *not* creating a tripleo repo just quite yet > > out there on the mailing list, and I'm > > hopeful we can come to agreement in Tuesday's tripleo weekly IRC > > meeting. That would resolve a lot of the > > concerns mentioned here, correct? > > It does not seem to resolve mine concern, though. I'm still wondering > where should I continue the major profiles refactoring. If it moves to > triple-common/tripleo (whatever the name), how do I backport it? >
This part of the move is still pending; your concerns are resolved if your PR goes in first, correct? I think that should be fine. Mainn > > > > > > > Mainn > > > > > > 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 > > > > > > > > > > __________________________________________________________________________ > > 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 > > > > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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