On Mon, Feb 02, 2015 at 08:07:27PM +0300, Alexandre Levine wrote: > > On 2/2/15 7:39 PM, Sean Dague wrote: > >On 02/02/2015 11:35 AM, Alexandre Levine wrote: > >>Thank you Sean. > >> > >>We'll be tons of EC2 Tempest tests for your attention shortly. > >>How would you prefer them? In several reviews, I believe. Not in one, > >>right? > >> > >>Best regards, > >> Alex Levine > >So, honestly, I think that we should probably look at getting the ec2 > >tests out of the Tempest tree as well and into a more dedicated place. > >Like as part of the stackforge project tree. Given that the right > >expertise would be there as well. It could use tempest-lib for some of > >the common parts. > > > > -Sean > We tried to find out about tempest-lib, asked Keichi Ohmichi, but it seems > that's still work in progress. Can you point us somewhere where we can > understand how to employ this technology.
Tempest-lib is the effort to break out useful pieces from the tempest repo so that they have stable interfaces and can easily be consumed externally. Right now it only has some basic functionality in it, but we are working on expanding it more constantly. If there is a needed feature from inside the tempest repo which is currently missing from the lib we can work together on migrating it over faster. > So the use cases will be: > > 1. Be able to run the suit against EC2 in nova. > 2. Be able to run the suit against stackforge/EC2. > 3. Use that for gating for both repos. These 3 things are really independent of tempest-lib. There more about how you configure the test suite to be run. (in general and in the CI) Tempest-lib is just a library which has the common functionality from tempest that is generally useful outside of the tempest repo and won't help with how you configure things to run. But, if your tests are only interacting with things only through the API 1 and 2 should be as simple as pointing it at different endpoints. > > Additional complication here is that some of the tests will have to skipped > because of functionality absence or because of bugs in nova's EC2 but should > be employed against stackforge's version. > > Could you advice how to achieve such effects? This also is just a matter of how you setup and configure your test jobs and the test suite. It would be the same pretty much wherever the tests end up. When you get a test suite setup I can help with setting things up to make this simpler. If you join the #openstack-qa channel on freenode and we can work through exactly what you're trying to accomplish with a higher throughput. -Matt Treinish > > > > >>On 2/2/15 6:55 PM, Sean Dague wrote: > >>>On 02/02/2015 07:01 AM, Alexandre Levine wrote: > >>>>Michael, > >>>> > >>>>I'm rather new here, especially in regard to communication matters, so > >>>>I'd also be glad to understand how it's done and then I can drive it if > >>>>it's ok with everybody. > >>>>By saying EC2 sub team - who did you keep in mind? From my team 3 > >>>>persons are involved. > >>>> > >>>> From the technical point of view the transition plan could look > >>>>somewhat > >>>>like this (sequence can be different): > >>>> > >>>>1. Triage EC2 bugs and fix showstoppers in nova's EC2. > >>>>2. Contribute Tempest tests for EC2 functionality and employ them > >>>>against nova's EC2. > >>>>3. Write spec for required API to be exposed from nova so that we get > >>>>full info. > >>>>4. Triage and fix all of the existing nova's EC2 bugs worth fixing. > >>>>5. Set up Tempest testing of the stackforge/ec2 (if that's possible). > >>>>6. Communicate and discover all of the existing questions and > >>>>problematic points for the switching from existing EC2 API to the new > >>>>one. Provide solutions or decisions about them. > >>>>7. Do performance testing of the new stackforge/ec2 and provide fixes if > >>>>any bottlenecks come up. > >>>>8. Have all of the above prepared for the Vancouver summit and discuss > >>>>the situation there. > >>>> > >>>>Michael, I am still wondering, who's going to be responsible for timely > >>>>reviews and approvals of the fixes and tests we're going to contribute > >>>>to nova? So far this is the biggest risk. Is there anyway to allow some > >>>>of us to participate in the process? > >>>I am happy to volunteer to shephard these reviews. I'll try to keep an > >>>eye on them, and if something is blocking please just ping me directly > >>>on IRC in #openstack-nova or bring them forward to the weekly Nova > >>>meeting. > >>> > >>> -Sean > >>> > >> > >>__________________________________________________________________________ > >>OpenStack Development Mailing List (not for usage questions) > >>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
pgp_zdXganLaI.pgp
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
