a9s Service Smoke Tests
For each a9s Data Service, the smoke-tests
errand is included.
This errand can be used to verify the main a9s Data Service features work in your environment.
It ensures:
- Service Instance can be created.
- Service Instance can be bound to CF applications.
- Applications can use the a9s Data Service (e.g. insert data into a9s PostgreSQL Service Instance).
- Service Instance can be updated to a bigger plan (vertical scaling).
- Data is still in the database after vertical scaling.
- Data can be backed up and restored.
Important
The smoke-tests
errand tries to remove the services and applications upon its completion, but the smoke-tests
errand
cannot guarantee that there are no leftovers. It is the platform operator's responsibility to monitor the smoke-tests
CF org and remove leftovers. Leftovers might slow down the system and raise costs for the environment (for example an
AWS).
General Smoke Tests Properties
- service-smoke-tests.cf.assign_space_developer_role
- service-smoke-tests.service.do_check_dashboard_sso
- service-smoke-tests.service.do_check_prometheus_streaming
- service-smoke-tests.service.asg_prefix
service-smoke-tests.cf.assign_space_developer_role
When set to true
the SpaceDeveloper
role is assigned to the configured Cloud Foundry user in the configured
organization and space, otherwise it must be manually assigned.
The SpaceDeveloper
role is necessary to execute the a9s Service Dashboard tests. See also:
service-smoke-tests.service.do_check_dashboard_sso
Default value: true
NOTE: The role is not removed from the used Cloud Foundry user afterwards.
IMPORTANT: Please be aware that if this property is set to true
, this potentially extends the permissions of the
Cloud Foundry user being used.
service-smoke-tests.service.do_check_dashboard_sso
Enables or disables Dashboard Single Sign On (SSO) smoke tests, which checks that the configured user can log in with a
single ID and password to gain access to a9s Service Dashboard. The default value is true
.
Example Ops file to disable the Dashboard SSO smoke tests:
---
- type: replace
path: /instance_groups/name=smoke-tests/jobs/name=service-smoke-tests/properties/service-smoke-tests/service/do_check_dashboard_sso
value: false
service-smoke-tests.service.do_check_prometheus_streaming
Enables or disables Prometheus platform metrics streaming tests. These tests checks if the metrics of a Service Instance
could be streamed to the Prometheus Service Instance deployed by the platform operator. That this platform operator
Prometheus is available, the operator needs to deploy the a9s Prometheus service broker and an Service Instance with the
prometheus-platform-logging
plan. This Service Instance will create the consul DNS entries needed for the metrics
streaming tests.
To disable these tests, you can use the Ops file "without-prometheus-platform-tests.yml" by deploying your service. This will disable the metrics streaming tests.
service-smoke-tests.service.asg_prefix
The prefix for the Cloud Foundry ASGs created by the a9s CF Service Guard. When the value of the property asg_prefix
has been set in the
a9s CF Service Guard, the same
value must be set here.
Default value: a9s-asg
Service Specific Test Cases
For some of the a9s Data Services, there exist some special test cases that can only be executed for the specific a9s Data Service. These special test cases will be explained in the following.
a9s PostgreSQL
Migration Tests
You can enable/disable migration tests using the property service-smoke-tests.service.do_check_migration
. The tests
are enabled by default.
If enabled, the smoke tests will run migration tests. It is basically testing the custom parameter copy_from
that is
available to the Application Developer, see Migration documentation.
For every service that you want to run migration tests, you must set the plan_migrations
property. For example:
properties:
service-smoke-tests:
service:
do_check_migration: true
services:
- name: a9s-postgresql13
plan_migrations:
- origin_service: a9s-postgresql94
origin_plan: postgresql-single-nano
target_plan: postgresql-single-nano
The property plan_migrations
can be null
to not test anything for the current service.
Otherwise, it must be an array of objects with the following keys:
origin_service
: The service name where theorigin_plan
exists.origin_plan
: The plan name for the Service Instance we do want to fill with data and migrate data from.target_plan
: The plan name within the current service we create an Service Instance with and do want to migrate data to.
For every entry in the array the test will run the following high level test logic:
- Spawn up an Service Instance with service
origin_service
and planorigin_plan
and fill it with data. - Spawn up a new Service Instance with current service and plan
target_plan
using the custom paramcopy_from
. - Validate new Service Instance copied the data from the first Service Instance.
The service names you reference must exist under properties.service-smoke-tests.service.services
, otherwise the smoke
tests might fail during migration tests since the service offering must be enabled during smoke tests initialization.
a9s Prometheus
Custom Scrape Config Test
You can enable/disable the scrape config tests using the property service-smoke-tests.service.do_check_service_cases
.
The tests are disabled by default.
If enabled, the smoke tests will run tests to ensure that a scrape config can be configured in an a9s Prometheus Service
Instance. It is basically testing the custom parameter scrape_configs
that is available to the Application Developer,
see Custom Scrape Configs.
To enable these tests, you have to set the property service-smoke-tests.service.do_check_service_cases
to true
,
e.g. with an Ops file.
---
- type: replace
path: /instance_groups/name=smoke-tests/jobs/name=service-smoke-tests/properties/service-smoke-tests/service/do_check_service_cases?
value: true
The custom parameter scrape_configs
must be modifiable by the Application User, otherwise the smoke tests might fail
during testing a custom scrape config since this property will be set during the smoke test run.
See Custom Parameter Configuration how to enable the
Application Developer to use custom parameters.