Open Stack

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. 

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/8957d22f/attachment.pgp>