-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathpytest_cluster_config-example.yaml
More file actions
87 lines (75 loc) · 3.62 KB
/
Copy pathpytest_cluster_config-example.yaml
File metadata and controls
87 lines (75 loc) · 3.62 KB
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