Open Stack

On 04/21/2016 10:32 AM, Michael Krotscheck wrote:
> On Thu, Apr 21, 2016 at 8:10 AM Hayes, Graham <graham.hayes at hpe.com
> <mailto:graham.hayes at hpe.com>> wrote:
>
>     On 21/04/2016 15:39, Michael Krotscheck wrote:
>
>     python-openstackclient does require the creation of a new repo for each
>     project (unless you are one of the chosen few).
>
>     Does this mean you will accept all projects to the library, or just
>     selected projects?
>
>
> In a perfect world, we'd accept everyone. I have some questions about
> things like "Does devstack fall down if we try to gate on every service
> ever", and how to package things so we can meet both the "gimme
> everything" and the "I just want one service" users, however those
> strike me as solvable problems.

FWIW, our policy in shade for adding new service support has been that 
adding the service to our existing devstack gate jobs does not break 
things, and that all new code must come with functional tests that run 
against a live devstack with the service in question enabled. So far it 
has worked well - we have not had a large land rush of people trying to 
get stuff in, but when they have showed up there has been a clear 
expectation on what it means that has nothing to do with whether or not 
I like the service.

A case in point that worth mentioning ... last cycle Yolanda started 
work on adding magnum support to shade - but adding magnum to our 
devstack config at that time increased the failure rate too much because 
the magnum devstack config was downloading atomic images from fedora. So 
- we disabled it again ... and yolanda went and worked with 
diskimage-builder to add support for building atomic images. And then we 
added a job that builds atomic images and uploads them to tarballs.o.o 
and then made sure the magnum devstack could consume those.

Now that all of those things are true, we're about to re-enable magnum 
support because we're confident that having magnum in our gate is a 
solid thing.