data-api/pytest_cluster_config-example.yaml at main · stelar-eu/data-api · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
# This file contains sample configuration for running the
# python tests that require a running cluster, or initialize
# a service.
#
# For these tests to work, you have to copy this file to
# ```
# pytest_cluster_config.yaml
# ````
# and possibly adjust the settings to reflect your own test
# setup.


# Basic settings are presented below. The file is an actual file used
# by the Athena team.
#
# The comments describe the contents of the various fields.

cluster:

    # During tool execution, the executing tool (kubernetes job) must be able to
    # access the stelar api from within its container.
    API_URL: 'http://localhost/'

    # The kubectl context that will be used by the tests to access the kubernetes
    # cluster. This context must be configured with the correct namespace, and
    # must have administrator access to the STELAR deployment
    context: minikube-notls

    # Parameters provided to the execution engine.
    # These are read as is into the tests
    execution:
        # Type of execution engine, the only supported value currently is
        # 'kubernetes'
        engine: kubernetes
        # The kubernetes namespace where the STELAR test instance resides
        namespace: stelar-notls
        # Determines the manner of speaking to the kubernetes API,
        # for testing the correct value is 'kubeconfig'.
        config: kubeconfig

    # Determines an administrator-level user to the KLMS that will be used as
    # the user to run tests as.
    access:
        # Load username and password from this client context (stored in file $HOME/.stelar by default)
        client_context: 'local'
        # Path to the stelar client config file
        # client_config: /home/vsam/.stelar

        # Note: it is also possible to add username and password directly
        # In this case, make sure that these are not exposed inadvertently, e.g., by git
        # username: vsam
        # password: secret_passwd123

    # Options determine the network access to the STELAR KLMS instance
    net:
        # Whether services are reachable via https or http. Usually testing is run
        # on local minikube instances, accessible via http.
        scheme: http

        # The base domain name for this installation.
        # For the example value below, the klms api should be accessible at
        #   http://klms.minikube.notls/stelar
        dn: minikube.notls

    # Options for the postgres database
    postgres:
        # The local port where the postgres database is accessible
        # This is the port where the in-cluster database is accessible from the testing machine
        # using a port-forwarding command.
        # For example, to forward the port 5432 to the local machine, use the command
        #
        #   kubectl port-forward svc/db 5432:5432
        #
        # The test suite will execute this command before running the tests, unless
        # the local port is already in use. If the port is already in use, the test suite will
        # assume that the port-forwarding is already set up (this is useful for running
        # tests much faster, since  port-forwarding takes ~5 seconds to set up).
        #
        # Therefore, for repeated test runs, it is suggested that the user run the port-forwarding
        # command manually before running the tests.
        local_port: 5432

        # The time to wait for the port-forwarding to be set up (in seconds).
        # You may need to adjust this value depending on the speed of your machine.
        # If the port-forwarding is not set up in this time, the test suite will
        # fail saying 'psycopg2 cannot connect to the database'.
        port_forward_wait: 5