have multiple swim lanes of these hardware
environments (I do already) and to automate the burn-down, install,
configuration, and testing of those environments. I would like the testing
portion of this to be consistent - and I'm looking to the OpenStack
Integration Tests to be the basis
/openstack/openstack-integration-tests
is actually a merge of Kong and Stacktester.
The other point I wanted to have more clarity on was on using both novaclient
AND httplib2 to make the API requests. Though wwkeyboard did mention issues
regarding spec bug proliferation into the client, how can we
/openstack-integration-tests
is actually a merge of Kong and Stacktester.
The other point I wanted to have more clarity on was on using both novaclient
AND httplib2 to make the API requests. Though wwkeyboard did mention issues
regarding spec bug proliferation into the client, how can we best
+gavin.brebner=hp@lists.launchpad.net
[mailto:openstack-bounces+gavin.brebner=hp@lists.launchpad.net] On Behalf
Of Daryl Walleck
Sent: Wednesday, October 19, 2011 6:27 PM
To: Rohit Karajgi
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [QA] openstack-integration-tests
Hi Rohit
in a
known state is to walk it there through sequences of tests.
I believe we essentially already have this framework in place with the
openstack-integration-tests repo and the proposed (but not yet implemented) set
of tests using proboscis to enable dependencies and grouping in those tests.
-joe
@lists.launchpad.net
[mailto:openstack-bounces+donald.ngo=hp@lists.launchpad.net] On Behalf Of
Brebner, Gavin
Sent: Wednesday, October 19, 2011 10:39 AM
To: Daryl Walleck; Rohit Karajgi
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [QA] openstack-integration-tests
My 2c
To me, the end
of this to be consistent - and I'm looking to the OpenStack Integration
Tests to be the basis for that - and to which we'll be submitting back tests
working the Dashboard as it goes forward.
Something to note - (kind of buried in:
http://wiki.openstack.org/openstack-integration-test-suites
is for
the openstack-integration-tests project.
The project is currently on github and gerrit:
https://github.com/openstack/openstack-integration-tests
I think there should be a new group, perhaps openstack-qa-core, that is
the group of core committers to the project that can approve changes
jenkins, it should be included in the
community github repository.
Hi,
During the meeting today, folks asked about what the core group is for
the openstack-integration-tests project.
The project is currently on github and gerrit:
https://github.com/openstack/openstack-integration
, it should be included in the
community github repository.
Hi,
During the meeting today, folks asked about what the core group is for
the openstack-integration-tests project.
The project is currently on github and gerrit:
https://github.com/openstack/openstack-integration-tests
I think
I'd like to try to summarize and propose at least one next step for the content
of the openstack-integration-tests git repository. Note that this is only
about the actual tests themselves, and says absolutely nothing about any gating
decisions made in other sessions.
First
Matt Dietz wrote:
Ditto
On 9/12/11 2:10 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
From: Jay Pipes [jaypi...@gmail.com]
Can we discuss pulling novaclient into Nova's source tree at the design
summit?
+1
Someone should file it at summit.openstack.org, then :)
--
Thierry Carrez
@lists.launchpad.net
Subject: Re: [Openstack] Integration tests
Matt Dietz wrote:
Ditto
On 9/12/11 2:10 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
From: Jay Pipes [jaypi...@gmail.com]
Can we discuss pulling novaclient into Nova's source tree at the design
summit?
+1
Someone should file
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] Integration tests
That link shouldn't have included the +bug bit. Copy/paste fail. :(
Sent from my phone. Pardon my brevity.
___ Mailing list:
https://launchpad.net/~openstack Post to : openstack
variables even as we pass state between
related tests. I think the openstack-integration-tests would definitely benefit
from it.
I'd love to have a conversation about getting the traits outlined above adopted
into this standardized testing solution. :)
Output of our tests running: http://pastie.org
fails, and avoid global variables even as we
pass state between related tests. I think the openstack-integration-tests
would definitely benefit from it.
I'd love to have a conversation about getting the traits outlined above
adopted into this standardized testing solution. :)
Output of our tests
it uses a 3rd party library
for executing the tests. We can try merging these things together, if
that's what everyone wants.
I'd be totally cool with bringing DTest goodness into
https://github.com/sorenh/openstack-integration-tests. :)
Less duplication of effort, the better IMHO.
openstack
From: Jay Pipes [jaypi...@gmail.com]
Can we discuss pulling novaclient into Nova's source tree at the design
summit?
+1
This email may include confidential information. If you received it in error,
please delete it.
@lists.launchpad.net
Subject: Re: [Openstack] Integration tests
Regarding novaclient, I was debating this myself last night. Our backfire
suite currently uses it. However, I can see scenarios where nova has
advanced but novaclient has yet to, and because all three projects are
independently developed
Ditto
On 9/12/11 2:10 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
From: Jay Pipes [jaypi...@gmail.com]
Can we discuss pulling novaclient into Nova's source tree at the design
summit?
+1
This email may include confidential information. If you
: [Openstack] Integration tests
Regarding novaclient, I was debating this myself last night. Our backfire
suite currently uses it. However, I can see scenarios where nova has
advanced but novaclient has yet to, and because all three projects are
independently developed, we're stuck temporarily. I
everyone wants.
I'd be totally cool with bringing DTest goodness into
https://github.com/sorenh/openstack-integration-tests. :)
Less duplication of effort, the better IMHO.
openstack-integration-tests should be in the business of writing
integration tests, not multi-processing testing libraries.
-jay
Sent: Monday, September 12, 2011 3:16 PM
To: Tim Simpson; Matt Dietz; Jay Pipes
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Integration tests
On 9/12/11 2:54 PM, Tim Simpson tim.simp...@rackspace.com wrote:
It would be advantageous for the tests to only use one client, whatever
On Sep 12, 2011, at 3:16 PM, Gabe Westmaas wrote:
It would be advantageous for the tests to only use one client, whatever
it turns out to be. I think it would be most practical to use a bleeding
edge version of Nova client and add any features necessary to it in its
own repo directly or by
Subject: Re: [Openstack] Integration tests
That link shouldn't have included the +bug bit. Copy/paste fail. :(
Sent from my phone. Pardon my brevity.
___ Mailing list:
https://launchpad.net/~openstack Post to :
openstack
://github.com/openstack/openstack-integration-tests and
is managed by Gerrit like everything else (see
http://wiki.openstack.org/GerritWorkflow for details).
A bit of history:
A number of different integration test projects existed. The most
extensive ones I knew of, Kong and Stacktester, were used
That link shouldn't have included the +bug bit. Copy/paste fail. :(
Sent from my phone. Pardon my brevity.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More
27 matches
Mail list logo
