Open Stack

On 14 August 2015 at 20:31, Chris Dent <chdent at redhat.com> wrote:
> On Thu, 13 Aug 2015, Sean M. Collins wrote:
>
>> Do we want to make it a default to True for users of DevStack? I think
>> it may be worth considering since I'm not familiar with this issue
>> with crypto and having something that protects devs who are trying to
>> work on stuff and using DevStack , sounds good. Less cryptic day to
>> day breakage for new developers just getting started and using
>> DevStack is a goal I have, long term (where possible).
>
>
> While I understand the practical considerations of using upper
> constraints in the gate I think using them locally when doing the
> "dev" part of using devstack has some unintended consequences that
> we need to think about (assuming my implicit conclusion below is
> correct).
>
> The main issue is that it moves our use of all these libraries from
> a position of participation to consumption. If we are only using
> known-good constrained libs then we are not being a part of the
> broader ecosystem that finds and fixes bugs in Python libraries.

It has little effect on that at all.

The vast majority of our developers do not fix such bugs. They react
by blacklisting the proximate cause of the issue - the new release -
locally, submit a patch to openstack/requirements *sometimes* and if
we're really lucky file a bug upstream.

The constraints system proactively finds and highlights to anyone
interested the same issues [presuming the issue can be shown in the
gate]. It does that via a bot that updates constraints automatically
via a periodic job.

> That may seem a bit esoteric or idealistic but it is one of the
> aspects of open source collaboration that I think is truly great:
> project evolution as a result of cross-pollination.

It makes 2500 developers all hit the same problem at the same time.
Thats not cross-pollination, its a flash mob :)

> This is not to say that I'm not sympathetic to the problem of
> cryptic day to day breakage. It's a significant issue but I'm not
> sure the way to fix that problem is by becoming more static.
> Breakage is a bug, it needs to be visible so it can be fixed, not
> masked.

Its visible: follow
https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:master+topic:openstack/requirements/constraints,n,z
(I don't know if you can make gerrit mail on just those reviews), and
you'll see the bot updates that tries the latest release of everything
in the gate. If it passes, we use it. If it fails, we report it as a
bug.

Fire drills are not worth the benefit of making incompatible upstream
releases be disruptive. Signal is important, stress is harmful: we
want signal without stress IMO.

-Rob



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud