Re: [openstack-dev] [qa] official clients and tempest
2015-04-14 8:04 GMT+09:00 Matthew Treinish : > On Thu, Apr 09, 2015 at 11:05:10AM +0900, Ken'ichi Ohmichi wrote: >> 2015-04-09 4:14 GMT+09:00 Sean Dague : >> > 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
Re: [openstack-dev] [qa] official clients and tempest
On Thu, Apr 09, 2015 at 11:05:10AM +0900, Ken'ichi Ohmichi wrote: > 2015-04-09 4:14 GMT+09:00 Sean Dague : > > 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
Re: [openstack-dev] [qa] official clients and tempest
2015-04-09 4:14 GMT+09:00 Sean Dague : > 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. 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
Re: [openstack-dev] [qa] official clients and tempest
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. -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] [qa] official clients and tempest
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. -David I get what you're going for but doing that as part of the tempest install is not the right place for it. We can put it as a recommendation in the developer documentation or have scripts somewhere which sets setups up a dev env or something. -Matt Treinish __ 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
Re: [openstack-dev] [qa] official clients and tempest
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 get what you're going for but doing that as part of the tempest install is not the right place for it. We can put it as a recommendation in the developer documentation or have scripts somewhere which sets setups up a dev env or something. -Matt Treinish pgpJHRB3WudHt.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
[openstack-dev] [qa] official clients and tempest
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? -David __ 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
