Open Stack

On Fri, Jan 17, 2014 at 1:15 AM, Robert Collins
<robertc at robertcollins.net> wrote:
> On 16 January 2014 14:51, John Griffith <john.griffith at solidfire.com> wrote:
>> On Wed, Jan 15, 2014 at 6:41 PM, Michael Still <mikal at stillhq.com> wrote:
>>> John -- I agree with you entirely here. My concern is more that I
>>> think the CI tests need to run more frequently than weekly.
>>
>> Completely agree, but I guess in essence to start these aren't really
>> CI tests.  Instead it's just a public health report for the various
>> drivers vendors provide.  I'd love to see a higher frequency, but some
>> of us don't have the infrastructure to try and run a test against
>> every commit.  Anyway, I think there's HUGE potential for growth and
>> adjustment as we go along.  I'd like to get something in place to
>> solve the immediate problem first though.
>
> You say you don't have the infrastructure - whats missing? What if you
> only ran against commits in the cinder trees?

Maybe this is going a bit sideways, but my point was that making a
first step of getting periodic runs on vendor gear and publicly
submitting those results would be a good starting point and a
SIGNIFICANT improvement over what we have today.

It seems to me that "requiring" every vendor to have a deployment in
house dedicated and reserved 24/7 might be a tough order right out of
the gate.  That being said, of course I'm willing and able to do that
for my employer, but feedback from others hasn't been quite so
amiable.

The feedback here seems significant enough that maybe gating every
change is the way to go though.  I'm certainly willing to opt in to
that model and get things off the ground.  I do have a couple of
concerns (number 3 begin the most significant):

1. I don't want ANY commit/patch waiting for a Vendors infrastructure
to run a test.  We would definitely need a timeout mechanism or
something along those lines to ensure none of this disrupts the gate

2. Isolating this to changes in Cinder seems fine, the intent was
mostly a compatability / features check.  This takes it up a notch and
allows us to detect when something breaks right away which is
certainly a good thing.

3. Support and maintenance is a concern here.  We have a first rate
community that ALL pull together to make our gating and infrastructure
work in OpenStack.  Even with that it's still hard for everybody to
keep up due to number of project and simply the volume of patches that
go in on a daily basis.  There's no way I could do my regular jobs
that I'm already doing AND maintain my own fork/install of the
OpenStack gating infrastructure.

4. Despite all of the heavy weight corporation throwing resource after
resource at OpenStack, keep in mind that it is an Open Source
community still.  I don't want to do ANYTHING that would make it some
unfriendly to folks who would like to commit.  Keep in mind that
vendors here aren't necessarily all large corporations, or even all
paid for proprietary products.  There are open source storage drivers
for example in Cinder and they may or may not have any of the
resources to make this happen but that doesn't mean they should not be
allowed to have code in OpenStack.

The fact is that the problem I see is that there are drivers/devices
that flat out don't work and end users (heck even some vendors that
choose not to test) don't know this until they've purchased a bunch of
gear and tried to deploy their cloud.  What I was initially proposing
here was just a more formal public and community representation of
whether a device works as it's advertised or not.

Please keep in mind that my proposal here was a first step sort of
test case.  Rather than start with something HUGE like deploying the
OpenStack CI in every vendors lab to test every commit (and I"m sorry
for those that don't agree but that does seem like a SIGNIFICANT
undertaking), why not take incremental steps to make things better and
learn as we go along?


>
>> To be honest I'd even be thrilled just to see every vendor publish a
>> passing run against each milestone cut.  That in and of itself would
>> be a huge step in the right direction in my opinion.
>
> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev