Open Stack

On 02/24/2015 12:33 PM, John Griffith wrote:
> 
> 
> On Tue, Feb 24, 2015 at 10:04 AM, David Kranz <dkranz at redhat.com
> <mailto:dkranz at redhat.com>> wrote:
> 
>     On 02/24/2015 09:37 AM, Chris Dent wrote:
> 
>         On Tue, 24 Feb 2015, Sean Dague wrote:
> 
>             That also provides a very concrete answer to "will people
>             show up".
>             Because if they do, and we get this horizontal refactoring
>             happening,
>             then we get to the point of being able to change release
>             cadences
>             faster. If they don't, we remain with the existing system.
>             Vs changing
>             the system and hoping someone is going to run in and
>             backfill the breaks.
> 
> 
>         Isn't this the way of the world? People only put halon in the
>         machine room after the fire.
> 
>         I agree that "people showing up" is a real concern, but I also think
>         that we shy away too much from the productive energy of stuff
>         breaking. It's the breakage that shows where stuff isn't good
>         enough.
> 
>         [Flavio said]:
> 
>             To this I'd also add that bug fixing is way easier when you have
>             aligned releases for projects that are expected to be deployed
>             together. It's easier to know what the impact of a change/bug is
>             throughout the infrastructure.
> 
> 
>         Can't this be interpreted as an excuse for making software which
>         does not have a low surface area and a good API?
> 
>         (Note I'm taking a relatively unrealistic position for sake of
>         conversation.)
> 
>     I'm not so sure about that. IMO, much of this goes back to the
>     question of whether OpenStack services are APIs or implementations.
>     This was debated with much heat at the Diablo summit (Hi Jay). I
>     frequently have conversations where there is an issue about release
>     X vs Y when it is really about api versions. Even if we say that we
>     are about implementations as well as apis, we can start to organize
>     our processes and code as if we were just apis. If each service had
>     a well-defined, versioned, discoverable, well-tested api, then
>     projects could follow their own release schedule, relying on distros
>     or integrators to put the pieces together and verify the quality of
>     the whole stack to the users. Such entities could still collaborate
>     on that task, and still identify longer release cycles, using
>     "stable branches". The upstream project could still test the latest
>     released versions together. Some of these steps are now being taken
>     to resolve gate issues and horizontal resource issues. Doing this
>     would vastly increase agility but with some costs:
> 
>     1. The upstream project would likely have to give up on the worthy
>     goal of providing an actual deployable stack that could be used as
>     an alternative to AWS, etc. That saddens me, but for various
>     reasons, including that we do no scale/performance testing on the
>     upstream code, we are not achieving that goal anyway. The big tent
>     proposals are also a move away from that goal.
> 
>     2. We would have to give up on incompatible api changes. But with
>     the replacement of nova v3 with microversions we are already doing
>     that. Massive adoption with release agility is simply incompatible
>     with allowing incompatible api changes.
> 
>     Most of this is just echoing what Jay said. I think this is the way
>     any SOA would be designed. If we did this, and projects released
>     frequently, would there be a reason for any one to be chasing master?
> 
>      -David
> 
> 
> 
>     ______________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.__openstack.org?subject:__unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> ​Seems like some of the proposals around frequency (increasing in
> particular) just sort of move the bottlenecks around.  Honestly, I
> thought we were already on a path with some of the ideas that Sean and
> David (and indirectly Jay) proposed.  Get rid of the whole "coordinated
> release" altogether.  I think there should still be some sort of tagging
> or something at some interval that just says "here's a point in time
> collection that we call X".
> 
> Another proposal I think I've talked to some folks about is a true
> CI/Train model.  Cut out some of the artificial milestone deadlines etc,
> just keep rolling and what's ready at the release point is what's ready;
> you make a cut of what's there at that time and roll on.  Basically
> eliminate the feature freeze and other components and "hopefully" keep
> feature commit distributed.  There are certainly all sorts of gotchas
> here, but I don't think it's very interesting to most so I won't go into
> a bunch of theory on it.
> 
> Regardless, I do think that no matter the direction we all seem to be of
> the opinion that we need to move more towards projects being responsible
> for more of the horizontal functions (as Sean put it).  Personally I
> think this is a great direction for a number of reasons, and I also
> think that it might force us to be better about our API's and
> requirements than we have been in the past.

Agreed.

Personally, this is where I've been spending my efforts over the last year.

- Branchless Tempest - means we decouple the idea of integration tests
from a timebox
- Testing libraries from releases - means we decouple the tight linkage
between libraries and servers, as we no longer can use features before
they are released.
- Devstack external plugins - lets projects own their full stack bringup
scripts for devstack

Modular upgrade infrastructure is definitely on the horizon for Liberty,
as well as getting some of the Tempest content that should be project
functional tests back into projects. Decoupling all the non base IaaS
projects in our testing infrastructure, which should let them easily
chance release cadence. Use of virtual envs for servers so that cross
project shared dependency conflicts stop being an issue we need to manage.

It's a long road to hoe. Additional hands welcomed in helping us get
there faster. Decoupling Nova from all other projects is going to be a
hard long game, and it really feels like it should come after the
lessons learned by decoupling some of the less coupled efforts like
Savana, Trove, Heat.

	-Sean

-- 
Sean Dague
http://dague.net