Open Stack

Tim Bell wrote:
>> - 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.

IMHO there are a few takeaways from this thread...

When a proposed patch is known to change default behavior, or break
backward compatibility, or cause an upgrade headache, we should
definitely be more careful before finally approving the change. We
should also have a mechanism to engage with users and operators so that
they can weigh in. In the worst case scenario where there is no good
solution, at least they are informed that the pain is coming. One
remaining question would be... what is that mechanism ? Mail to the
general list ? the operators list ? (should those really be two separate
lists ?) Some impact tag that upgrade-minded operators can subscribe to ?

For the cases where we underestimate the impact of a change, there is no
magic bullet. So, like Sean said, we need to continue improving the
number of things we cover by automated testing. We also need to continue
encouraging a devops culture. When most developers are also people
running clouds, we are better at estimating operational impact.

I've seen a bit of "us vs. them" between operators and developers
recently, and this is a dangerous trends. A sysadmin-friendly
programming language was picked for OpenStack for a reason: to make sure
that operation-minded developers and development-minded operators could
all be part of the same game. If we create two separate groups, tension
will only get worse.

-- 
Thierry Carrez (ttx)