aboutsummaryrefslogtreecommitdiffstats
path: root/kubernetes/sdnc/components/sdnc-ansible-server/values.yaml
blob: a674f78b4ba990b2b3f1cab0a1ee5eafa10d2217 (plain)
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
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
# Copyright © 2017 Amdocs, Bell Canada
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

#################################################################
# Global configuration defaults.
#################################################################
global:
  nodePortPrefix: 302
  readinessImage: onap/oom/readiness:3.0.1
  loggingRepository: docker.elastic.co
  loggingImage: beats/filebeat:5.5.0
  # envsusbt
  envsubstImage: dibi/envsubst
  mariadbGalera:
    #This flag allows SO to instantiate its own mariadb-galera cluster
    #If shared instance is used, this chart assumes that DB already exists
    localCluster: false
    service: mariadb-galera
    internalPort: 3306
    nameOverride: mariadb-galera

#################################################################
# Secrets metaconfig
#################################################################
secrets:
  - uid: db-secret
    name: &dbSecretName '{{ include "common.release" . }}-sdnc-ansible-server-db-secret'
    type: basicAuth
    # This is a nasty trick that allows you override this secret using external one
    # with the same field that is used to pass this to subchart
    externalSecret: '{{ ternary "" (tpl (default "" (index .Values "mariadb-galera" "config" "userCredentialsExternalSecret")) .) (hasSuffix "sdnc-ansible-server-db-secret" (index .Values "mariadb-galera" "config" "userCredentialsExternalSecret"))}}'
    login: '{{ index .Values "mariadb-galera" "config" "userName" }}'
    password: '{{ index .Values "mariadb-galera" "config" "userPassword" }}'
    passwordPolicy: required
  - uid: rest-creds
    type: basicAuth
    externalSecret: '{{ tpl (default "" .Values.config.restCredsExternalSecret) . }}'
    login: '{{ .Values.config.restUser }}'
    password: '{{ .Values.config.restPassword }}'
    passwordPolicy: required

#################################################################
# Application configuration defaults.
#################################################################
# application image
repository: nexus3.onap.org:10001
image: onap/sdnc-ansible-server-image:2.0.3
pullPolicy: Always

# flag to enable debugging - application support required
debugEnabled: false

# application configuration
config:
  sdncChartName: sdnc
  configDir: /opt/onap/sdnc
  restUser: sdnc
  restPassword: sdnc
  # restCredsExternalSecret: some secret

mariadb-galera:
  config:
    userCredentialsExternalSecret: *dbSecretName
    userName: sdnc
    userPassword: sdnc
    mysqlDatabase: ansible
  nameOverride: ansible-server-galera
  service:
    name: ansible-server-galera
    portName: ansible-server-galera
    internalPort: 3306
  replicaCount: 1
  persistence:
    enabled: true
    mountSubPath: ansible-server/maria/data

# default number of instances
replicaCount: 1

nodeSelector: {}

affinity: {}

# probe configuration parameters
liveness:
  initialDelaySeconds: 180
  periodSeconds: 10
  # necessary to disable liveness probe when setting breakpoints
  # in debugger so K8s doesn't restart unresponsive container
  enabled: true

readiness:
  initialDelaySeconds: 60
  periodSeconds: 10

service:
  type: ClusterIP
  name: sdnc-ansible-server
  portName: sdnc-ansible-server
  internalPort: 8000
  externalPort: 8000

ingress:
  enabled: false

#Resource Limit flavor -By default using small
flavor: small

#Segregation for Different environment (Small and Large)

resources:
  small:
    limits:
      cpu: 1
      memory: 1Gi
    requests:
      cpu: 0.5
      memory: 500Mi
  large:
    limits:
      cpu: 2
      memory: 2Gi
    requests:
      cpu: 1
      memory: 1Gi
  unlimited: {}
