Definition

Related Epic: SDNC-887

There are two new services arround SDN-R Mountpoints planned:

  • Use DMaaP as ONAP internal communication services
  • Create two seperate bundles in ccsdk/feature-sdnr/wt
  • Overall architecture: SDNC-888

Mountpoint provider

  1. Deliver SDN-R Mountpoint status changes over DMaaP
  2. Stories are: SDNC-889 
  3. Proposed bundle name: sdnr-wt-mountpoint-state-provider
  4. Register listener to MDSAL for mountpoint changes and provide related information
  5. Related disussion: model-driven DMaaP Agent
  6. Uses ClusteredDataTreeChangeListener for NetconfChangeListener

Mountpoint registrar for VES

  1. Manage SDN-R Mountpoints
  2. Methods are: Create, Remove
  3. Stories are: SDNC-890
  4. Proposed bundle name: sdnr-wt-mountpoint-registrar
  5. VES message: pnfRegistration
  6. New!: Additional VES messages for PoC "Basic Fault Message Flow" and "Basic Configuration Message Flow": (See VES-Notification processing) 

Integration test

  1. Story: SDNC-891

Development related

Open:

  • Topic name in DMaaP for such messages: unauthenticated.VES_PNFREG_OUTPUT

Configuration files

  1. The mountpoint-registrar bundle uses 1 configuration file (it is located in the $ODL_HOME/etc directory by default) - 
    1. mountpoint-registrar.properties - Contains the consumer Java class name and the consumer properties. By default the HTTPNOAUTH transport type is used by the consumer. For other applicable transport types and their corresponding properties, please refer to - Feature configuration requirements. This properties file is auto-generated in its entirety if it does not exist. If certain properties are missing in an already existing file that is present in the $ODL_HOME/etc directory before the bundle starts, the missing properties are included automatically into the existing file. The file contains the following properties - 

[general]
dmaapEnabled=false
pnfRegConsumerClass=org.onap.ccsdk.features.sdnr.wt.mountpointregistrar.impl.DMaaPPNFRegVESMsgConsumer
TransportType=HTTPNOAUTH
host=onap-dmap:3904
topic=unauthenticated.VES_PNFREG_OUTPUT
contenttype=application/json
group=myG
id=C1
timeout=20000
limit=10000

The "dmaapEnabled" property is an important one to be aware of. By default it is set to "false", it means that DMaaP is not enabled in the system and hence we do not want the mountpoint-registrar bundle to poll for messages. When DMaaP is running, set the "dmaapEnabled" property to "true", set "host" property to the DMaaP host IP Address/Hostname and saving the file will automatically start the PNFRegistration consumer to consume messages from the DMaaP topic.

Usage

  1. Install DMaaP as per instructions in - How to set up a local DMaaP installation in Docker for testing. This is based on Amsterdam. The latest DMaaP repository can be retrieved using information in - Resources and Repositories (Deprecated)#DataMovementasaPlatform
  2. Installing and starting DMaaP as per the instructions in (1) above brings up 3 docker containers - dmaap:localadapt , dockercompose_kafka and wurstmeister/zookeeper
  3. Install VESCollector. Detailed instructions are at - https://github.com/onap/dcaegen2-collectors-ves. The DMaaP topics that VESCollector manages are present in etc/DmaapConfig.json file. cambria.topic refers to the topics that VESCollector manages. cambria.hosts value should match the IP Address/Hostname of the DMaaP instance.
  4. Once we have DMaaP, Kafka, zoopkeeper and VESCollector running, we can send pnfRegistration VES message using the pnfRegister.sh script located at https://git-highstreet-technologies.com/highstreet/sdnr-interfacing-aai-dcae. The "config" file has to be updated with the correct DCAE VES Collector communication end point
  5. On executing the pnfRegister.sh script (ex: pnfRegister.sh 1234), a VES message is sent to the VESCollector which processes the VES message and checks for conformance as per the JSON schema and if everything is fine, puts the message in the DMaaP topic
  6. Deploy SDN-R and check if the mountpoint-registrar bundle is running correctly by looking for the following messages in the karaf.log - 
    1. DMaaPPNFRegVESMsgConsumer received ResponseCode: 200
    2. DMaaPPNFRegVESMsgConsumer received ResponseMessage:
    3. No data received from fetch. Pausing 5000 ms before retry
  7. Once the mountpoint-registrar bundle is running correctly, it starts to consume any VES messages coming on the topic and creates a mountpoint in SDN-R by parsing the information in the VES Message. The created mountpoint can be seen by logging into the ODLUX GUI. 
  8. Currently the created mountpoint uses SSH for communicating with the PNF. A TLS based mountpoint implementation is in the works.


