SMO deployment for C-Release (Cherry) based on ONAP-Guilin-Release

Reference Documentation

This procedure provides:

  • ONAP-AAF
  • ONAP-DCAE
  • ONAP-DMaaP
  • ONAP-SDNC (single node, SMO functionality)
Released images:

Relevant images for released use cases:

componentImageTagRemark
SDNConap/sdnc-image2.0.4
SDNRDBbitnami/elasticsearch7.6.1
DCAEonap/org.onap.dcaegen2.deployments.k8s-bootstrap-container2.1.8VES collector
DMaaPonap/dmaap/dmaap-mr1.1.18message router

Please note: helm deployment contains more images which are not listed here.

Limitations (wip):
  • none
Prerequisites:
Setup
  • clone oom repo from gerrit.onap.org
mkdir ~/workspace
cd ~/workspace
git clone -b guilin http://gerrit.onap.org/r/oom --recurse-submodules oom_smo
cd oom_smo
sudo cp -R ~/workspace/oom_smo/kubernetes/helm/plugins/ ~/.helm
  • verifiy if local helm repo is available, otherwise follow intructions in onap setup
helm repo list
#NAME    URL
#stable  https://kubernetes-charts.storage.googleapis.com
#local   http://127.0.0.1:8879
  • build local onap helm repo
sudo apt install -y build-essential
cd ~/workspace/oom_smo/kubernetes
make repo; make SKIP_LINT=TRUE all ; make SKIP_LINT=TRUE onap
# take a coffee
helm search onap
  • create an overwrite yaml file, e.g. deploy_smo_cherry.yaml
# Copyright © 2019 Amdocs, Bell Canada
# Copyright (c) 2020 Nordix Foundation, Modifications
# Modifications Copyright © 2020 Nokia
#
# 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.

###################################################################
# This override file enables helm charts for all ONAP applications.
###################################################################
global:
  addTestingComponents: &testing true
  centralizedLoggingEnabled: ¢ralizedLogging false
cassandra:
  enabled: false
mariadb-galera:
  enabled: true
aaf:
  enabled: true
aai:
  enabled: false
appc:
  enabled: false
cds:
  enabled: false
clamp:
  enabled: false
cli:
  enabled: false
# Today, "contrib" chart that hosting these components must also be enabled
# in order to make it work. So `contrib.enabled` must have the same value than
# addTestingComponents
contrib:
  enabled: *testing
consul:
  enabled: true
dcaegen2:
  enabled: true
dcaemod:
  enabled: true
dmaap:
  enabled: true
esr:
  enabled: false
oof:
  enabled: false
msb:
  enabled: true
multicloud:
  enabled: false
nbi:
  enabled: false
policy:
  enabled: false
portal:
  enabled: false
robot:
  enabled: true
sdc:
  enabled: false
sdnc:
  enabled: true
  config:
    enableClustering: false
    sdnr:
      mountpointRegistrarEnabled: true
so:
  enabled: false
uui:
  enabled: false
vfc:
  enabled: false
vid:
  enabled: false
vnfsdk:
  enabled: false
modeling:
  enabled: false
platform:
  enabled: true
a1policymanagement:
  enabled: false


  • deploy smo

helm install -n smo local/onap --set global.masterPassword=myAwesomePasswordThatINeedToChange -f ~/workspace/smo/deploy_smo_cherry.yaml --namespace onap --timeout 900
  •  verifiy deployment
helm ls
  • verifiy pnf-registration, fault notification use case, please find examples for sending VES message in gerrit.
  • No labels

