Open Stack

Excerpts from Tim Bell's message of 2014-01-01 13:30:32 -0800:
> 
> > - Changes in default behaviour:   Always likely to affect existing systems in some way.   Maybe we should have an additional type of review vote that comes from people who are recognised as reperensting large production deployments ?
> 
> This is my biggest worry...  there are changes which may be technically valid but have a significant disruptive impact on those people who are running clouds. Asking the people who are running production OpenStack clouds to review every patch to understand the risks and assess the migration impact is asking a lot.
> 
> What processes are in place to ensure that a technically correct patch does not have major impact on those of us who are running large scale OpenStack clouds in production ? DocImpact tagging is not sufficient as this implies the change is the right thing to do but needs procedures defined.
> 

If it's not tested, it is broken. A wise group of developers once
said that.

I think most things like this become a non issue if we test them in the
gate. If you are running a large production cloud and not making sure
what is important to you is tested in the gate, then IMO, you are doing
it wrong.

Also I'd be shocked to see a deployer who just consumes what comes out
of upstream without running their own private integration tests. So if
you don't have an integration test that makes sure you can still mount
ephemeral on supported images, then again, you're doing it wrong. It is
better to get your stuff in the gate, but if you have something local
that you must keep private, you can still do that and still raise a
"please revert this patch" bug.

Basically don't rely on JUST the humans to catch things. When there is
a hole in the automation and humans do manage to catch things, that is
great, but it should be a rarity. The catchers _SHOULD_ be adding tests
to make sure that the hole is plugged. No amount of review process is
going to be as effective as adequate test coverage.