On Thu, Apr 09, 2015 at 11:05:10AM +0900, Ken'ichi Ohmichi wrote: > 2015-04-09 4:14 GMT+09:00 Sean Dague <s...@dague.net>: > > On 04/08/2015 02:58 PM, David Kranz wrote: > >> On 04/08/2015 02:36 PM, Matthew Treinish wrote: > >>> On Wed, Apr 08, 2015 at 01:08:03PM -0400, David Kranz wrote: > >>>> Since tempest no longer uses the official clients as a literal code > >>>> dependency, except for the cli tests which are being removed, the clients > >>>> have been dropping from requirements.txt. But when debugging issues > >>>> uncovered by tempest, or when debugging tempest itself, it is useful to > >>>> use > >>>> the cli to check various things. I think it would be a good service to > >>>> users > >>>> of tempest to include the client libraries when tempest is installed on a > >>>> machine. Is there a reason to not do this? > >>> i> > >>> > >>> Umm, so that is not what requirements.txt is for, we should only put what > >>> is > >>> required to run the tempest in the requirements file. It's a package > >>> dependencies > >>> list, not a list of everything you find useful for developing tempest > >>> code. > >> I was more thinking of users of tempest than developers of tempest, > >> though it is useful to both. > >> But we can certainly say that this is an issue for those who provide > >> tempest to users. > > > > I'm in agreement with Matt here. Tempest requirements should be what > > Tempest actually requires. > > > > Installing the CLI is pretty easy, it's package installed in any Linux > > distro. apt-get, yum, or even pip install and you are off and running. > > > > I don't think having Tempest side effect dragging in the CLI tools is > > useful. Those should instead be something people install themselves. > > requirements.txt needs to contain necessary packages only for > deploying Tempest as Matthew said. > but David's idea is interesting. Official clients are easy to use, and > it is nice debugging way to compare results of both Tempest and > official clients. > Since David's mail, I have another idea for debugging problems: > > How about adding a commandline option to switch API function to > tempest-lib's service clients into official clients in the future? > > We are working for tempest-lib's service clients to migrate tests from > Tempest to projects' repository, these service clients will handle > REST API operations and they would be useful for debugging because > these clients' code is based on Tempest which we are using for the > gate problems. > If official clients have the option, we can reproduce Tempest's > operation more easily when facing/debugging problems. >
So we've discussed this before, in Paris and a bit since, and building a cli, or other clients on top of the tempest clients is definitely doable. Especially after the service clients start to move into tempest-lib it would not be difficult. Although, I really don't think want to get into that game for the tempest clients, at least for as the official clients are concerned. There is still some value in having separate client implementations to keep ourselves honest in the APIs. I've talked with Dean about doing this with OSC before, and we keep coming back to having the distinct implementation for testing, to ensure we don't code around bugs. That being said if people want to do own there own as a separate client, it wouldn't be very hard to do after the migration is started. I really don't feel like having multiple client implementations really hurt OpenStack, it would probably just help make the APIs better in the long run. As an aside, I actually used to have a couple of scripts lying around to use a older version of the tempest clients to do some basic tasks against a cloud. It worked well for what it was, and I liked it because I was far more familiar with that code and debugging failures when they occurred. -Matt Treinish
pgp9Kp92QQZmY.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
