docs/integration-s3p.rst

   1 .. This work is licensed under a
   2    Creative Commons Attribution 4.0 International License.
   3 .. _integration-s3p:
   4
   5 :orphan:
   6
   7 Stability
   8 =========
   9
  10 .. important::
  11     The Release stability has been evaluated by:
  12
  13     - The daily Jakarta CI/CD chain
  14     - Stability tests
  15
  16 .. note:
  17     The scope of these tests remains limited and does not provide a full set of
  18     KPIs to determinate the limits and the dimensioning of the ONAP solution.
  19
  20 CI results
  21 ----------
  22
  23 As usual, a daily CI chain dedicated to the release is created after RC0.
  24
  25 The daily results can be found in `LF Orange lab daily results web site
  26 <https://logs.onap.org/onap-integration/daily/onap_daily_pod4_master/>`_ and
  27 `LF DT lab daily results web site <https://logs.onap.org/onap-integration/daily/onap-daily-dt-oom-master/>`_.
  28
  29 .. image:: files/s3p/jakarta-dashboard.png
  30    :align: center
  31
  32
  33 Infrastructure Healthcheck Tests
  34 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  35
  36 These tests deal with the Kubernetes/Helm tests on ONAP cluster.
  37
  38 The global expected criteria is **100%**.
  39
  40 The onap-k8s and onap-k8s-teardown, providing a snapshop of the onap namespace
  41 in Kubernetes, as well as the onap-helm tests are expected to be PASS.
  42
  43 .. image:: files/s3p/istanbul_daily_infrastructure_healthcheck.png
  44    :align: center
  45
  46 Healthcheck Tests
  47 ~~~~~~~~~~~~~~~~~
  48
  49 These tests are the traditionnal robot healthcheck tests and additional tests
  50 dealing with a single component.
  51
  52 The expectation is **100% OK**.
  53
  54 .. image:: files/s3p/istanbul_daily_healthcheck.png
  55   :align: center
  56
  57 Smoke Tests
  58 ~~~~~~~~~~~
  59
  60 These tests are end to end and automated use case tests.
  61 See the :ref:`the Integration Test page <integration-tests>` for details.
  62
  63 The expectation is **100% OK**.
  64
  65 .. figure:: files/s3p/istanbul_daily_smoke.png
  66   :align: center
  67
  68 Security Tests
  69 ~~~~~~~~~~~~~~
  70
  71 These tests are tests dealing with security.
  72 See the  :ref:`the Integration Test page <integration-tests>` for details.
  73
  74 Waivers have been granted on different projects for the different tests.
  75 The list of waivers can be found in
  76 https://git.onap.org/integration/seccom/tree/waivers?h=jakarta.
  77
  78 nodeport_check_certs test is expected to fail. Even tremendous progress have
  79 been done in this area, some certificates (unmaintained, upstream or integration
  80 robot pods) are still not correct due to bad certificate issuers (Root CA
  81 certificate non valid) or extra long validity. Most of the certificates have
  82 been installed using cert-manager and will be easily renewable.
  83
  84 The expectation is **80% OK**. The criteria is met.
  85
  86 .. figure:: files/s3p/istanbul_daily_security.png
  87   :align: center
  88
  89 Stability tests
  90 ---------------
  91
  92 Stability tests have been performed on Istanbul release:
  93
  94 - SDC stability test
  95 - Parallel instantiation test
  96
  97 The results can be found in the weekly backend logs
  98 https://logs.onap.org/onap-integration/weekly/onap_weekly_pod4_istanbul.
  99
 100 SDC stability test
 101 ~~~~~~~~~~~~~~~~~~
 102
 103 In this test, we consider the basic_onboard automated test and we run 5
 104 simultaneous onboarding procedures in parallel during 24h.
 105
 106 The basic_onboard test consists in the following steps:
 107
 108 - [SDC] VendorOnboardStep: Onboard vendor in SDC.
 109 - [SDC] YamlTemplateVspOnboardStep: Onboard vsp described in YAML file in SDC.
 110 - [SDC] YamlTemplateVfOnboardStep: Onboard vf described in YAML file in SDC.
 111 - [SDC] YamlTemplateServiceOnboardStep: Onboard service described in YAML file
 112   in SDC.
 113
 114 The test has been initiated on the Istanbul weekly lab on the 14th of November.
 115
 116 As already observed in daily|weekly|gating chain, we got race conditions on
 117 some tests (https://jira.onap.org/browse/INT-1918).
 118
 119 The success rate is expected to be above 95% on the 100 first model upload
 120 and above 80% until we onboard more than 500 models.
 121
 122 We may also notice that the function test_duration=f(time) increases
 123 continuously. At the beginning the test takes about 200s, 24h later the same
 124 test will take around 1000s.
 125 Finally after 36h, the SDC systematically answers with a 500 HTTP answer code
 126 explaining the linear decrease of the success rate.
 127
 128 The following graphs provides a good view of the SDC stability test.
 129
 130 .. image:: files/s3p/istanbul_sdc_stability.png
 131   :align: center
 132
 133 .. csv-table:: S3P Onboarding stability results
 134     :file: ./files/csv/s3p-sdc.csv
 135     :widths: 60,20,20,20
 136     :delim: ;
 137     :header-rows: 1
 138
 139 .. important::
 140    The onboarding duration increases linearly with the number of on-boarded
 141    models, which is already reported and may be due to the fact that models
 142    cannot be deleted. In fact the test client has to retrieve the list of
 143    models, which is continuously increasing. No limit tests have been
 144    performed.
 145    However 1085 on-boarded models is already a vry high figure regarding the
 146    possible ONAP usage.
 147    Moreover the mean duration time is much lower in Istanbul.
 148    It explains why it was possible to run 35% more tests within the same
 149    time frame.
 150
 151 Parallel instantiations stability test
 152 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 153
 154 The test is based on the single test (basic_vm) that can be described as follows:
 155
 156 - [SDC] VendorOnboardStep: Onboard vendor in SDC.
 157 - [SDC] YamlTemplateVspOnboardStep: Onboard vsp described in YAML file in SDC.
 158 - [SDC] YamlTemplateVfOnboardStep: Onboard vf described in YAML file in SDC.
 159 - [SDC] YamlTemplateServiceOnboardStep: Onboard service described in YAML file
 160   in SDC.
 161 - [AAI] RegisterCloudRegionStep: Register cloud region.
 162 - [AAI] ComplexCreateStep: Create complex.
 163 - [AAI] LinkCloudRegionToComplexStep: Connect cloud region with complex.
 164 - [AAI] CustomerCreateStep: Create customer.
 165 - [AAI] CustomerServiceSubscriptionCreateStep: Create customer's service
 166   subscription.
 167 - [AAI] ConnectServiceSubToCloudRegionStep: Connect service subscription with
 168   cloud region.
 169 - [SO] YamlTemplateServiceAlaCarteInstantiateStep: Instantiate service described
 170   in YAML using SO a'la carte method.
 171 - [SO] YamlTemplateVnfAlaCarteInstantiateStep: Instantiate vnf described in YAML
 172   using SO a'la carte method.
 173 - [SO] YamlTemplateVfModuleAlaCarteInstantiateStep: Instantiate VF module
 174   described in YAML using SO a'la carte method.
 175
 176 10 instantiation attempts are done simultaneously on the ONAP solution during 24h.
 177
 178 The results can be described as follows:
 179
 180 .. image:: files/s3p/istanbul_instantiation_stability_10.png
 181  :align: center
 182
 183 .. csv-table:: S3P Instantiation stability results
 184     :file: ./files/csv/s3p-instantiation.csv
 185     :widths: 60,20,20,20
 186     :delim: ;
 187     :header-rows: 1
 188
 189 The results are good with a success rate above 95%. After 24h more than 1300
 190 VNF have been created and deleted.
 191
 192 As for SDC, we can observe a linear increase of the test duration. This issue
 193 has been reported since Guilin. For SDC as it is not possible to delete the
 194 models, it is possible to imagine that the duration increases due to the fact
 195 that the database of models continuously increases. Therefore the client has
 196 to retrieve an always bigger list of models.
 197 But for the instantiations, it is not the case as the references
 198 (module, VNF, service) are cleaned at the end of each test and all the tests
 199 use the same model. Then the duration of an instantiation test should be
 200 almost constant, which is not the case. Further investigations are needed.
 201
 202 .. important::
 203   The test has been executed with the mariadb-galera replicaset set to 1
 204   (3 by default). With this configuration the results during 24h are very
 205   good. When set to 3, the error rate is higher and after some hours
 206   most of the instantiation are failing.
 207   However, even with a replicaset set to 1, a test on Master weekly chain
 208   showed that the system is hitting another limit after about 35h
 209   (https://jira.onap.org/browse/SO-3791).