Open Stack

----- 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>