Re: [openstack-dev] [qa][keystone] Adding client library related tests to tempest

On 10/18/2013 01:54 PM, Sean Dague wrote: On 10/18/2013 11:59 AM, Dolph Mathews wrote: On Fri, Oct 18, 2013 at 10:34 AM, Steven Hardy mailto:sha...@redhat.com>> wrote: Hi all, Starting a thread to discuss $subject, as requested in: https://review.openstack.org/#/c/51558/ Fir

Re: [openstack-dev] Announce of Rally - benchmarking system for OpenStack

On 10/18/2013 12:17 PM, Boris Pavlovic wrote: John, Actually seems like a pretty good suggestion IMO, at least something worth some investigation and consideration before quickly discounting it. Rather than "that's not what tempest is", maybe it's something tempest "could do". Don't know, n

Re: [openstack-dev] [qa][keystone] Adding client library related tests to tempest

Thanks, Steve. I suggested a new directory because we really need to have more complete tests of the client libs since they are not tied to particular OpenStack releases and we claim the current libs should work with older releases. That said, I did not realize the intent was to do more than te

Re: [openstack-dev] "Thanks for fixing my patch"

On 10/11/2013 02:34 PM, Clint Byrum wrote: Recently in the TripleO meeting we identified situations where we need to make it very clear that it is ok to pick up somebody else's patch and finish it. We are broadly distributed, time-zone-wise, and I know other teams working on OpenStack projects ha

Re: [openstack-dev] [Hyper-V] Havana status

On 10/11/2013 02:03 PM, Alessandro Pilotti wrote: On Oct 11, 2013, at 19:29 , Russell Bryant > wrote: On 10/11/2013 12:04 PM, John Griffith wrote: [... snip ...] Talking about new community involvements, newcomers are getting very frustrated to have to wait

[openstack-dev] [qa] Remember the difference between recheck and reverify

A lot of people have needed to do rechecks due to the current gate condition. Please remember that if you need to do this for a patch that has already been Approved, you need to use "reverify bug xxx" rather than "recheck" or the code will not merge. -David __

[openstack-dev] [qa] Consider rechecking your patches

