Open Stack

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?

>
>
> 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
>