tor:latest "bash dmaap-sim.sh" 4 days ago Up 4 days 0.0.0.0:3904->3904/tcp message-router 60cfcf8cfe65 mariadb:10.2.14 "docker-entrypoint.s…" 4 days ago Up 4 days 0.0.0.0:3306->3306/tcp mariadb VM2 Only: Install Distribution ------------------------------ Modify the setup_distribution.sh script located at: - ~/distribution/testsuites/stability/src/main/resources/distributionsetup/setup_distribution.sh Ensure the correct docker image version is specified - e.g. for Guilin-RC0: - nexus3.onap.org:10001/onap/policy-distribution:2.4.2 Run the setup_distribution.sh script to install the distribution service, provide the IP of VM1 (twice) as the arguments to the script: .. code-block:: bash ~/distribution/testsuites/stability/src/main/resources/distributionsetup/setup_distribution.sh <vm1-ipaddr> <vm1-ipaddr> Ensure the distribution container is running. .. code-block:: bash $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 9a8db2bad156 nexus3.onap.org:10001/onap/policy-distribution:2.4.2 "bash ./policy-dist.…" 29 hours ago Up 29 hours 0.0.0.0:6969->6969/tcp, 0.0.0.0:9090->9090/tcp policy-distribution VM2 Only: Install JMeter ------------------------ Download and install JMeter .. code-block:: bash # Install required packages sudo apt install -y wget unzip # Install JMeter mkdir -p jmeter wget https://archive.apache.org/dist/jmeter/binaries/apache-jmeter-5.1.1.zip unzip -qd jmeter apache-jmeter-5.1.1.zip rm apache-jmeter-5.1.1.zip VM2 Only: Install & configure visualVM -------------------------------------- VisualVM needs to be installed in the virtual machine running Distrbution (VM2). It will be used to monitor CPU, Memory and GC for Distribution while the stability tests are running. .. code-block:: bash sudo apt install -y visualvm Run these commands to configure permissions .. code-block:: bash # Create Java security policy file for VisualVM sudo cat > /usr/lib/jvm/java-11-openjdk-amd64/bin/visualvm.policy << EOF grant codebase "jrt:/jdk.jstatd" { permission java.security.AllPermission; }; grant codebase "jrt:/jdk.internal.jvmstat" { permission java.security.AllPermission; }; EOF # Set globally accessable permissions on policy file sudo chmod 777 /usr/lib/jvm/java-11-openjdk-amd64/bin/visualvm.policy Run the following command to start jstatd using port 1111 .. code-block:: bash /usr/lib/jvm/java-11-openjdk-amd64/bin/jstatd -p 1111 -J-Djava.security.policy=/usr/lib/jvm/java-11-openjdk-amd64/bin/visualvm.policy & Run visualVM to connect to localhost:9090 .. code-block:: bash visualvm & This will load up the visualVM GUI Connect to Distribution JMX Port. 1. Right click on "Local" in the left panel of the screen and select "Add JMX Connection" 2. Enter the Port 9090. this is the JMX port exposed by the dsitribution container 3. Double click on the newly added nodes under "Local" to start monitoring CPU, Memory & GC. Example Screenshot of visualVM .. image:: images/distribution-s3p-vvm-sample.png Stability Test of Policy Distribution +++++++++++++++++++++++++++++++++++++ Introduction ------------ The 72 hour Stability Test for policy distribution has the goal of introducing a steady flow of transactions initiated from a test client server running JMeter. The policy distribution is configured with a special FileSystemReception plugin to monitor a local directory for newly added csar files to be processed by itself. The input CSAR will be added/removed by the test client(JMeter) and the result will be pulled from the backend(PAP and PolicyAPI) by the test client (JMeter). The test will be performed in an environment where Jmeter will continuously add/remove a test csar into the special directory where policy distribuion is monitoring and will then get the processed results from PAP and PolicyAPI to verify the successful deployment of the policy. The policy will then be undeployed and the test will loop continuously until 72 hours have elapsed. Test Plan Sequence ------------------ The 72h stability test will run the following steps sequentially in a single threaded loop. - **Delete Old CSAR** - Checks if CSAR already exists in the watched directory, if so it deletes it - **Add CSAR** - Adds CSAR to the directory that distribution is watching - **Get Healthcheck** - Ensures Healthcheck is returning 200 OK - **Get Statistics** - Ensures Statistics is returning 200 OK - **CheckPDPGroupQuery** - Checks that PDPGroupQuery contains the deployed policy - **CheckPolicyDeployed** - Checks that the policy is deployed - **Undeploy Policy** - Undeploys the policy - **Delete Policy** - Deletes the Policy for the next loop - **Check PDP Group for Deletion** - Ensures the policy has been removed and does not exist The following steps can be used to configure the parameters of the test plan. - **HTTP Authorization Manager** - used to store user/password authentication details. - **HTTP Header Manager** - used to store headers which will be used for making HTTP requests. - **User Defined Variables** - used to store following user defined parameters. ========== =============================================== **Name** **Description** ========== =============================================== PAP_HOST IP Address or host name of PAP component PAP_PORT Port number of PAP for making REST API calls API_HOST IP Address or host name of API component API_PORT Port number of API for making REST API calls DURATION Duration of Test ========== =============================================== Screenshot of Distribution stability test plan .. image:: images/distribution-s3p-testplan.png Running the Test Plan --------------------- Edit the /tmp folder permissions to allow the testplan to insert the CSAR into the /tmp/policydistribution/distributionmount folder .. code-block:: bash sudo mkdir -p /tmp/policydistribution/distributionmount sudo chmod -R a+trwx /tmp From the apache JMeter folder run the test for 72h, pointing it towards the stability.jmx file inside the testplans folder and specifying a logfile to collect the results .. code-block:: bash ~/jmeter/apache-jmeter-5.1.1/bin/jmeter -n -t ~/distribution/testsuites/stability/src/main/resources/testplans/stability.jmx -Jduration=259200 -l ~/20201016-1715-distr-stability.jtl & Test Results ------------ **Summary** - Stability test plan was triggered for 72 hours. - No errors were reported **Test Statistics** .. csv-table:: Stability Results - Summary Report :file: csv/20201016-1715-distr-stability-summary.csv :header-rows: 1 .. csv-table:: Stability Results - Aggregate Report :file: csv/20201016-1715-distr-stability-aggregate.csv :header-rows: 1 **VisualVM Screenshots** .. image:: images/20201016-1715-distr-stability-20201018T2040-monitor.png .. image:: images/20201016-1715-distr-stability-20201018T2040-threads.png Performance Test of Policy Distribution +++++++++++++++++++++++++++++++++++++++ Introduction ------------ The 4h Performance Test of Policy Distribution has the goal of testing the min/avg/max processing time and rest call throughput for all the requests when the number of requests are large enough to saturate the resource and find the bottleneck. It also tests that distribution can handle multiple policy CSARs and that these are deployed within 30 seconds consistently. Setup Details ------------- The performance test is based on the same setup as the distribution stability tests. Test Plan Sequence ------------------ Performance test plan is different from the stability test plan. - Instead of handling one policy csar at a time, multiple csar's are deployed within the watched folder at the exact same time. - We expect all policies from these csar's to be deployed within 30 seconds. - There are also multithreaded tests running towards the healtchcheck and statistics endpoints of the distribution service. Running the Test Plan --------------------- Edit the /tmp folder permissions to allow the Testplan to insert the CSAR into the /tmp/policydistribution/distributionmount folder. .. code-block:: bash sudo mkdir -p /tmp/policydistribution/distributionmount sudo chmod -R a+trwx /tmp From the apache JMeter folder run the test for 4h, pointing it towards the performance.jmx file inside the testplans folder and specifying a logfile to collect the results .. code-block:: bash ~/jmeter/apache-jmeter-5.1.1/bin/jmeter -n -t ~/distribution/testsuites/performance/src/main/resources/testplans/performance.jmx -Jduration=14400 -l ~/20201020-1730-distr-performance.jtl & Test Results ------------ **Summary** - Performance test plan was triggered for 4 hours. - No errors were reported **Test Statistics** .. csv-table:: Performance Results - Summary Report :file: csv/20201020-1730-distr-performance-summary.csv :header-rows: 1 .. csv-table:: Performance Results - Aggregate Report :file: csv/20201020-1730-distr-performance-aggregate.csv :header-rows: 1 **VisualVM Screenshots** .. image:: images/20201020-1730-distr-performance-20201020T2025-monitor.png .. image:: images/20201020-1730-distr-performance-20201020T2025-threads.png