mordred at inaugust.com
Thu Apr 21 17:17:46 UTC 2016
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
More information about the OpenStack-dev