[openstack-dev] Cinder Review Inbox Was RE: Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

Asselin, Ramy ramy.asselin at hp.com
Tue Mar 24 19:38:55 UTC 2015


Changing the topic.

Mike Perez did include a Cinder Review Inbox link on the main Cinder Wiki page.
https://wiki.openstack.org/wiki/Cinder#Resources

Not sure how many people/cores use that link but that could be a step towards what you’re asking for.
The query should probably be proposed to http://git.openstack.org/cgit/stackforge/gerrit-dash-creator/tree/dashboards

Ramy


From: Rochelle Grober [mailto:rochelle.grober at huawei.com]
Sent: Tuesday, March 24, 2015 12:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

One other item I’d like to bring up.

While Nova and Neutron are well distributed around the globe and have Core Reviewers on IRC in the Asia daytime, some other projects are not so well distributed as yet.  A problem I noticed a number of times is that an Asia based developer will post to the mailing list to get some attention for  his/her patch.  This is frowned upon in the community, but when there are few to no Core Reviewers in IRC, getting that first core review can be difficult.  Emailing the PTL is something I’m sure the PTLs would like to limit as they are already swamped.  So, how do we get timely first core review of patches in areas of the world where Core presence in IRC is slim to none?

I can think of a few options but they don’t seem great:

·         A filter for dashboards that flags reviews with multiple +1s and no core along with a commitment of the Core team to perform a review within x number of days

·         A separate mailing list for project review requests

·         Somehow queueing requests in the IRC channel so that offline developers can easily find review requests when looking at channel logs

·         ???

Solving this issue could help not just Third Party developers, but all of OpenStack and make the community more inviting to Asian and Australian (and maybe European and African) developers.

--Rocky

From: Rochelle Grober [mailto:rochelle.grober at huawei.com]
Sent: Monday, March 23, 2015 14:51
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

I’d like to suggest that the myriad wiki pages and spreadsheets for Third Party CI also be consolidated to a more manageable count.  Just looking for maintainers contact, you can find information (often conflicting) in Stackalytics, on the ThirdPartyDrivers page, on the Cinder PTL’s google doc and who knows where else for the Neutron maintainers.  Even finding which tests to run takes linking through a number of Cinder wiki pages.

The teams have done a great job documenting a process that started out as lore, but I think the beginning of L would be a great time to revisit and reorganize the documentation for clarity, conciseness and single locations (version controlled) of critical information.

--Rocky

From: Patrick East [mailto:patrick.east at purestorage.com]
Sent: Monday, March 23, 2015 14:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

On Mon, Mar 23, 2015 at 12:59 PM, Stefano Maffulli <stefano at openstack.org<mailto:stefano at openstack.org>> wrote:
On Mon, 2015-03-23 at 11:43 -0700, Mike Perez wrote:
> We've been talking about CI's for a year. We started talking about CI deadlines
> in August. If you post a driver for Kilo, it was communicated that you're
> required to have a CI by the end of Kilo [1][2][3][4][5][6][7][8]. This
> should've been known by your engineers regardless of when you submitted your
> driver.

Let's work to fix the CI bits for Liberty and beyond. I have the feeling
that despite your best effort to communicate deadlines, some quite
visible failure has happened.

I think the only failure is on the side of any driver maintainers who did not make the deadlines. From my perspective (as one of the driver maintainers who did setup a CI system and a developer working on Cinder) this whole process has been a success. The test coverage has sky rocketed for Cinder, driver maintainers are forced to be a bit more active in the community, and the code base (in theory) no longer has volume drivers in tree that we don't know if they actually work or not. This is, in my opinion, a huge win for the project.

You've been clear about Cinder's deadlines, I've been trying to add them
also to the weekly newsletter, too.

To the people whose drivers don't have their CI completed in time: what
do you suggest should change so that you won't miss the deadlines in the
future? How should the processes and tool be different so you'll be
successful with your OpenStack-based products?

For anyone who struggled with getting a CI system operational there are numerous resources at your disposal (all of which have been advertised in Cinder meetings and the #openstack-cinder IRC channel). There are three meetings every week where you can get help setting them up [1]. There are a few different Cinder developers who have set up their own CI systems and shared code/instructions [2][3]. I have seen those same devs supporting them via IRC and have enabled several other companies to successfully use their tools. Between these resources I don't think anyone who has actually showed up at the meetings, asked for help, and make a good faith effort to keep everyone in the loop and show progress failed to get their system online and keep their driver in Cinder.... its not a coincidence.

There are also efforts to provide an easier to use CI system that is shared with the OpenStack infra team [4]. I would recommend anyone who wants to help ease this process for new drivers/maintainers to help contribute to this effort. I think this is going to be the best route forward to ensure people have the tools they need to setup and operate a stable third party ci system.


1 - https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings
2 - https://github.com/rasselin/os-ext-testing
3 - https://github.com/j-griffith/sos-ci
4 - https://review.openstack.org/#/c/139745/


-Patrick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150324/64cfb01b/attachment.html>


More information about the OpenStack-dev mailing list