Open Stack

On Wed, Feb 19, 2014 at 11:41 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

> On Wed, Feb 19, 2014 at 7:06 AM, Doug Hellmann
> <doug.hellmann at dreamhost.com> wrote:
> >
> >
> >
> > On Tue, Feb 18, 2014 at 9:03 PM, Joe Gordon <joe.gordon0 at gmail.com>
> wrote:
> >>
> >> On Wed, Feb 12, 2014 at 12:16 PM, Doug Hellmann
> >> <doug.hellmann at dreamhost.com> wrote:
> >> > If you have a change in your project that is blocked waiting for a
> patch
> >> > to
> >> > land in oslo (in the incubator, or any of the libraries we manage)
> >> > *please*
> >> > either open a blueprint or mark the associated bug as also affecting
> the
> >> > relevant oslo project, then let me know about it so I can put it on
> our
> >> > review priority list. We have a lot going on in oslo right now, but
> will
> >> > do
> >> > our best to prioritize reviews that affect features landing in other
> >> > projects -- if you let us know about them.
> >>
> >>
> >> While I don't think this is what you meant when you said let oslo help
> >> you, I do have a request:
> >>
> >> While trying to do a basic oslo-incubator update ('./update.sh
> >> --nodeps --modules fixture --base nova --dest-dir ../nova')  I hit a
> >> bug https://bugs.launchpad.net/oslo/+bug/1281860
> >>
> >> Due to the nature of oslo-incubator (it may break at any time) it is
> >> hard for downstream projects (nova, cinder etc.) to keep there
> >> oslo-incubator copies up to date, so when someone wants to sync across
> >> a new change they have to deal with many unrelated changes, some of
> >> which may break things. For example
> >>
> >> oslo-incubator$ ./update.sh --config-file
> >> ../cinder/openstack-common.conf --base cinder --dest-dir ../cinder
> >> cinder$ git diff --stat HEAD
> >> 52 files changed, 3568 insertions(+), 961 deletions(-)
> >>
> >>
> >> I would like to propose making the oslo team responsible for syncing
> >> across oslo-incubator code, they know the code base best and can fix
> >> things when they break.  This doesn't mean no one else can use
> >> update.sh it just means that the oslo team would make sure that syncs
> >> are done in a timely fashion, so the diffs don't get too big.
> >
> >
> > The intent has always been for the person making a change in the
> incubator
> > to be responsible for updating consuming projects (whether that person
> is an
> > oslo core reviewer or not). That hasn't always happened -- some changes
> are
> > only synced into the project where the change was wanted, some changes
> > aren't synced at all.
>
> I had no idea that is how it supposed to work today. That means for
> every patch I make to oslo-incubator I should be making 10+ other
> patches as well, that is a lot of overhead.
>

It is. It's a bad idea to have that many projects copying code from the
incubator, and it was never the plan that the incubator would be used that
way. Making syncing easier isn't going to solve the problem. It only
perpetuates the situation where syncing is needed at all.

> Although it doesn't look like it from the outside, we have made
> significant
> > progress in creating the tools and processes we need to move code out of
> the
> > incubator into libraries. I expect to accelerate those moves late in this
> > cycle and early in the next so the libraries can be adopted early in the
> > next cycle.
>
> Does this mean, there are plans to stop doing code syncs via
> oslo-incubator all together?
>

No, although I hope to restore it to its original purpose. As I said on
IRC, oslo is meant to be a place to collaborate to evolve an API and
create libraries. Somehow the perception has become that the incubator is a
place to dump code for someone else to maintain.

I am really happy to see the accelerated move to libraries, but that
> is not an immediate solution, we still have to deal with icehouse. It
> sounds like we both agree the status quo is broken and the long term
> solution is move code out of incubator. We need a short term solution
> as well, having cinder 4k lines off of oslo or nova being almost 10k
> lines off is unacceptable.
>

So far, every discussion on the subject eventually comes back to how big
the required patches are, though, and no one has come up with any proposals
for addressing that. I don't have a solution either, but am open to
suggestions. I do know that whatever solution we come up with will require
work from both sides of each sync -- oslo and the receiving project.

In the mean time, I have been focusing on addressing the underlying issue
by moving code into libraries. In past releases, we graduated the config
library and the messaging library, each with a certain amount of pain. That
pain taught us valuable lessons, which we have applied when creating
processes and tools to make things go more smoothly for other libraries. We
are verifying them now with oslo.vmware and oslo.test, and when we have the
kinks worked out we will move on to other libraries [1].

Doug

[1] https://wiki.openstack.org/wiki/Oslo/GraduationStatus



>
> >
> > Doug
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140219/d8a7bc64/attachment.html>