[Rdo-list] reconsidering midstream repos

[Fox, Kevin M]

My 2 cents as an operator:

I upgraded a production cloud to Juno. Juno had an unexpected regression...
https://bugs.launchpad.net/neutron/+bug/1422476

Bug filed on:  2015-02-16

I proposed a working fix tested and working on our production cloud:
Feb 18, 2015 2:01 PM

The patch hit upstream Juno:
2015-05-07 12:48:47 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Upstream cares about the long term care and feeding of the code base more then the stability of it. If you follow the review, no one really commented on the fix, only nitpicked the unit tests. I'm all for the long term unit testing code being rock solid, but the fix should have gone in right away, and then care been spent on making nice unit tests. The project got what it needed, but the ops guys suffered in the mean time.

If you don't provide a way to apply fixes before they get upstreamed, your going to get some very unhappy operators I think since upstream doesn't care. :/

Thanks,
Kevin
________________________________________
From: rdo-list-bounces at redhat.com [rdo-list-bounces at redhat.com] on behalf of James Slagle [jslagle at redhat.com]
Sent: Tuesday, May 26, 2015 12:06 PM
To: Hugh O. Brock
Cc: rdo-list at redhat.com
Subject: Re: [Rdo-list] reconsidering midstream repos

On Mon, May 25, 2015 at 02:55:57PM +0200, Hugh O. Brock wrote:
> Seems like the midstream repos are causing us a lot of pain with little
> gain, at least in some cases. (For example it appears the t-h-t
> midstream exists to carry a single patch that enables mongodb on
> Centos.) Is it worth discussing whether we can eliminate some of these,
> especially for upstreams like t-h-t that aren't tightly tied to the
> OpenStack release schedule?
>
> /me ducks flying bricks

No flying bricks from me anyway :)

I agree with what you're saying, but would like to agree on what we're actually
meaning.  I think it's great that pretty much exactly what we said would happen
has happened: as Kilo nears completion, the patches that we're having to carry
for RDO-Manager is approaching 0.

But before we say, let's kill the midstream repos...let's consider why we even
have them to begin with.

We didn't come up with the idea to fork a bunch of projects because it would
make our *development* lives for RDO-Manager easier. In fact, it's exactly the
opposite, they cause pain.

So why do we have them? Quite simply it's because of the demand that we show,
commit to, and support features in RDO-Manager prior to them necessarily
merging in upstream OpenStack projects.

If we can lift that requirement, we could likely do away with the midstream
repos entirely.  I know this is rdo-list, but in the spirit of being open, if
we don't have midstream repos for RDO-Manager, then we shouldn't have them for
OSP either, and we should only be committing to features as they land in
upstream OpenStack.

It doesn't make sense to me to drop the midstream repos for RDO-Manager, but
then turn around and set them up privately for OSP. At least with them setup
for RDO, we're doing the development of the management product in the open. In
fact if we were to split like this, I think the pain would only intensify.

It's pragmatic to say that anyone looking to productize OpenStack is going to
have their own bug fixes/etc that they need, and maybe even some features. But
setting up private forks as a general development principal to drive OpenStack
based product development should be avoided at all costs.

So yes, I'm +1 on dropping the midstream repos if they're no longer needed.

But I'm -1 on then turning around and setting them up privately so that we can
commit code to private forks because that code hasn't landed in upstream
OpenStack yet. If we can agree that this isn't needed, then I think we can do
without the midstream. Otherwise, if we're going to insist on forks to "land"
features prior to them merging upstream, let's at least keep them public.

There's a couple other facets to the discussion as well:

The midstream repos is a place where we can preview where the management
product is headed. For example, the Heat breakpoint work was available from the
midstream repos much earlier than it ended up merging into Heat/heatclient.
Some devs/users might find this sort of thing really useful, and could provide
some early feedback for RDO-Manager.

The midstream repos are also a place where we can quickly land reverts to
unblock work. The Neutron regression that broke provisioning via Ironic this
past cycle immediately comes to mind...it took a couple of weeks before the
upstream revert even landed in Neutron. While that was broken, we carried the
proposed revert in the midstream repos so that people could install a Neutron
that actually worked for RDO-Manager.

>
> --Hugh
>
> --
> == Hugh Brock, hbrock at redhat.com                                   ==
> == Senior Engineering Manager, Cloud Engineering                   ==
> == RDO Manager: Install, configure, and scale OpenStack            ==
> == http://rdoproject.org                                           ==
>
> "I know that you believe you understand what you think I said, but I’m
> not sure you realize that what you heard is not what I meant."
> --Robert McCloskey
>
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com
--
-- James Slagle
--

_______________________________________________
Rdo-list mailing list
Rdo-list at redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list

To unsubscribe: rdo-list-unsubscribe at redhat.com