4 Comments

  1. Alexander Dehn

    Zhe Huang we can use helm plugin 'deploy' as in ONAP - OOM,

    https://docs.onap.org/projects/onap-oom/en/guilin/oom_quickstart_guide.html#quick-start-label

     sudo cp -R ~/oom/kubernetes/helm/plugins/ ~/.helm

    This would leverage from comprehensive OOM testing in ONAP.

  2. Kranthi Molleti

    Hi Alex, I am planning to deploy SMO-Cherry version you mentioned.  What is the minimum RAM required? 32 GB VM is sufficient ?

  3. Caleb Lo

    Hi - we followed the instructions on this page and were able to successfully deploy ONAP on one machine (which I'll call the "ONAP box").  We're running into some issues when trying to integrate it with a Near-RT RIC running on a separate machine (which I'll call the "RIC box").

    We checked that the "ONAP box" can talk with the "RIC box".  In particular, we created a policy type on the "RIC box" and then used curl on the "ONAP box" to see that policy type (i.e. we ran the following command on the "ONAP box": curl -X GET --header "Content-Type: application/json" --header "accept: application/json" http://105.165.70.18:22234/a1mediator/a1-p/policytypes)

    Here, 105.165.70.18 is the IP address of the "RIC box", and 22234 is the port for the r4-infrastructure-kong-proxy service.

    We then changed the application_configuration.json file (which is attached to this comment) in this directory on the "ONAP box": /root/oom_smo/kubernetes/a1policymanagement/resources/config

    We then stopped and restarted the smo-a1policymanagement pod on the "ONAP box".  We also stopped and restarted the smo-sdnc-0 pod on the "ONAP box".

    We then checked the log file (which is attached to this comment as the a1policymanagement_file) for the smo-a1policymanagement pod on the "ONAP box".  Note the error messages "Could not get protocol version from Near-RT RIC: ric1" (and the "Synchronization failure for ric: ric1, reason: Protocol negotiation failed for ric1" message near the top of the file).

    We then checked the log file (which is attached to this comment as the smo_sdnc_0_file) for the smo-sdnc-0 pod on the "ONAP box".  It appears that an issue arises for a procedure related to the "Start of getA1Policy" message.  In particular, that procedure returns a message "Error sending the request: Exception while posting http request to client URI is not absolute".

    Our understanding is that "Once the Policy Management Service is up and running, it establishes connections to all configured Near-RT RICs (ric1 and ric2) via the A1 Controller" per the instructions on this page: https://wiki.onap.org/pages/viewpage.action?pageId=92997705

    It seems that the Policy Management Service isn't connected to the configured Near-RT RIC based on the error messages that we're seeing, so any guidance would be appreciated.

    Thank you very much.

    application_configuration.jsona1policymanagement_filesmo_sdnc_0_file

    1. Caleb Lo

      A further check of the smo_sdnc_0_file (attached in the previous message) revealed several messages that included "prop.a1Mediator.url: [http://10.12.7.38:10001/a1-p]", indicating that the A1 adapter in the "ONAP box" wasn't pointing to the A1 mediator on the "RIC box".  In particular, it seems to be using the original settings for "near-rt-ric-id" and "a1Mediator.url" in the a1-adapter-api-dg.properties file (see section 7 in this link for reference: https://wiki.onap.org/display/DW/A1+Adapter+in+ONAP).

      We then stopped and restarted the smo-sdnc-0 pod on the "ONAP box".  After it restarted, we logged into that pod and modified "near-rt-ric-id" and "a1Mediator.url" in the a1-adapter-api-dg.properties file.

      We've attached the log file for the smo-sdnc-0 pod on the "ONAP box", which shows some interesting behavior.  On line 71682, it appears that the A1 adapter has picked up the modified settings, as it shows "Adding INPUT data for getA1Policy input: GetA1PolicyInput{getNearRtRicUrl=Uri{_value=http://105.165.70.18:22234//A1-P/v1/policies}, augmentations={}}".  Here, 105.165.70.18 is the IP address of the "RIC box"

      On line 102223, the operation to get all A1 policy types appears to be successful, as it shows "HTTP response: [ 20008 ]", which corresponds to the policy type "20008" (earlier, we had created that policy type on the "RIC box").

      On line 125209, though, it appears that the A1 adapter has dropped the modified settings, as it shows "Adding INPUT data for getA1Policy input: GetA1PolicyInput{getNearRtRicUrl=Uri{_value=/A1-P/v1/policies}, augmentations={}}".

      The A1 adapter doesn't seem to recover the modified settings after that, as can be seen in the remainder of the attached log file.

      We're wondering if there's some way to make the modified settings for "near-rt-ric-id" and "a1Mediator.url" persistent.

      Thank you very much.

      smo_sdnc_0_file_url_issues