Black used with the '-l 79 -S' flags.
A future change will ignore this commit in git-blame history by adding a
'git-blame-ignore-revs' file.
Change-Id: I356643d06b2cd408ccaedfe02b858aea55388949
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
OSC has historically relied on project-specific clients like novaclient
for library bindings. These did not support auto-negotiation of
versions. Instead, users were advised to set the requested microversion
to e.g. '2.latest' to opt into the latest API version supported by the
client.
We're slowly migrating everything to SDK which *does* support
auto-negotiation (well, of sorts). This makes versions like '2.latest'
unecessary and SDK correctly warns the user about this.
You have a configured API_VERSION with 'latest' in it. In the context
of openstacksdk this doesn't make any sense.
Unfortunately, we have not yet migrated all commands to SDK, meaning we
have a mix of SDK and legacy client-based commands. So long as there are
any command using the legacy client, we can't insist on users removing
this configuration. This makes the warning both annoying and something
the user can't do anything about. We also don't want to remove the
warning from SDK so instead we opt to filter it out, along with all
other warnings from openstacksdk (which similarly a user can't do
anything about).
Change-Id: If8a7cf9bc876f84864d66f5aed5f2f61c5d0696a
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
With python3.x, classes can use 'metaclass=' instead of
'six.add_metaclass', 'six.iteritems' and 'six.iterkeys' can
be replaced by 'items' and 'keys', 'six.moves.urllib.parse'
can be replaced by 'urllib.parse', 'six.StringIO' and
'six.moves.cStringIO' can be replaced by 'io.StringIO',
'six.text_type' and 'six.string_type' are just 'str'.
Change-Id: I84848c0bf8ab3c36dd821141191e2725e4e3b58b
osc-lib's OpenStackShell.prepare_to_run_command has been a superset of
python-openstackclient's since at least osc-lib 1.4.0. We require 1.14.0
now, so the redundant override can be removed.
Change-Id: I5658e3df5af1100e139623505d0375588edae63c
* Remove unnecessary code in OpenStackShell.initialize_app() - only
the bits it instantiate our subclass of ClientManager remain
* Remove OSC_Config - with https://review.opendev.org/#/c/678095/
the last remaining required bit moves to osc-lib
Thos requires osc-lib 1.14.0
Change-Id: Ia4b3c737de9dc34949e74632441621014ef9eea9
Signed-off-by: Dean Troyer <dtroyer@gmail.com>
Pick up newer versions of this library. Thankfully no serious changes
are needed.
Change-Id: I69e523844529fc1c8aa0c1ce764182dbe29cfeb6
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The token_endpoint was a compatibility auth type to maintain support
for the --url global option that dated back to the beginning of
OpenStack CLI auth. The common keystoneauth library implements
'admin_token' which provides the same functionality using
--endpoint rather than --url.
Change-Id: I1b9fbb96e447889a41b705324725a2ffc8ecfd9f
Signed-off-by: Dean Troyer <dtroyer@gmail.com>
Shell.py contains lines to import osprofiler. This is useless
because osprofiler options support code was moved to osc-lib.
Removed it.
Change-Id: Ibec17700c87df908640848c3787d190ca66a7bcf
Closes-Bug: #1707103
The commands that do not require authentication sometimes still need
to call ClientManager.is_network_endpoint_enabled() to see if Neutron
is available. Optimize the paths a bit to skip auth when it is not
necessary; the upshot is Neutron will be assumed in these cases now.
This gets a LOT cleaner when it appears is a future osc-lib.
Change-Id: Ifaddc57dfa192bde04d0482e2cdcce111313a22a
Don't do it.
os-client-config's plugin loading has been causing this pain for a long
time, removing the KSC hack-around in o-c-c unmasked this again. So when
auth is not reuired, just don't let o-c-c do any plugin loading at all.
Ever.
Of course, this shouldn't be in OSC either, but we have to do this until
the equivalent fix lands in osc-lib, is released and makes it into the
global requirements minimum version.
Depends-on: Ie68c82f7b073012685f0513b615ab1bf00bc0c3a
Change-Id: Ifdf65f3bb90fb923947a2cbe80a881d71a3fee56
When the service name end with keyword "os", like: antiddos,
the parsing logic isn't suitable, that cause the service api
version specified by users don't work.
Change-Id: I5d6217c77d7cd2d2f360d78d8561261398b96685
Closes-Bug: #1658614
When an exception was caught and rethrown, it should
call 'raise' without any arguments because it shows
the place where an exception occured initially instead
of place where the exception re-raised
Change-Id: I3ec3680debbfad7c06f2251396e0e8e4e3df6c50
Auth option prompting happens waaaay to early in the default
os-client-config flow, we need to defer it until adter the commands
have been parsed. This is why ClientManager.setup_auth() exists,
as it is not called until the first attempt to connect to a server
occurs. Commands that do not require authentication never hit this.
Also, required options were not being enforced. By doing this we handle
when no authentication info is present, we fail on missing auth-url rather
than attempt to prompt for a password (default auth is password).
Closes-Bug: 1619274
Change-Id: Ia4eae350e6904c9eb2c8507d9b3429fe52418726
We start by fixing this in the already-present OSC_Config class so OSC
can move forward. This change needs to get ported down into
os-client-config in the near future, maybe even soon enough to make the
client library freeze this week.
* Add the pw-func argument to the OSC_Config (or OpenStackConfig) __init__()
* When looping through the auth options from the KSA plugin look for any
that have a prompt defined and do not have a value already, so ask for one.
Closes-bug: #1617384
Change-Id: Ic86d56b8a6844516292fb74513712b486fec4442
The split to osc-lib shell lost the detection of --os-token and
--os-url to set --os-auth-type token_endpoint
Closes-bug: 1615988
Change-Id: I248f776a3a7b276195c162818f41ba20760ee545
Fix argument precedence hack
Working around issues in os-client-config <= 1.18.0
This is ugly because the issues in o-c-c 1.19.1 run even deeper
than in 1.18.0, so we're going to use 1.19.0 get_one_cloud() that
is known to work for OSC and fix o-c-c with an axe.
Remove return values for set commands
'identity provider set' and 'service provider set' were still
returning their show-like data, this is a fail for set commands
now, don't know how this ever passed before...
Constraints are ready to be used for tox.ini
Per email[1] from Andreas, we don't need to hack at install_command
any longer.
[1] http://openstack.markmail.org/thread/a4l7tokbotwqvuoh
Co-authorioed-by: Steve Martinelli <s.martinelli@gmail.com>
Depends-On: I49313dc7d4f44ec897de7a375f25b7ed864226f1
Change-Id: I426548376fc7d3cdb36501310dafd8c44d22ae30
Convert to using ClientManager and OpenStackShell from osc-lib.
* Change all internal uses of ClientManager private attributes that are
now public in osc-lib's ClientManager. Leave back-compat copies in
place in OSC's clientManager so we don't break plugins.
* Put some work-arounds in place for changes in osc-lib that we need until
a new release makes it through the g-r and u-c change process.
* Add a test for Unicode decoding of argv in shell.main() to parallel
the one in osc-lib.
Change-Id: I85289740d4ca081f2aca8c9b40ec422ad25d302c
When the openstackclient in Python2 passes command line arguments to a
subcommand it fails to pass the arguments as text
(e.g. Unicode). Instead it passes the arguments as binary data encoded
using the current locales encoding.
An easy way to see this is trying to pass a username with a non-ASCII
character.
% openstack user delete ñew
No user with a name or ID of 'ñew' exists.
What occurs internally is when the user data is retrieved it's it
properly represented in a Unicode object. However the username pased
from the command line is still a str object encoded in the locales
encoding (typically UTF-8). A string comparison is attempted between
the encoded data from the command line and the Unicode text found in
the user representation. This seldom ends well, either the comparison
fails to match or a codec error is raised.
There is a hard and fast rule, all text data must be stored in Unicode
objects and the conversion from binary encoded text to Unicode must
occur as close to the I/O boundary as possible. Python3 enforces this
behavior automatically but in Python2 it is the programmers job to do
so.
In the past there have been attempts to fix problems deep inside
internal code by attempting to decode from UTF-8. There are two
problems with this approach. First, internal code has no way to
accurately know what encoding was used to encode the binary data. This
is way it needs to be decoded as close to the I/O source as possible
because that is the best place to know the actual encoding. Guessing
UTF-8 is at best a heuristic. Second, there must be a canonical
representation for data "inside" the program, you don't want dozens of
individual modules, classes, methods, etc. performing conversions,
instead they should be able to make the assumption in what format text
is represented in, the format for text data must be Unicode. This is
another reason to decode as close to the I/O as possible.
In Python3 the argv strings are decoded from the locales encoding by
the interpreter. By the time any Python3 code sees the argv strings
they will be Unicode. However in Python2 there must be explicit code
added to decode the argv strings into Unicode.
The conversion of sys.argv into Unicode only occurs when argv is not
passed to OpenStackShell.run(). If a caller of OpenStackShell.run()
supplies their own arg it is their responsiblity to assure they are
passing actual text objects. Consider this a requirement of the API.
Note: This patch does not contain a unittest to exercise the behavior
because it is difficult to construct a test that depends on command
invocation from a shell. The general structure of the unit tests is to
pass fake argv into OpenStackShell.run() as if it came from a
shell. Because the new code only operates when argv is not passed and
defaults to sys.argv it conflicts with the unittest design.
Change-Id: I779d260744728eae8455ff9dedb6e5c09c165559
Closes-Bug: 1603494
Signed-off-by: John Dennis <jdennis@redhat.com>
* Add compatibility for plugin v2 interface removed from osc-lib
* ClientManager.is_network_endpoint_enabled() is wrapper for
new is_service_available()
Change-Id: I6f26ce9e4d0702f50c7949bacfbeeb0f98cddb5d
When an exception was caught and rethrown,
it should call 'raise' without any arguments
because it shows the place where an exception
occured initially instead of place where the exception re-raised.
Change-Id: I5fb6dea5da7fb6e1e2b339a713c7d37f8c99e407
This changes the scope validation to occur after a token has already
been created.
Previous flow:
1. Validate authentication options.
2. Validate authorization options if the command requires a scope.
3. Create a token (using authentication + authorization options)
4. Run command.
This means that scope was being checked, even if a default scope was
applied in step 3 by Keystone.
New flow:
1. Validate authentication options.
2. Create token (using authentication + authorization options)
3 Validate authorization options if the command requires a scope and
the token is not scoped.
4. Run command.
Change-Id: Idae368a11249f425b14b891fc68b4176e2b3e981
Closes-Bug: 1592062
Use osc-lib directly for exceptions.
Leave openstackclient.common.exceptions for deprecation period.
Change-Id: Iea3e862302372e1b31ccd27f69db59b4953ca828
The --enable option on commands is ignored when the arguments are parsed.
This is related to the --enable-beta-commands option. Renaming the option
to --os-beta-command fixes the problem.
There's no need to handle backwards compatibility for the option name
change because there hasn't been an OSC release yet with beta commands.
Change-Id: I0327ba8a2058858a83e9a42e231470ed733cc834
Closes-Bug: #1588384
* The --profile global option is deprecated but will be supported
through at least April 2017.
* Update man page
Closes-bug: #1571812
Change-Id: I2e623411a56096b4cc352f4eedbf770632ae2cc3
In Python 2, dict.keys() will return a list.
But in Python 3, it will return an iterator.
So we need to fix all the places that assuming
dict.keys() is a list.
Change-Id: I8d1cc536377b3e5c644cfaa0892e40d0bd7c11b1
Closes-Bug: #1556350
Fix typo introduced in OSprofiler intergation commit, that
leaded to non-working interactive mode of the CLI client.
Change-Id: If5dfc90dbbe64d4665c3e33e936f0cc674738351
Closes-Bug: 1551160
This will allow to trigger profiling of various services that
allow it currently and which APIs support is added to openstackclient.
Cinder and Glance have osprofiler support already, Nova and Keystone
are in progress.
To use this functionality osprofiler (and its storage backend) needs
to be installed in the environment. If so, you will be able to trigger
profiling via the following command, for example:
$ openstack --profile SECRET_KEY user list
At the end of output there will be message with <trace_id>, and
to plot nice HTML graphs the following command should be used:
$ osprofiler trace show <trace_id> --html --out result.html
Related Keystone change: https://review.openstack.org/#/c/103368/
Related Nova change: https://review.openstack.org/#/c/254703/
The similar change to the keystoneclient
(https://review.openstack.org/#/c/255308/) was abandoned as new
CLI extenstions are not more accepted to python-keystoneclient.
Change-Id: I3d6ac613e5da70619d0a4781e5d066fde073b407
Make scope check optional for the "token issue" command as unscoped token is
a valid Keystone V2/V3 API.
Change-Id: Ie1cded4dbfdafd3a78c0ebdf89e3f66762509930
Closes-Bug: #1543214
'openstack --help' can display the basic information, even if
openstack command does not have permission to read clouds.yaml.
Change-Id: I7d5255c5ce3bd60af77fc70f433ca78dc011a79f
Closes-Bug: #1541047
OSC blows up if you try to use for example identity_api_version: 2
in the clouds.yaml. It will only work with a string '2'. This
fixes that.
Change-Id: I785d37a288126a1582464e907c7f9c9947bac27c
At one point this file contained the context for logging, but
the reason for its existence is now for logging.
Implements: blueprint logging-migration
Change-Id: I4ba42bbef97b09d31236ac8c01b6fb23827b8bee
The current default value for debug in cliff is False. Cloud
config assumes that it was set that way on the command line and
does not overlay it with the value from the configuration file.
Cliff bug:
https://bugs.launchpad.net/python-cliff/+bug/1483378
Change-Id: I66d82b489b2241dbcd1e1350e94259a54ce09de7
