Perform DriveTrain sanity testing¶

This section instructs you on how to perform the DriveTrain sanity testing of your deployment using the CPV - Sanity checks Jenkins pipeline. The sanity checks for DriveTrain include testing of the Gerrit, Jenkins, and OpenLDAP functionality, as well as the DriveTrain services replicas, components and versions, and the Jenkins job branch.

To perform the DriveTrain sanity testing:

1. Perform the steps 1-4 as described in Execute the CVP - Sanity checks pipeline.

2. Using the step 5 of the same procedure, specify the IMAGE, SALT_MASTER_CREDENTIALS, SALT_MASTER_URL parameters.

3. Configure the following parameters as required:

   Parameter	Description
   TESTS_SET Removed since 2019.2.4 update	Specify cvp-sanity/cvp_checks/tests/test_drivetrain.py to perform only the DriveTrain sanity testing.
   TESTS_SETTINGS Removed since 2019.2.4 update	drivetrain_version=<your_mcp_version>
   EXTRA_PARAMS Added since 2019.2.4	Specify tests/test_drivetrain.py to perform only the DriveTrain sanity testing. For example: envs: - tests_set=tests/test_drivetrain.py Added since 2019.2.7 You can override the configuration values using the override_config variable. For example: override_config: skipped_nodes: - log02 - apt03

4. Perform the remaining steps of the Execute the CVP - Sanity checks pipeline procedure.

The CPV - Sanity checks pipeline workflow for DriveTrain:

1. Run the test_drivetrain_openldap job:

   1. Obtain the LDAP server and port from the _param:haproxy_openldap_bind_port and _param:haproxy_openldap_bind_host pillars.
   2. Obtain the LDAP admin password from the _param:openldap_admin_password pillar.
   3. Using the admin user name from the openldap:client:server:auth:user pillar and password from the previous step, connect to the LDAP server.
   4. Create a test user DT_test_user.
   5. Add the created test user to the admins group.
   6. Using the test user credentials, try obtaining the information about the cvp-sanity job.
   7. Using the test user credentials, try connecting to the Gerrit server and check the list of patches created by this user.
   8. Delete the user from the admins group and from the LDAP server.

2. Run the test_drivetrain_jenkins_job job:

   1. Obtain the Jenkins server and port from the _param:haproxy_jenkins_bind_port and _param:haproxy_jenkins_bind_host pillars.

   2. Obtain the Jenkins admin password from the _param:openldap_admin_password pillar.

   3. Connect to Jenkins using the credentials from the previous steps.

   4. Execute <jenkins_test_job> on the cid node.

      Note

      The pipeline checks whether a DT-test-job exists and if it does not exist - creates a new empty DT-test-job job. You can specify another job using the jenkins_test_job option in the TESTS_SETTINGS parameter.

   5. Wait 180 seconds for the SUCCESS status of the job.

3. Run the test_drivetrain_gerrit job:

   1. Obtain the Gerrit server and port from the _param:haproxy_gerrit_bind_port and _param:haproxy_gerrit_bind_host pillars.
   2. Obtain the Gerrit admin password from the _param:openldap_admin_password pillar.
   3. Connect to Gerrit using the credentials from the previous steps.
   4. Add a new test-dt-<current_date> project.
   5. Create a new file and send it on review.
   6. As an admin user, add Code-Review +2 to the patch and merge it.
   7. Delete the test project.

4. Run the test_drivetrain_services_replicas job:

   1. Obtain the list of Docker services from the cid node.
   2. Compare the number of expected and actual number of replicas.

5. Run the test_drivetrain_components_and_versions job:

   1. Obtain the list of Docker services from the cid node.

   2. Compare the list of expected and actual list of the services.

   3. Compare the version of the service with the drivetrain_version version.

      Note

      ^{Prior to the 2019.2.4 update} The test will be skipped if drivetrain_version was not defined in the TESTS_SETTINGS parameter.

6. Run the test_jenkins_jobs_branch job:

   1. Obtain the list of all jobs from Jenkins.

   2. Compare the versions of the jobs with the drivetrain_version version.

      Note

      ^{Prior to the 2019.2.4 update} The test will be skipped if drivetrain_version was not defined in the TESTS_SETTINGS parameter.

      In MCP Build ID 2019.2.0, this test will fail due to an issue with all Jenkins jobs having the release/2019.2.0 version instead of 2019.2.0. This issue has been fixed since the 2019.2.2 maintenance update.

      The master version for the deploy-update-salt job is an expected behavior.