Open Stack

2015-04-14 8:04 GMT+09:00 Matthew Treinish <mtreinish at 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 <sean at 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