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.e...@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 <stef...@openstack.org<mailto:stef...@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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
