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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
