* Add keystone-openidc setup code.
The keystone-openidc charm requires 2 configuration steps:
1) Configure the oidc-client-id, oidc-client-secret and
oidc-provider-metadata-url, this information is tightly related to
the Identity Provider configured, which for testing purposes this is
the openidc-test-fixture charm, the setup function
zaza.openstack.charm_tests.openidc.setup.configure_keystone_openidc
takes care of setting these values once the fixture charm is ready
for service.
2) Create the OpenStack objects to correctly configure the federation,
this is made by the setup function
zaza.openstack.charm_tests.openidc.setup.keystone_federation_setup_site1
which will create and configure the following resources:
- Create a domain named 'federated_domain'.
- Create a group named 'federated_users'.
- Grant the 'Member' role to users in the 'federated_users' group.
- Create an identity provider named 'openid'.
- Create a mapping named 'openid_mapping'.
- Create a federation protocol named 'openid' that relates the mapping
and the identity provider.
* Add support for v3oidcpassword auth plugin.
get_keystone_session() uses the v3.OidcPassword class when the
OS_AUTH_TYPE is set to v3oidcpassword, this class expects the following
extra configuration options:
- OS_IDENTITY_PROVIDER
- OS_PROTOCOL
- OS_CLIENT_ID
- OS_CLIENT_SECRET
- OS_ACCESS_TOKEN_ENDPOINT (optional)
- OS_DISCOVERY_ENDPOINT (optional)
* Add test for keystone-openidc
This patch introduces a new testing class named CharmKeystoneOpenIDCTest
which interacts with keystone using users provided by
openidc-test-fixture via OpenID Connect.
* Add keystone_session argument to launch instances.
Adding the option to pass a keystone session allows callers to use
credentials different from the ones provided by
get_overcloud_keystone_session(), this is helpful when testing non
default keystone configurations (e.g. Federation).
* Add zaza.openstack.charm_tests.openidc.tests.TestLaunchInstance
This testing class configures a private network in the user's project defined by the mapping
rules during the setUpClass stage. Specifically this test performs the following steps:
- Create keypair named 'zaza' in the user's project
- Create a router for the project
- Attach the router to the external network
- Create a network
- Create a subnet attached to the previously create network
- Connect the subnet to the project's router
The testing method launches an instance using a keystone session
associated with a user backed by OpenID Connect.
It was pinned in requirements.txt,
but this isn't picked up when installing this via pip.
So, it needs to be pinned in the setup.py install_require list too.
The workaround was specifically targeting Groovy which is now EOL.
Also remove the `current_release` class variable as it is no
longer needed.
Related-Bug: #1852221
Remove the work around for Bug #1964117 now that it is fixed
in the latest ovs package versions in ubuntu and the cloud
archive. This is fixed in the following versions of ovs:
xena (2.16.4), jammy/yoga (2.17.2), and kinetic (3.0.0).
When deployed in a non-ha setup the keystone ip can fail to be
found due to problems with getting ips of subordinates. Also,
there is duplicate code for finding the keystone ip so put this
in the setup class.
The dashboard policyd override tests assume the deloyment is http
and non-ha. This is not a safe assumption so use the existing code
to generate the correct domain listing url.
* Add functional tests for ceph-mon actions.
This PR adds functional validation for 2 actions of the ceph-mon
charm that are currently being rewritten.
Cleanup after the tests run.
Co-authored-by: Luciano Lo Giudice <luciano.logiudice@canonical.com>
`get_unit_name_from_ip_address` along with the ip from vault client
has proven flaky in this situation.
Not sure why.
But better to reload all vault units anyway,
so we can take a simpler route here.
Manila Ganesha is not always deployed in an ha configuration in
functional tests. This means there is no automated restart of the
manila services but the _restart_share_instance method shuts down
manila services via systemctl and expects them to be automatically
started. This change detects if the hacluster charm is present, if
it is it defaults it used the old behaviour otherwise systemctl
is used to restart the services.
Follow-up of #860 and #791 to fix:
File "./zaza/openstack/charm_tests/test_utils.py", line 798, in launch_guest
return configure_guest.launch_instance(
File "./zaza/openstack/configure/guest.py", line 128, in launch_instance
image_name = image_name or boot_tests[instance_key]['image_name']
KeyError: 'jammy'
Change 0af4c93d causes the target model to be ignored when a
model_name was specified. This in turn is causing the swift
cmr tests to fail as an ip of None is being recorded for
units in a different model.
This ensures initialising and unsealing works nicely
with vault using the raft backend
(which makes race conditions evident because of the time
it takes for the raft cluster to settle).
Added tests for checking positive and negative matches for the
Cache-Control and Pragma http headers.
If the requested resource is static check if these headers are
not set
Cache-Control: no-store
Pragma: no-cache
If the resource is dynamic ensure these headers are set
Cache-Control: no-store
Pragma: no-cache
