keystoneauth knows about a bunch of argparse options that users
from a command line will want. We do a good job of processing them
once they've been collected, but an os-client-config user doesn't
have a great way to make sure that they register all of the options,
especially when once considers that you really want to peek at the
args to see which auth plugin has been selected so that the right
arguments can be registered and displayed.
Depends-On: Ifea90b981044009c3642b268dd639a703df1ef05
Change-Id: Ic196f65f89b3ccf92ebec39564f5eaefe8a4ae4b
The code to deal with this properly is quite sharable and we should
not care. Use requestsexceptions from the Infra team to handle it.
Change-Id: Ie20a3e1b2d8d18a4a76b34219cf12510cb1cda98
Depends-On: I52249b6d2fe04c49a9f4ed139d7625c890309ca8
We know all of the things that we need to know to return an appropriate
auth plugin from keystoneauth based on the auth parameters. This also
introduces a hard-depend on keystoneauth, which should be fine since
keystoneauth itself has a very low dependency count.
We'll also use ksa to help validate auth parameters when we're doing
the config processing.
Change-Id: Ia1a1a4adb4dcefed5d7607082e026ca7361f394d
Cache, data and config files live rooted in different places across
different OS's. Use appdirs to find where.
Depends-On: Ic939dea11b7476ec504d2bf65854a0781b1bfb39
Change-Id: I7338ae1d0442e0c5cc1ec4ae4d619fac319a4a28
The auth parameter name validation requires keystoneclient and can't be
tested if it's not there.
While we're at it - update the current requirements to be inline with
global requirements.
Change-Id: I6da62476f3851670545143184f9f29479f1caaca
