[openstack-dev] [OpenStack-Dev] [gate tests] Cinder drivers being set up as jobs in infra

John Griffith john.griffith8 at gmail.com
Fri Feb 20 01:49:00 UTC 2015


On Thu, Feb 19, 2015 at 5:59 PM, Clark Boylan <cboylan at sapwetik.org> wrote:
>
>
> On Thu, Feb 19, 2015, at 04:38 PM, John Griffith wrote:
>> Hey Everyone,
>>
>> Anteaya was kind enough to ask in the Cinder channel about some tests
>> that were added to the gate for SheepDog [1].  I would like to know
>> why there's no process for the projects that are impacted by these
>> changes to have input?  At the very least if someone is adding test
>> requirements against the Cinder project for example it should have
>> votes on the review from Cinder Core members.
> I approved this change. The only project directly affected is the
> sheepdog devstack plugin. They are testing that the plugin works. I
> don't understand why this is a problem. This test was not added to
> Cinder.

I suppose that's fair, the bigger question I have though is where we
set the allocation of resources?

>>
>> Nobody on the Cinder team seems to have had any information regarding
>> this change (or the Ceph config that was added for that matter).  It
>> seems odd to me that I hear discussions about the burden on infra
>> resources regarding the number of projects in OpenStack and what's
>> taking place there but then at the same time that group merges things
>> like this?  If there have been discussions with the Cinder PTL in
>> these cases then forgive me, I wasn't aware and I'll just move along.
> Again this change did not affect Cinder. Not sure why this is
> problematic. There is a second change,
> https://review.openstack.org/#/c/153868, that has not been approved that
> would run this test against Cinder, but a project-config core reviewer
> reached out to Cinder before approving that change. This appears to be
> what you would like to see so thats good.

Yes, thank you for pointing that out, that is in fact more relevant to
my concerns.

>
> The ceph job was added in https://review.openstack.org/#/c/147559/ and a
> quick scan of comments does show it to have had positive votes from a
> Cinder core.

Indeed, we have core representation from Redhat and I fully trust his
judgement here.  The issue isn't so much if the add is "ok" but more
along the lines of what I mentioned earlier regarding use of
resources.  Maybe I've interpreted things incorrectly and there is no
resource issue with infra; in which case I was way off base and again
I should butt out.

>>
>> My other question is, why is anybody setting up and maintaining their
>> own CI system?  Couldn't I just setup a stackforge project that
>> deploys my software in an Instance and push it to infra as well?
>> Doesn't this seem a bit wrong to anybody else, using Foundation
>> resources for my own gain?
> For open source projects that don't require special hardware we have
> wanted more people to cooperate with Infra to run tests upstream. Third
> party CI is a great solution for when you cannot redistribute certain
> pieces of software or specific hardware is required. But in general if
> it is open source and we can test it in our clouds then we would at
> least like to talk about doing it that way.

Fair enough, I wasn't aware that this was the direction we had taken.
I certainly agree with the need for other ways to help out Open Source
projects.  My only concern in this case was that I know there has been
a lot of work by first Duncan and now Mike to try and keep track of
and communicate driver testing efforts.  This sort of came out of
nowhere for me personally and a number of other people on the Cinder
team.  If nothing else it would just be good to know what efforts are
in progress.  For the record I have no issue with the SheepDog driver
(well assuming it's up to date now; it had fallen pretty far behind as
of Juno).  That's the sort of thing that I think does impact Cinder,
verifying the project is actually active in Cinder, that there's some
visible maintenance and that it actually "works".  Granted that would
be sorted out soon enough just by the process itself I suppose.

>
> There are some rough edges with that particularly if you don't want
> things to gate or be similar to gating due to clean check. Basically we
> need a way to report results back to Gerrit as a user other than Jenkins
> so that the Jenkins results are still used for gating (there are
> probably other alternatives too but the second account method is in
> development).

The points you made above are probably the biggest thing that bothered
me here and the fact that you're already working on it... well then
good enough.  My problem here is signal to noise ratio when conducting
reviews; I rely heavily on the "Jenkins" table to use as a filter.

>>
>> Also, I think it creates some confusion; we either have a reference
>> implementation or we don't.  If somebody wants to propose changing
>> what the reference implementation is that's fine but that should be
>> handled by the affected project not by a change submitted to the infra
>> projects.
>>
>> I've actually been of the opinion that devstack and our internal gate
>> is bloated with plugins and options and should actually be scaled
>> down.  We should certainly provide mechanisms for any plugin to be
>> configured via devstack for example but I don't think the code belongs
>> "in" devstack; it should be externally maintained in my opinion... but
>> that's a whole separate rant I suppose.
>>
>> Thanks,
>> John
>>
>> [1]: https://review.openstack.org/#/c/154605/
>>
> Hope this helps clarify things.
>
> Clark
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list