[openstack-dev] [Manila][Infra] A proposal for 3rd-party vendor CI in Manila

Csaba Henk chenk at redhat.com
Thu Jun 25 10:46:47 UTC 2015


Hi,

please find our plan here:

https://github.com/csabahenk/manila/wiki/CI-plan-for-Manila-glusterfs-drivers

Csaba

----- Original Message -----
> From: "Ben Swartzlander" <ben at swartzlander.org>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Wednesday, May 13, 2015 11:23:07 PM
> Subject: [openstack-dev] [Manila][Infra] A proposal for 3rd-party vendor CI	in Manila
> 
> We (the Manila community) have known for a while that we would like to
> have 3rd-party vendor CI similar to the Cinder project, but up until now
> the details of what that would look like have been vague. I would like
> to make a proposal for how we should proceed so we can set deadlines and
> socialize them at the design summit next week.
> 
> I'm assuming based on previous discussions that everyone understands the
> value of CI systems and there's no disagreement that Liberty is the
> right time frame to add a requirement. If not, then we need to have a
> different discussion. But if so, then I'd like to get consensus from the
> community about what the deadlines should be and how we should deal with
> drivers that can't or won't set up CI systems to test them.
> 
> 
> My proposal consists of 4 deadlines, aligned to the Liberty milestones.
> 
> liberty-1 (Jun 25)
> * Every driver must have an associated maintainer with contact
> information. We will create a wiki/etherpad to collect this information.
> * Maintainers should understand the 3rd party CI requirement and have a
> plan for how to meet the deadlines. A plan includes how and when any
> needed materials will be obtained (hardware, other compute resources,
> accounts, firewall exceptions etc).
> * Maintainers should already be in contact with #openstack-infra and
> other resources to get help with how to build a CI system if help is needed.
> 
> liberty-2 (July 30)
> * Maintainers should have created any needed accounts and obtained any
> needed resources and should be making progress towards getting the
> system to run tests on their backends.
> * Maintainers are be expected to be able to show logs of Tempest running
> on Manila with their drivers if they aren't able to report results
> directly to gerrit.
> * Any tests that aren't passing should have bugs filed to get them fixed.
> 
> liberty-3 (Sept 3)
> * CI systems are expected to be running by this point, and posting
> results to gerrit (whether successful or not).
> * Maintainers shouldn't be working on the CI system itself at this point
> but only fixing driver bugs or other issues related to stability.
> 
> liberty-rc1 (Sept 24)
> * Drivers which don't have CI systems posting successful results
> reliably will get removed from the master branch before the RC1 cut.
> 
> 
> My theory is that by creating multiple checkpoints, we can identify
> anyone who's is having issues early on and assist them, to avoid nasty
> surprises late in the release. Also, this forces maintains to at least
> start thinking about the requirement early on so they don't
> underestimate the difficultly/effort required and try to do it all a the
> last moment.
> 
> The Cinder community took roughly 12 months to go from a decision that
> CI was a good idea to having the requirement fully implemented. I
> believe the Manila community can do it in 6 months, by taking lessons
> learned from Cinder's experience, and also taking advantage of the
> excellent resources that the infra team has built up over the last year.
> 
> The specifics of the requirement are open to debate, as far as what
> deadlines we should enforce, and how we deal with drivers that don't
> meet the requirement, so please add feedback to this thread if you have
> any suggestions or disagreements. We will discuss this topic at the
> Manila weekly meeting tomorrow as well (May 14, 1500 UTC).
> 
> -Ben Swartzlander
> 
> __________________________________________________________________________
> 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