I'm certainly interested.
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Tuesday, September 24, 2013 5:12 AM
> To: dev
> Subject: Re: community testing
>
> due to lack of response, I might add.
>
> On Mon, Sep 23, 2013
t;> Sent: Wednesday, September 11, 2013 11:58 PM
>>> To: Prasanna Santhanam
>>> Cc: Mike Tutkowski; Marcus Sorensen; dev@cloudstack.apache.org; Ahmad
>>> Emneina
>>> Subject: Re: community testing
>>>
>>>
>>> While everything happen
udstack.apache.org; Ahmad
>> Emneina
>> Subject: Re: community testing
>>
>>
>> While everything happens on the mailing list, maybe we can setup a
>> meeting to discuss this. Google hangout ?
>> Anyone interested in testing could join.
>>
>> Mike
> -Original Message-
> From: sebgoa [mailto:run...@gmail.com]
> Sent: Wednesday, September 11, 2013 11:58 PM
> To: Prasanna Santhanam
> Cc: Mike Tutkowski; Marcus Sorensen; dev@cloudstack.apache.org; Ahmad
> Emneina
> Subject: Re: community testing
>
>
> W
On Sep 12, 2013, at 7:24 AM, Prasanna Santhanam wrote:
> Thanks Marcus - I wanted to work through some concrete steps for the infra now
> that we have some idea what we want to do. We should have basic product setup
> and install and a single deployvm test for all possible configurations:
>
> A
Thanks Marcus - I wanted to work through some concrete steps for the infra now
that we have some idea what we want to do. We should have basic product setup
and install and a single deployvm test for all possible configurations:
As a start can we work to setup devcloud and devcloud-kvm environment
I guess I was unaware that the test infrastructure tests various
deployment configs from the ground up, rebuilding from baremetal (I
guess?). I was initially thinking "We already test KVM, let me just
run two commands on the host to set up a volume group, then tweak the
marvin test to register it
Yeah, I would love to get a SolidFire test suite up and running and plugged
into the main builds.
On Wed, Sep 11, 2013 at 11:15 PM, Marcus Sorensen wrote:
> I think the test infra as described is great, but I think we're
> hurting a little more for basics. For example, we don't need a full
> inf
I think the test infra as described is great, but I think we're
hurting a little more for basics. For example, we don't need a full
infrastructure with hardware to ensure that the support matrix works.
I could bring up a VM with CentOS and one with Ubuntu, and test NFS,
CLVM, and RBD on each. CLVM
As Sebastien said, it's easy to get you the credentials for jenkins.
Anyone with commit rights can request for an account. In fact one is
created soon as you commit. I just need to adjust the credentials.
(We'll move to git based job configurations but later)
Citrix is unable to test various confi
Again, I'm not knocking Citrix. If anything, the issue is that they tend to
be so generous and community oriented that it surprises me when I find out
that certain donation is limited to their interests. Its perfectly
reasonable, e.g. my own donations are mostly limited to KVM.
On Sep 11, 2013 10:5
I do understand that. The email I received just triggered warning bells
because it gave me the impression that the QA team as it stands isn't
testing anything that Citrix doesn't care about, regardless of what the
community has put on the support matrix. This includes even basic configs
that the co
Yeah, that would be fantastic if I could test the SolidFire plug-in in such
a way.
I could probably get away with a virtual storage node, as well, because I'm
not testing anything that requires the real hardware.
On Wed, Sep 11, 2013 at 2:10 AM, Sebastien Goasguen wrote:
>
> On Sep 11, 2013, at
On Sep 11, 2013, at 3:02 AM, Prasanna Santhanam wrote:
> CloudStack API actions are agnostic of underlying infrastructure and
> most cases can fall into such a category as you describe. But imagine
> this - I want to test snapshots ..
>
> so i take a snapshot and verify if it backedup correctly
CloudStack API actions are agnostic of underlying infrastructure and
most cases can fall into such a category as you describe. But imagine
this - I want to test snapshots ..
so i take a snapshot and verify if it backedup correctly against a
ceph object store, nfs store or iscsi store. that sort of
That's a good question, I'm not sure how preconditions work with Marvin cases,
but I know the tests are run generically. Say I run copyvolumeToPrimary (not
sure this test exists, hypothetical at the moment), it gets run against a slew
of infrastructure configurations using local storage as well
If a test is meddling with the infrastructure then we have two
options:
1. isolate the test and run it separately when other tests aren't
running
2. prepare a deployment with those nfs storage preconfigured.
It can be difficult to always get the infra right for a test so tests
often will skip the
But if the test requires some sort of preconfiguration, what then (e.g.
test NFS primary storage would need a local or remote NFS configured)? do I
need to roll my own, or can I touch the existing test infra and do the
preconfigure?
On Sep 11, 2013 12:34 AM, "Prasanna Santhanam" wrote:
> Yes - On
Yes - Once your test goes into the repo, it should get picked in the subsequent
run.
Jenkins installations from various companies can be combined into a single
landing page. Jenkins itself doesn't support master/slave but it does through
the gearman plugin. It's something I have tried using with
I think there are jenkins slaves that run the nicera plugins on/at Schuberg
Philis housed infrastructure. The Citrix jenkins nodes also runs as slaves
that connect back to the apache owned/controlled jenkins. No reason why
testing infra need be so consolidated, it just so happens no one is putting
20 matches
Mail list logo