There was a gate failure yesterday. A lot of tempest patches have a -1 from jenkins and I suspect a lot of them were victims. It would be a good idea to look at any such patches that belong to you and do a 'recheck bug 1229797 ' (or reverify as the case may be. That is the tracking bug for this

Re: [openstack-dev] Current list of confirmed PTL Candidates

On 09/25/2013 02:15 PM, Joshua Harlow wrote: I agree with all that u guys are saying and I think that the current PTL's have done a great job and I know that there is a lot to take under consideration when submitting a potential PTL candidacy and that its all about delegating, integrating, public

Re: [openstack-dev] [QA]Bug in tempest/scenario/manager.py, wrong tenant being used for the selected admin user.

On 09/17/2013 04:30 PM, Martinez, Castulo wrote: Hi Guys, I found what seems to be a bug in the tempest/scenario/manager.py module in Tempest. In the "credentials" classmethod definition for the "OrchestrationScenarioTest" class (Line 637), @classmethod *def* *credentials*(cls):

Re: [openstack-dev] [qa] nominations for tempest-core

(1|29|18|227) (89.1%) | | sdague ** | 198 (4|60|0|134) (67.7%) | | gfidente | 130 (0|55|75|0) (57.7%) | |david-kranz **| 112 (1|24|0|87) (77.7%) | | treinish ** | 109 (5|32|0|72) (66.1%) | | cyeoh-0 ** |

Re: [openstack-dev] [qa] How to do nova v3 tests in tempest

On 09/04/2013 09:11 AM, Zhu Bo wrote: hi, I'm working on bp:nova-v3-tests in tempest. The nova tests in tempest mostly have been ported into v3 and sent off. but we got some feedbacks that there was mass code duplication and suggested to do this by inheritance. So I have sent another pat

[openstack-dev] [qa] [neutron] Neutron tests in tempest

It's great that new neutron tests are being submitted to Tempest. There is an issue that the only active neutron tests in the gate are "smoke" tests. Until the full gate can be enabled, please tag any new neutron tests as 'smoke' so they run in the gate jobs. Thanks. -David _

[openstack-dev] [qa] Pitfalls of parallel tempest execution

Now that we have achieved the goal of parallel tempest in the gate using testr we have to be careful that we don't introduce tests that are flaky. This may be obvious to many of you but we should include some information in the tempest README. Here is a start. Improvements are welcome and I wi

Re: [openstack-dev] [Ceilometer] Documentation and patches

On 08/30/2013 09:22 AM, Julien Danjou wrote: On Fri, Aug 30 2013, Russell Bryant wrote: This is something we could get better at across all of OpenStack. I've been thinking about proposing requiring docs *somewhere* for everything that affects docs. For small stuff, it could be explaining it

Re: [openstack-dev] [Nova] Frustrations with review wait times

On 08/28/2013 10:31 AM, Gary Kotton wrote: Hi, I am not sure that there is a good solution. I guess that we all need to 'vasbyt' (that is Afrikaans for bite the bullet) and wait for the code posted to be reviewed. In Neutron when we were heading towards the end of a cycle and there were a ton

Re: [openstack-dev] [Nova] Frustrations with review wait times

On 08/28/2013 10:31 AM, Gary Kotton wrote: Hi, I am not sure that there is a good solution. I guess that we all need to 'vasbyt' (that is Afrikaans for bite the bullet) and wait for the code posted to be reviewed. In Neutron when we were heading towards the end of a cycle and there were a ton

Re: [openstack-dev] [qa] What is the purpose of stress test in tempest?

On 08/05/2013 07:40 AM, Koderer, Marc wrote: Hi all, After some refactoring work in tempest/stress I would like to raise a general question since I have the feeling we have different opinions about the purpose of tempest stress test. Giulio already put this topic on the agenda for the next QA me

Re: [openstack-dev] [qa] How to apply submit Nova v3 API tempest tests

On 08/02/2013 01:23 AM, Christopher Yeoh wrote: Hi, Matthew Trenish brought up an issue on one of the proposed Nova V3 API tempest tests: > So I get why you do things this way. But, unlike nova we aren't going to be able to do part1 > being a straight copy and paste. Doing so will double the

Re: [openstack-dev] Proposal for new Program: OpenStack Deployment

Rob, it's great that you folks are tackling this. I was wondering if you could give an opinion about timeline and how others could help by trying it out. When would you like to see people outside the project start trying to use it experimentally? As part of your vision, at which OpenStack rele

Re: [openstack-dev] Adding a clean shutdown for stop/delete breaks Jenkins

On 07/03/2013 12:30 PM, Day, Phil wrote: Hi Folks, I have a change submitted which adds the same clean shutdown logic to stop and delete that exists for soft reboot -- the rational being that its always better to give a VM a chance to shutdown cleanly if possible even if you're about to dele

Re: [openstack-dev] [nova] Nova API extensions NOT to be ported to v3

On 07/02/2013 10:49 AM, Russell Bryant wrote: On 07/02/2013 07:24 AM, John Garbutt wrote: On 1 July 2013 15:49, Andrew Laski wrote: On 07/01/13 at 11:23am, Mauro S M Rodrigues wrote: One more though, about os-multiple-create: I was also thinking to remove it, I don't see any real advantage to

Re: [openstack-dev] HP OpenStack Stress Test Tool

Thanks, Terry. Tempest would be a great place for stress tests. There has already been some work on Tempest stress tests and there is currently a blueprint https://blueprints.launchpad.net/tempest/+spec/stress-tests and some code https://github.com/openstack/tempest/tree/master/tempest/stress. T

Re: [openstack-dev] [nova] Nova API extensions NOT to be ported to v3

I have used it. In the case where large numbers of instances are to be created, it (in theory) allows the compute system to optimize the request. It also avoids rate limit and other such issues that could come from hundreds of calls to create a server in sequence. -David On 07/01/2013 10:23

Re: [openstack-dev] XML Support for Nova v3 API

On 06/20/2013 01:22 PM, Brant Knudson wrote: How about a mapping of JSON concepts to XML like: collections: the-value ... the-value ... values: text number This type of mapping would remove any ambiguities. Ambiguities and complexity are problems I've seen with the XML-JSON mapping

<    1   2   3