pnfRegistration VES Message flow 

Message flow (for registering a mountpoint with TLS protocol)


SDN-R NetConf TLS Cetificate Handling Certificate Authority Certificate Authority Device Device VES Collector VES Collector Mountpoint register service Mountpoint register service SDN-Controller SDN-Controller 1create trusted certificatetrusted-ca 2generatecontroller-private-key 3certificate signign request 4returncontroller-certreturntrusted-ca netconf-keystore 5add-keystore-entry(controller-private-key) 6add-private-key(controller-private-key, controller-cert) 7add-trusted-certificate(trusted-ca) 8generatedevice-private-key 9certificate signing request 10returndevice-certreturntrusted-ca netconf server 11add-private-key(device-private-key, device-cert) 12add-trusted-certificate(trusted-ca) 13VES messagepnfRegistration 14send message via DMaaP 15mount device with protocolTLS 16initiate TLS connection 17TLS connection establishedLicenseApache 2.0SDN-R NetConf TLS Cetificate HandlingThanks to plantUml!2019-10-04 | onap.org

  • No labels

8 Comments

  1. Herbert Eiselt

    Micha+Herbert's questions/discussion: 

    • Where the decision is taken if a device is allowed to be mounted by SDN-Controller? A) After step 7 by CA?? or  B) with Step 14 by SDN-Controller using a RequiredDeviceInformation?
    • Step 10 implies that Mountpoint register service own a mapping table of DeviceIP to DeviceCert. This information is available in the device and in CA. It should/could be requested from CA after Step 12 replacing Step 13?
    • Step 14: Is device-cert also used for authentification on SDN-Controller/RESTCONF by mountpoint register service?
    • Step 8: Why the device gets the device-cert. Is this required for TLS connection setup?

    1. Alex Stancu

      This is my opinion:

      • The diagram was simplified when involving the CA in doing step 10. Actually, this is a manual step that can be done by any operating user.. I think that this decision should be taken by some user (since anyway it is a manual process), after step 7.
      • Indeed, this information could be requested from the user after Step 12.
      • device-cert is needed in the mount operation associated to that particular device. The authentication of the mountpoint register service on the SDN-Controller is unrelated, it is done separately (e.g. via user/pass).
      • The device needs a certificate (device-cert) in order to be able to talk via TLS. The connection in TLS is established via certificates, not via public keys.

    2. Martin Skorupski

      On a high-level I like to refer to: PNF PLUG and PLAY in R6 Frankfurt

      1) The decision is made by SO and A&AI and by the existence of a device-cert.

      2) "somehow" the CA must be known by ODL. in Dublin the device-cert was manually added to ODL. The workflow above would still use this approach. The device-simulator has an API for this step, but we doubt that all devices will implement something like this - the CA propagation via pnfRegistration VES message is not modeled (yet). 

      @Benjamin Cheung: Is there a way to request the device-cert from the pnf or will the pnfRegirstion VES message be enhanced to automate this step?

      3) yes

      4) that is the way how ODL works. 


  2. Ravi Chandra Pendurty

    Regarding step 10, why is it not present in the original sequence diagram though both implementations i.e., the current mountpoint registrar implementation and the erst while TLS implementation in June create a mountpoint in the SDN Controller ?

  3. Herbert Eiselt

    To provide encrypted information, in registration message the additonalFields should be used:

    https://gerrit.onap.org/r/gitweb?p=dcaegen2/collectors/ves.git;a=blob;f=etc/CommonEventFormat_30.0.1.json;h=49c7f9320b7aad6dee22ccb4fc401c81521142bd;hb=refs/heads/master

    2219 },
    2220 "pnfRegistrationFields": {
    2221 "description": "hardware device registration fields",
    2222 "type": "object",
    2223 "properties": {
    2224 "additionalFields": {
    2225 "$ref": "#/definitions/hashMap"
    2226 },

  4. Alex Stancu

    Steps done by NTS when configuring a TLS connection:

    • Mount operation from the NTS Manager to ODL:

    using this RESTCONF API:

    PUT http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device

    and this payload:

    <node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
    <node-id>new-netconf-device</node-id>
    <host xmlns="urn:opendaylight:netconf-node-topology">127.0.0.1</host>
    <port xmlns="urn:opendaylight:netconf-node-topology">17830</port>

    <key-based xmlns="urn:opendaylight:netconf-node-topology">

    <username xmlns="urn:opendaylight:netconf-node-topology">admin</username>

    <!-- this parameter is optional, we can use it to specify which private key ODL uses to connect to this devices, if not I think ODL will try to connect with all its keys --><key-id>keystore_key_id</key-id>

    </key-based>

    <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
    <protocol xmlns="urn:opendaylight:netconf-node-topology">
    <name>TLS</name>
    </protocol>

    <!-- non-mandatory fields with default values, you can safely remove these if you do not wish to override any of these values-->
    <reconnect-on-changed-schema xmlns="urn:opendaylight:netconf-node-topology">false</reconnect-on-changed-schema>
    <connection-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">20000</connection-timeout-millis>
    <max-connection-attempts xmlns="urn:opendaylight:netconf-node-topology">0</max-connection-attempts>
    <between-attempts-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">2000</between-attempts-timeout-millis>
    <sleep-factor xmlns="urn:opendaylight:netconf-node-topology">1.5</sleep-factor>
    <!-- keepalive-delay set to 0 turns off keepalives-->
    <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">120</keepalive-delay>
    </node>

    • Create new netconf-keystore datastore entry in ODL:

    API:

    http://localhost:8181/restconf/operations/netconf-keystore:add-keystore-entry

    Payload:

    <input xmlns="urn:opendaylight:netconf:keystore">

    <key-credential>

    <key-id>whatever_key_id</key-id>

    <private-key>MIIEpAIBAAKCAQEAueCQaNQWoNmFK6LKu1p8U8ZWdWg/PvDdLsJyzfzl/Qw4UA68 SfFNaY06zZl8QB9W02nr5kWeeMY0VA3adrPgOlvfx3oWlFbkETnMaN4OT3WTQ0Wt 6jAWZDzVfopwpJPAzRPxACDftIqFGagYcF32hZlVNqqnVdbXh0S0EViweqp/dbG4 VDUHSNVbglc+u4UbEzNIFXMdEFsJZpkynOmSiTsIATqIhb+2srkVgLwhfkC2qkuH QwAHdubuB07ObM2z01UhyEdDvEYGHwtYAGDBL2TAcsI0oGeVkRyuOkV0QY0UN7UE FI1yTYw+xZ42HgFx3uGwApCImxhbj69GBYWFqwIDAQABAoIBAQCZN9kR8DGu6V7y t0Ax68asL8O5B/OKaHWKQ9LqpVrXmikZJOxkbzoGldow/CIFoU+q+Zbwu9aDa65a 0wiP7Hoa4Py3q5XNNUrOQDyU/OYC7cI0I83WS0lJ2zOJGYj8wKae5Z81IeQFKGHK 4lsy1OGPAvPRGh7RjUUgRavA2MCwe07rWRuDb/OJFe4Oh56UMEjwMiNBtMNtncog j1vr/qgRJdf9tf0zlJmLvUJ9+HSFFV9I/97LJyFhb95gAfHkjdVroLVgT3Cho+4P WtZaKCIGD0OwfOG2nLV4leXvRUk62/LMlB8NI9+JF7Xm+HCKbaWHNWC7mvWSLV58 Zl4AbUWRAoGBANyJ6SFHFRHSPDY026SsdMzXR0eUxBAK7G70oSBKKhY+O1j0ocLE jI2krHJBhHbLlnvJVyMUaCUOTS5m0uDw9hgSsAqeSL3hL38kxVZw+KNG9Ouno1Fl KnE/xXHlPQyeGs/P8nAMzHZxQtEsQdQayJEhK2XXHTsy7Q3MxDisfVJ1AoGBANfD 34gB+OMx6pwj7zk3qWbYXSX8xjCZMR0ciko+h4xeMP2N8B0oyoqC+v1ABMAtJ3wG sGZd0hV9gwM7OUM3SEwkn6oeg1GemWLcn4rlSmTnZc4aeVwrEWlnSNFX3s4g9l4u k8Ugu4MVJYqH8HuDQ5Ggl6/QAwPzMSEdCW0O+jOfAoGAIBRbegC5+t6m7Yegz4Ja dxV1g98K6f58x+MDsQu4tYWV4mmrQgaPH2dtwizvlMwmdpkh+LNWNtWuumowkJHc akIFo3XExQIFg6wYnGtQb4e5xrGa2xMpKlIJaXjb+YLiCYqJDG2ALFZrTrvuU2kV 9a5qfqTc1qigvNolTM0iaaUCgYApmrZWhnLUdEKV2wP813PNxfioI4afxlpHD8LG sCn48gymR6E+Lihn7vuwq5B+8fYEH1ISWxLwW+RQUjIneNhy/jjfV8TgjyFqg7or 0Sy4KjpiNI6kLBXOakELRNNMkeSPopGR2E7v5rr3bGD9oAD+aqX1G7oJH/KgPPYd Vl7+ZwKBgQDcHyWYrimjyUgKaQD2GmoO9wdcJYQ59ke9K+OuGlp4ti5arsi7N1tP B4f09aeELM2ASIuk8Q/Mx0jQFnm8lzRFXdewgvdPoZW/7VufM9O7dGPOc41cm2Dh yrTcXx/VmUBb+/fnXVEgCv7gylp/wtdTGHQBQJHR81jFBz0lnLj+gg==</private-key> <passphrase></passphrase>

    </key-credential>

    </input>

    • Create a new private-key entry in the netconf-keystore datastore in ODL:

    API:

    http://localhost:8181/restconf/operations/netconf-keystore:add-private-key

    Payload:

    <input xmlns="urn:opendaylight:netconf:keystore">

    <private-key>

    <name>my_private_key_to_cert_association</name> <data>MIIEpAIBAAKCAQEAueCQaNQWoNmFK6LKu1p8U8ZWdWg/PvDdLsJyzfzl/Qw4UA68SfFNaY06zZl8QB9W02nr5kWeeMY0VA3adrPgOlvfx3oWlFbkETnMaN4OT3WTQ0Wt6jAWZDzVfopwpJPAzRPxACDftIqFGagYcF32hZlVNqqnVdbXh0S0EViweqp/dbG4VDUHSNVbglc+u4UbEzNIFXMdEFsJZpkynOmSiTsIATqIhb+2srkVgLwhfkC2qkuHQwAHdubuB07ObM2z01UhyEdDvEYGHwtYAGDBL2TAcsI0oGeVkRyuOkV0QY0UN7UEFI1yTYw+xZ42HgFx3uGwApCImxhbj69GBYWFqwIDAQABAoIBAQCZN9kR8DGu6V7yt0Ax68asL8O5B/OKaHWKQ9LqpVrXmikZJOxkbzoGldow/CIFoU+q+Zbwu9aDa65a0wiP7Hoa4Py3q5XNNUrOQDyU/OYC7cI0I83WS0lJ2zOJGYj8wKae5Z81IeQFKGHK4lsy1OGPAvPRGh7RjUUgRavA2MCwe07rWRuDb/OJFe4Oh56UMEjwMiNBtMNtncogj1vr/qgRJdf9tf0zlJmLvUJ9+HSFFV9I/97LJyFhb95gAfHkjdVroLVgT3Cho+4PWtZaKCIGD0OwfOG2nLV4leXvRUk62/LMlB8NI9+JF7Xm+HCKbaWHNWC7mvWSLV58Zl4AbUWRAoGBANyJ6SFHFRHSPDY026SsdMzXR0eUxBAK7G70oSBKKhY+O1j0ocLEjI2krHJBhHbLlnvJVyMUaCUOTS5m0uDw9hgSsAqeSL3hL38kxVZw+KNG9Ouno1FlKnE/xXHlPQyeGs/P8nAMzHZxQtEsQdQayJEhK2XXHTsy7Q3MxDisfVJ1AoGBANfD34gB+OMx6pwj7zk3qWbYXSX8xjCZMR0ciko+h4xeMP2N8B0oyoqC+v1ABMAtJ3wGsGZd0hV9gwM7OUM3SEwkn6oeg1GemWLcn4rlSmTnZc4aeVwrEWlnSNFX3s4g9l4uk8Ugu4MVJYqH8HuDQ5Ggl6/QAwPzMSEdCW0O+jOfAoGAIBRbegC5+t6m7Yegz4JadxV1g98K6f58x+MDsQu4tYWV4mmrQgaPH2dtwizvlMwmdpkh+LNWNtWuumowkJHcakIFo3XExQIFg6wYnGtQb4e5xrGa2xMpKlIJaXjb+YLiCYqJDG2ALFZrTrvuU2kV9a5qfqTc1qigvNolTM0iaaUCgYApmrZWhnLUdEKV2wP813PNxfioI4afxlpHD8LGsCn48gymR6E+Lihn7vuwq5B+8fYEH1ISWxLwW+RQUjIneNhy/jjfV8TgjyFqg7or0Sy4KjpiNI6kLBXOakELRNNMkeSPopGR2E7v5rr3bGD9oAD+aqX1G7oJH/KgPPYdVl7+ZwKBgQDcHyWYrimjyUgKaQD2GmoO9wdcJYQ59ke9K+OuGlp4ti5arsi7N1tPB4f09aeELM2ASIuk8Q/Mx0jQFnm8lzRFXdewgvdPoZW/7VufM9O7dGPOc41cm2DhyrTcXx/VmUBb+/fnXVEgCv7gylp/wtdTGHQBQJHR81jFBz0lnLj+gg==</data>

    <certificate-chain>MIIECTCCAvGgAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCQ1oxFjAUBgNVBAgMDVNvdXRoIE1vcmF2aWExDTALBgNVBAcMBEJybm8xDzANBgNVBAoMBkNFU05FVDEMMAoGA1UECwwDVE1DMRMwEQYDVQQDDApleGFtcGxlIENBMSIwIAYJKoZIhvcNAQkBFhNleGFtcGxlY2FAbG9jYWxob3N0MB4XDTE1MDczMDA3MjcxOFoXDTM1MDcyNTA3MjcxOFowgYUxCzAJBgNVBAYTAkNaMRYwFAYDVQQIDA1Tb3V0aCBNb3JhdmlhMQ8wDQYDVQQKDAZDRVNORVQxDDAKBgNVBAsMA1RNQzEXMBUGA1UEAwwOZXhhbXBsZSBjbGllbnQxJjAkBgkqhkiG9w0BCQEWF2V4YW1wbGVjbGllbnRAbG9jYWxob3N0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAueCQaNQWoNmFK6LKu1p8U8ZWdWg/PvDdLsJyzfzl/Qw4UA68SfFNaY06zZl8QB9W02nr5kWeeMY0VA3adrPgOlvfx3oWlFbkETnMaN4OT3WTQ0Wt6jAWZDzVfopwpJPAzRPxACDftIqFGagYcF32hZlVNqqnVdbXh0S0EViweqp/dbG4VDUHSNVbglc+u4UbEzNIFXMdEFsJZpkynOmSiTsIATqIhb+2srkVgLwhfkC2qkuHQwAHdubuB07ObM2z01UhyEdDvEYGHwtYAGDBL2TAcsI0oGeVkRyuOkV0QY0UN7UEFI1yTYw+xZ42HgFx3uGwApCImxhbj69GBYWFqwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUXGpLeLnh2cSDARAVA7KrBxGYpo8wHwYDVR0jBBgwFoAUc1YQIqjZsHVwlea0AB4N+ilNI2gwDQYJKoZIhvcNAQELBQADggEBAJPV3RTXFRtNyOU4rjPpYeBAIAFp2aqGc4t2J1c7oPp/1n+lZvjnwtlJpZHxMM783e2ryDQ6dkvXDf8kpwKlg3U3mkJ3xKkDdWrM4QwghXdCN519aa9qmu0zdFL+jUAaWlQ5tsceOrvbusCcbMqiFGk/QfpHqPv52SVWbYyUx7IX7DE+UjgsLHycfV/tlcx4ZE6soTzl9VdgSL/zmzG3rjsr58J80rXckLgBhvijgBlIAJvWfC7D0vaouvBInSFXymdPVoUDZ30cdGLf+hI/i/TfsEMOinLrXVdkSGNo6FXAHKSvXeB9oFKSzhQ7OPyRyqvEPycUSw/qD6FVr80oDDc=</certificate-chain>

    </private-key>

    </input>

    • Add a new trusted certificate into ODL:

    API:

    http://172.17.0.1:8181/restconf/operations/netconf-keystore:add-trusted-certificate

    Payload:

    <input xmlns="urn:opendaylight:netconf:keystore">

    <trusted-certificate>

    <name>some_trusted_cert</name> <certificate>MIID7TCCAtWgAwIBAgIJAMtE1NGAR5KoMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJDWjEWMBQGA1UECAwNU291dGggTW9yYXZpYTENMAsGA1UEBwwEQnJubzEPMA0GA1UECgwGQ0VTTkVUMQwwCgYDVQQLDANUTUMxEzARBgNVBAMMCmV4YW1wbGUgQ0ExIjAgBgkqhkiG9w0BCQEWE2V4YW1wbGVjYUBsb2NhbGhvc3QwHhcNMTQwNzI0MTQxOTAyWhcNMjQwNzIxMTQxOTAyWjCBjDELMAkGA1UEBhMCQ1oxFjAUBgNVBAgMDVNvdXRoIE1vcmF2aWExDTALBgNVBAcMBEJybm8xDzANBgNVBAoMBkNFU05FVDEMMAoGA1UECwwDVE1DMRMwEQYDVQQDDApleGFtcGxlIENBMSIwIAYJKoZIhvcNAQkBFhNleGFtcGxlY2FAbG9jYWxob3N0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArD3TDHPAMT2Z84orK4lMlarbgooIUCcRZyLe+QM+8KY8Hn+mGaxPEOTSL3ywszqefB/Utm2hPKLHX684iRC14ID9WDGHxPjvoPArhgFhfV+qnPfxKTgxZC12uOj4u1V9y+SkTCocFbRfXVBGpojrBuDHXkDMDEWNvr8/52YCv7bGaiBwUHolcLCUbmtKILCG0RNJyTaJpXQdAeq5Z1SJotpbfYFFtAXB32hVoLug1dzl2tjG9sb1wq3QaDExcbC5w6P65qOkNoyym9ne6QlQagCqVDyFn3vcqkRaTjvZmxauCeUxXgJoXkyWcm0lM1KMHdoTArmchw2Dz0yHHSyDAQIDAQABo1AwTjAdBgNVHQ4EFgQUc1YQIqjZsHVwlea0AB4N+ilNI2gwHwYDVR0jBBgwFoAUc1YQIqjZsHVwlea0AB4N+ilNI2gwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEAI/1KH60qnw9Xs2RGfi0/IKf5EynXt4bQX8EIyVKwSkYKe04zZxYfLIl/Q2HOPYoFmm3daj5ddr0ZS1i4p4fTUhstjsYWvXs3W/HhVmFUslakkn3PrswhP77fCk6eEJLxdfyJ1C7Uudq2m1isZbKih+XF0mG1LxJaDMocSz4eAya7M5brwjy8DoOmA1TnLQFCVcpn+sCr7VC4wE/JqxyVhBCk/MuGqqM3B1j90bGFZ112ZOecyE0EDSr6IbiRBtmeNbEwOFjKXhNLYdxpBZ9D8A/368OckZkCrVLGuJNxK9UwCVTe8IhotHUqU9EqFDmxdV8oIdU/OzUwwNPA/Bd/9g==</certificate>

    </trusted-certificate>

    </input>

    With blue we have the private key of ODL.

    With green we have the certificate associated with the private key of ODL, signed by a certain CA.

    With red we have the certificate of the CA, which we list as a trusted CA, meaning that we can talk via TLS to any other device that has its certificate signed by the same CA.

  5. Ринат Бедретдинов

    Hello!

    I am trying to use this mounting feature. But after setting param dmaapEnabled=true i see errors in karaf.log:

    2023-06-09T08:25:51,200 | INFO  | Thread-61        | MountpointRegistrarImpl          | 239 - ures.sdnr.wt.sdnr-wt-mountpoint-registrar-provider - 1.4.1 |  -   | Service configuration state changed. Enabled: true
    2023-06-09T08:25:51,201 | INFO  | Thread-61        | MountpointRegistrarImpl          | 239 - ures.sdnr.wt.sdnr-wt-mountpoint-registrar-provider - 1.4.1 |  -   | DMaaP is enabled, starting consumer(s)
    2023-06-09T08:25:51,204 | INFO  | Thread-61        | DMaaPVESMsgConsumerMain          | 239 - ures.sdnr.wt.sdnr-wt-mountpoint-registrar-provider - 1.4.1 |  -   | Started consumer thread (DMaaPFaultVESMsgConsumer : {jersey.config.client.p
    2023-06-09T08:25:51,204 | INFO  | Thread-61        | DMaaPCMVESMsgConsumer            | 239 - ures.sdnr.wt.sdnr-wt-mountpoint-registrar-provider - 1.4.1 |  -   | DMaaPCMVESMsgConsumer started successfully
    2023-06-09T08:25:51,206 | INFO  | Thread-61        | DMaaPVESMsgConsumerMain          | 239 - ures.sdnr.wt.sdnr-wt-mountpoint-registrar-provider - 1.4.1 |  -   | Started consumer thread (DMaaPCMVESMsgConsumer : {jersey.config.client.prox
    2023-06-09T08:25:51,208 | INFO  | Thread-61        | DMaaPVESMsgConsumerMain          | 239 - ures.sdnr.wt.sdnr-wt-mountpoint-registrar-provider - 1.4.1 |  -   | Started consumer thread (DMaaPPNFRegVESMsgConsumer : {jersey.config.client.
    2023-06-09T08:25:51,213 | WARN  | Thread-873       | PropertiesHelper                 | 195 - org.glassfish.jersey.core.jersey-common - 2.27.0 |  -   | There is no way how to transform value "" [java.lang.String] to type [java.lang.Integ
    2023-06-09T08:25:51,213 | ERROR | Thread-873       | MRConsumerImpl                   | 499 - apclient_dmaapClient_1.1.13_dmaapClient-1.1.13.jar - 0.0.0 |  -   | exception:
    javax.ws.rs.ProcessingException: null
            at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:287) ~[bundleFile:?]
            at org.glassfish.jersey.client.JerseyInvocation.lambda$invoke$0(JerseyInvocation.java:753) ~[bundleFile:?]
            at org.glassfish.jersey.internal.Errors.process(Errors.java:316) ~[bundleFile:?]
            at org.glassfish.jersey.internal.Errors.process(Errors.java:298) ~[bundleFile:?]
            at org.glassfish.jersey.internal.Errors.process(Errors.java:229) ~[bundleFile:?]
            at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:414) ~[bundleFile:?]
            at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:752) ~[bundleFile:?]
            at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:419) ~[bundleFile:?]
            at org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:319) ~[bundleFile:?]
            at org.onap.dmaap.mr.client.impl.DmaapClientUtil.getResponsewtNoAuth(DmaapClientUtil.java:124) ~[bundleFile:?]
            at org.onap.dmaap.mr.client.impl.MRBaseClient.getNoAuthResponse(MRBaseClient.java:321) ~[bundleFile:?]
            at org.onap.dmaap.mr.client.impl.MRConsumerImpl.fetchWithReturnConsumerResponse(MRConsumerImpl.java:320) [bundleFile:?]
            at org.onap.ccsdk.features.sdnr.wt.mountpointregistrar.impl.DMaaPVESMsgConsumerImpl.run(DMaaPVESMsgConsumerImpl.java:64) [bundleFile:?]
            at java.lang.Thread.run(Unknown Source) [?:?]
    Caused by: java.lang.NullPointerException
            at org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:347) ~[bundleFile:?]
            at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:282) ~[bundleFile:?]
            at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:278) ~[bundleFile:?]
            ... 13 more
    2023-06-09T08:25:51,214 | ERROR | Thread-873       | DMaaPVESMsgConsumerImpl          | 239 - ures.sdnr.wt.sdnr-wt-mountpoint-registrar-provider - 1.4.1 |  -   | Caught exception reading from DMaaP VES Message Topic
    java.lang.NullPointerException: null
            at org.onap.ccsdk.features.sdnr.wt.mountpointregistrar.impl.DMaaPVESMsgConsumerImpl.run(DMaaPVESMsgConsumerImpl.java:77) [bundleFile:?]
            at java.lang.Thread.run(Unknown Source) [?:?]
    2023-06-09T08:25:51,216 | WARN  | Thread-875       | PropertiesHelper                 | 195 - org.glassfish.jersey.core.jersey-common - 2.27.0 |  -   | There is no way how to transform value "" [java.lang.String] to type [java.lang.Integ
    2023-06-09T08:25:51,216 | ERROR | Thread-875       | MRConsumerImpl                   | 499 - apclient_dmaapClient_1.1.13_dmaapClient-1.1.13.jar - 0.0.0 |  -   | exception:
    javax.ws.rs.ProcessingException: null
            at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:287) ~[bundleFile:?]
            at org.glassfish.jersey.client.JerseyInvocation.lambda$invoke$0(JerseyInvocation.java:753) ~[bundleFile:?]
            at org.glassfish.jersey.internal.Errors.process(Errors.java:316) ~[bundleFile:?]
            at org.glassfish.jersey.internal.Errors.process(Errors.java:298) ~[bundleFile:?]
            at org.glassfish.jersey.internal.Errors.process(Errors.java:229) ~[bundleFile:?]
            at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:414) ~[bundleFile:?]
            at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:752) ~[bundleFile:?]
            at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:419) ~[bundleFile:?]
            at org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:319) ~[bundleFile:?]
            at org.onap.dmaap.mr.client.impl.DmaapClientUtil.getResponsewtNoAuth(DmaapClientUtil.java:124) ~[bundleFile:?]
            at org.onap.dmaap.mr.client.impl.MRBaseClient.getNoAuthResponse(MRBaseClient.java:321) ~[bundleFile:?]
            at org.onap.dmaap.mr.client.impl.MRConsumerImpl.fetchWithReturnConsumerResponse(MRConsumerImpl.java:320) [bundleFile:?]
            at org.onap.ccsdk.features.sdnr.wt.mountpointregistrar.impl.DMaaPVESMsgConsumerImpl.run(DMaaPVESMsgConsumerImpl.java:64) [bundleFile:?]
            at java.lang.Thread.run(Unknown Source) [?:?]
    Caused by: java.lang.NullPointerException
            at org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:347) ~[bundleFile:?]
            at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:282) ~[bundleFile:?]


    Also could anybody help me to understand workflow to config provisioning with SDNC? 

    1. Ravi Pendurty

      Looks like there is something missing in your mountpoint-registrar.properties file. Also, is DMaaP MR and VES Collector setup in your environment? Can you share your mountpoint-registrar.properties file?