2015-04-14 8:04 GMT+09:00 Matthew Treinish <mtrein...@kortar.org>: > 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.
Interesting point. Yeah, I just did think multiple client implementations seemed redundant and better to merge them into a single. but multiple client implementations are just real OpenStack situation(many SDKs), and we have found quality issues around APIs by them. So I agree with you now. > 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. Tempest clients should be useful for debugging as the main purpose. We need to keep this feature on tempest-lib service clients also. Thanks Ken Ohmichi __________________________________________________________________________ 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
