On Apr 24, 2013, at 10:50 AM, Dan Prince <[email protected]>
 wrote:

> 
> ----- Original Message -----
>> From: Brian Lamar <[email protected]>
> 
>> So the question again becomes how can we get XenServer into the gate.
> 
> Hi Lamar,
> 
> I understand there is a long term goal to move towards larger scale testing 
> on bare metal w/ TripleO, etc. I'm very interested in that myself too. In the 
> short/mid term however perhaps using SmokeStack (which supports testing 
> multiple/flexible configurations) would help cover the scenario you described 
> below via pre-gate testing?

I knew I was missing something big when I had finished this email. Absolutely. 
Maybe our first fight really is how we can get SmokeStack (and thus XenServer 
testing) as part of the gate.

My understanding is that the main gripe is that it needs to be easy for people 
to see what failed and for them to have access to the nodes to troubleshoot 
failures. Is this what is holding things back? I'd love to get as many 
specifics as possible so we can work on getting things integrated. This is 
probably a question for Jim/Monty.

> 
>> I imagine it going something like this:
>> 
>> 
>> 1) Hardware is provided with XenServer 6.1 installed
> 
> SmokeStack currently runs a single node (all in one) XenServer 5.6 test on 
> upstream branches and comments on them (pre-gate testing). It does this using 
> 4 Dell R710's (provided by RAX). Why not upgrade these machines to XenServer 
> 6.1 to cover this?

Sounds good to me. I think I should be able to handle this. I'm going to send 
some emails internally to get this process kicked off. If I don't reply with a 
timeline in a week can you ping me again? 

> 
>> 2) Script for Jenkins will boot XenServer VM on hardware provided
> 
> SmokeStack uses this approach as well (via something called Kytoon).
> 
>> 3) VM will be configured using...devstack?
> 
> SmokeStack uses Puppet w/ Fedora packages I maintain :). I understand people 
> have various opinions on how to deploy things... but if it works w/ packages 
> I would argue that is probably "close enough" to the test coverage you are 
> looking for. The actual configuration that is used for XenServer testing is 
> easily modifiable though so long as the puppet modules support it.

Agreed.

> 
>> 4) This script will be an unofficial gate (aka 3rd party gate) until
>> it is considered stable
>> 5) This script will be integrated into the official process either as
>> a gate-gate or a periodic-gate
> 
> SmokeStack comments on reviews pre-commit (via Bellows). It isn't a gate 
> (that ship sailed at the Diablo conference) but it is a well defined 3rd 
> party review tool ATM.
> 
> ----
> 
> Not trying to derail this into a conversation about SmokeStack. But it does 
> seem like it wouldn't take too much effort to be able to cover your concerns 
> in the short/mid term via something that is already running and commenting on 
> reviews upstream.

Yup! My sincere apologies for forgetting about SmokeStack. I've used it enough 
to know that it has caught tons of stuff for us in the past. I very much would 
like to work with you to at least get XenServer gating. Once again if we can 
get an enumerated list of apprehensions from others it will go a long way 
towards success.

> 
> Dan


_______________________________________________
OpenStack-Infra mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Reply via email to