This commit is part of a series to retire the Packaging Deb
project. Step 2 is to remove all content from the project
repos, replacing it with a README notification where to find
ongoing work, and how to recover the repo if needed at some
future point (as in
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project).
Change-Id: I131bb2372ca52fd232da417e02693af5e36350cf
Set some of the new config values and enable openstackdocstheme as an
extension so it will inject values into the page context as it writes
each documentation page. This ensures the pages link to the right bug
tracker, etc.
Change-Id: Id9cc61e81aa43f4b69883d338090716005477d0a
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
We are destructive to os.environ in the OpenStackConfig constructor- so
it really should only ever be called once. Make sure get_config does
this.
Change-Id: I279bdf68408a807ec18fba634df3769c9b8fc4dc
Closes-Bug: #1691294
Unrevert the endpoint_type/interface patch. But this time around, put in
a check for API version 2.0 and only apply the interface arg if it's for
v3.
This reverts commit 4493871824.
Change-Id: Ib347ec686d4d01788ee943c4c4f809aad06d9ccf
This reverts commit 38e5eba621.
This patch introduced a bug when using Keystone v2. With this patch, the
following works:
python -c "import os_client_config; print(os_client_config.make_client('identity', auth_url='http://localhost/identity_admin', username='admin', project_name='admin', password='testtest', identity_api_version='3').roles.list())"
But changing identity_api_version from 3 to 2.0 raises an exception.
Without this patch, both 3 and 2.0 works.
Change-Id: I8d2ad71ff51a08af1166d36805b740ea272939ed
keystoneauth in newton did not have app_name or app_version
as Session parameters. Although it isn't a super common combination,
user agent strings aren't a reason to break something. Add a
simple workaround.
Change-Id: Ib5774389fefdbc190a4b78dd6784c8006afbb270
Python Argparse supports the 'append' action [1] which is super handy to allow
a user to repeat several times the same argument, each time with different
values.
This doesn't work with occ that tries to "fix argv" but raises this error:
os_client_config.exceptions.OpenStackConfigException: The following options
were given: '--foo,--foo' which contain duplicates except that one has _
and one has -. There is no sane way for us to know what you're doing.
Remove the duplicate option and try again
This patch tweak the _fix_argv() function so that it doesn't explode
if the duplicate option has no '_' not '-' in its name.
Change-Id: I4f06b6aff8d3ab1df45637399bc3a9b4b61764a9
Related-bug: #1685630
keystoneauth supports adding a user_agent info to the Session and
Adapter via app_name. Allow users to add app_name/app_name and versions as
desired. Also, add os-client-config into additional_user_agent.
As an example, once this is landed and plumbed through shade,
nodepool will set app_name='nodepool' and we'll have:
User-Agent: nodepool/0.4.0 os-client-config/1.26.1 shade/1.19.1
keystoneauth1/2.18.0 python-requests/2.13.0 CPython/2.7.12
Change-Id: I1eb4dbd2587dcbe297b5c060c3c34b68ef51ef5e
Some users are forced to use these instead of passwords (whether because
they use 2-factor auth or by policy). Document it so they know how.
Change-Id: I558c2e8d3e8b0fad0a96a361232f14443e82a35f
We have a special case to work around a thing we're pretty sure
keystoneclient used to do but apparently doesn't do anymore. Remove the
workaround.
Co-Authored-By: Jamie Lennox <jamielennox@gmail.com>
Change-Id: I873ad91816150b593d4aef13dcd1520e8c91b22a
OVH supports qcow2 images too. Update the docs and vendor json file to
reflect this. You can continue to use raw images just fine as well.
Change-Id: Ic7dc4c70c681947a0475bbabf5621672825dfb3c
At least for cinder for now, allow a consumer of get_legacy_client to
express the minimum version they find acceptable. This will use
cinder_client logic to figure out the version from the url.
As a follow on, expand this to all of the clients and make it support
microversions for the clients that support microversions. (Right now
it's just going to be major versions, so min_version=1 will throw an
exception if the cinder service returns a v1 endpoint.
Also, because we override the volume/volumev2/volumev3 service type
stuff, we need to do extra special logic in get_session_endpoint to try
all three in the case where do not have a configured api_version.
Change-Id: I7b6b3588fec9a6be892cf20d344667f0b9a62f0a
the OpenStack requirements project has modify version requirement of docutils/oslosphinx.
The link is below
https://review.openstack.org/#/c/418772/
So modify test-requirement like other project
Closes-Bug: #1666149
Change-Id: I145ba596926cac0efab75fb4a1548eea338a2d5a
Since pbr already landed and the old version of hacking seems not
work very well with pbr>=2, we should update it to match global
requirement.
Partial-Bug: #1668848
Change-Id: I09ae994782889aae05250a8e5bf9f5b630b2d502
If someone sets baremetal_api_version to 1.29 right now, we don't really
do anything with that information. Pass it through to the constructor
for ironicclient in get_legacy_client().
Change-Id: I470fbb8852eac7d5cb35aef549ac591d63f3636f
Added a flag, 'load_yaml_config' that defaults to True.
If set to false, no clouds.yaml files will be loaded. This
is beneficial if os-client-config wants to be used inside of
a service where end-user clouds.yaml files would make things
more confusing.
Change-Id: Idbc82bb931e9edf1bbcc575237c0e202e219c218
OSC doesn't use this codepath anyway (to my knowledge) and it masks
errors in exceptionally strange ways.
Change-Id: I15ec5aacb037813a98ac9ea8e9504a5d1cc90837
The mistral team copied the heinous pervsion that the cinder team
propagated upon the world and appended a version to their service_type.
That's ok - there is nice copy-pastable code here we can use to prevent
users from feeling the pain.
Change-Id: Icf280f932014e4d9abeab3e944aece125988562e
These are simple scripts I made to investigate things. Each show the
version discovery info for all of the clouds in a clouds.yaml.
Change-Id: I742a59c737c53c05851015b9734c7aa85a5466ca
Some clouds require that users add a floating IP to a server if the user
wants that server to be able to talk to things that are not on the
cloud. Some clouds do not require this and instead give servers a
directly attached IP. The only way a user can know is to boot a server,
then ask neutron for the port associated with that server, then find the
network the port came from and then try to infer whether or not that
network has the ability to route packets northbound. Of course, networks
don't actually communicate that quality directly, (router:external
doesn't mean a network routes externally, it means the network can have
a router attached to it to provide floating ips) so it's still hit and
miss.
Where we can, save the user the stress and strain of not knowing how
their cloud wants them to get an externally routable IP.
Change-Id: I1baf804ce28bc1997b2347c4648c5cc56c750ead
Remove the extraneous title markup and move the team tag include
instructions below the main project title in the readme so it renders
more nicely.
Change-Id: Icd384c81a455a3e1a86abd1f2ef84e775e06c307
Signed-off-by: Doug Hellmann <doug@doughellmann.com>