New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

README.md is abiguous/misleading about OS_TENANT environment variable for OpenStack #966

Open
cbhall opened this Issue Apr 20, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@cbhall

cbhall commented Apr 20, 2016

In one place in the README.md file regarding the setup for OpenStack, it correctly says to use '--openstack_tenant flag or OS_TENANT_NAME environment variable'. However, a few lines later it incorrectly shows an example where export OS_TENANT=myproject is used. The latter won't work.

@meteorfox

This comment has been minimized.

Collaborator

meteorfox commented Apr 20, 2016

Good catch.

There's a PR #942 that will move from the library approach to a CLI-based approach like the other provider implementations. This has the benefit that such flags will not be necessary, all that is required is that you have openstack CLI installed and configured.

@cbhall

This comment has been minimized.

cbhall commented Apr 20, 2016

Is there a time frame when PR #942 is expected to be delivered?

For various reasons we have been interested in the OpenStack APIs that are used by PerfKit. Some of the current PerfKit API usage concerns us, such as the use of Nova-networks instead of Neutron. If PerfKit is moving to use the openstack command that is installed by python-openstackclient, for better or worse PerfKit will then ultimately use which ever APIs the openstack command uses for the particular commands issued by PerfKit.

@meteorfox

This comment has been minimized.

Collaborator

meteorfox commented Apr 20, 2016

@cbhall Not a particular time frame set. The PR is in review and I need to work on the suggestions. I hope to have it merged very soon.

openstack CLI is designed to be backward compatible and will handle the compatibility issues between different API versions. For example, it would use Neutron whenever is available.

The OpenStack community recommends the OpenStack Client and has deprecated other CLIs (nova, neutron, keystone, etc)[1]. The OpenStack Client supports the core services in OpenStack in a unified and consistent manner and should keep backward compatibility for the currently supported OpenStack versions[2].

Delegating these dependencies to the openstack CLI simplifies the management and reduces the maintenance to support different OpenStack API/bindings versions in PerfKit.

[1] https://review.openstack.org/#/c/243348/5/specs/deprecate-cli.rst
[2] http://releases.openstack.org/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment