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