Update get_ca to include identity-credentials (#124)
* Update get_ca to include identity-credentials
When using keystone generated SSL with the identity-credentials
relation get_ca was ignoring ca data. Check both identity-service and
identity-credentials.
Update IdentityService context for service_domain_id (#121)
Newer keystone charm versions will set the service_domain_id on
an identity-service relation; update context to pick this new
data item from the relation.
Add code to retrieve keystone session and client (#120)
* Refactor authenticate_keystone
* Add get_keystone_session for creating v2 or v3 session object
depending on api version
* Add get_default_keystone_session as the standard way to retrieve
a keystone session and client.
Cinder has multiple api versions advertised in the Keystone catalog.
The endpoints test assume 3 endpoints (public, internal, admin). Allow
passing of the expected number of endpoints. In the case of cinder, 6.
* Revert "Use volumev3 for Openstack >= Pike (#65) (#66)"
This reverts commit 3aa436da7151770e104df7d2ff013fbca3cb4367.
After discussion with @ajkavanaugh (tinwood) this change conflates
the internal endpoints with api version usage for cinder API. A
new change will be used instead.
* Add VolumeAPIContext for catalog and version info
Adds a VolumeAPIContext object which provides information
about the volume api that should be in use. The VolumeAPIContext
provides information rearding the catalog_info that can be passed
directly to a configuration file which accepts a catalog_info
string.
Additionally, the volume api version string is returned for any
instances which do not accept the catalog_info string.
0a7295d...
by
=?utf-8?q?Laurent_Sesqu=C3=A8s?= <email address hidden>
contrib/network: don't panic if an interface is deleted during get_address_in_network (#107)
785eff8...
by
Dmitrii Shcherbakov <email address hidden>
Add string template rendering to core/templating (#102)
This change allows a charm writer to support specifying
config template parts in config options, or render config files based on
templates passed via relation data from other charms.
The main use-case is drop-in files which contain custom logic not
possible to predict or model in the charm code by providing relevant
config options.
For example, RBAC rules are subjective and some operators have
to implement policy based on those subjective rules which may
differ from defaults. If those rules cannot be provided via an API
to a given service and are stored in config files this is the only way
to provide desired customization options.
Related to pad.lv/1741723
In addition to #87 but for
reactive charms which mainly use this render function.
