Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
  1. Ubuntu 16.04
  2. apt-get install  kea-dhcp4-server
  3. install library  : kea-sdnc-notify.so  (/usr/local/lib)
    1. this library is built from source (hacked up copy of kea-pxe-replace4-mod)
    2. creates the hook which listens on pkt4_send
    3. sends an HTTP POST via libcurl if message is DHCPACK (that is response to client after Discover/Offer/Request)
    4. POST has macaddr, msg_name,  yiaddr (yiaddr is the one we want in SDNC)
    5. No response required since we are not re-writing the packet

 

  1. install conf files:
    1. /etc/kea/kea-dhcp4.conf

                                                    i.     This file sets ups the giaddr and ip blocks to be served

                                                   ii.     In the demo its 192.0.2.0/24

    1. /etc/kea/kea-sdnc-notify.conf

                                                    i.     This file sets the desintation url

                                                   ii.     For testing “http://localhost/sdnc.php?macaddr=”

                                                  iii.     For ONAP it would be a DMaaP TOPIC

  1. Start kea-dhcp4-server
  2. Logs in /var/log/kea-dhcp4.log

View file
nameonap-archiving-and-restore.mp4

Kang,

 

I don’t know if there are instructions about this, so I just send you a few notes. It works very similarly to Heat. You need to change /etc/hosts as before. See below:

 

10.12.6.48 portal.api.simpledemo.onap.org

10.12.6.48 vid.api.simpledemo.onap.org

10.12.6.48 sdc.api.fe.simpledemo.onap.org

10.12.6.48 portal-sdk.simpledemo.onap.org

10.12.6.48 policy.api.simpledemo.onap.org

10.12.6.48 aai.api.sparky.simpledemo.onap.org

10.12.6.48 cli.api.simpledemo.onap.org

10.12.6.48 msb.api.discovery.simpledemo.onap.org

 

Because K8S containers have node ports that are visible across the entire cluster, in theory you can pick the IP address of any K8S node for your /etc/hosts. In practice, to make portal work as Heat, you need to use the IP of the portal-app service. You can have the same IP for all the URLs above because of the node ports that I mentioned above. To get the portal-app service IP, run:

 

kubectl get services -n onap | grep portal-app

 

It will return the private IP of the K8S VM, then you need to go to the OpenStack GUI to see what is the public IP associated with that private IP. As an example, in SB04, the portal-app service is in K8S VM with private IP 10.0.0.15, which corresponds to public IP 10.12.6.48. After that, you can use the Portal (with SDC, Policy, etc) as you would do with Heat.

 

For accessing other services via browser (such as SDNC or APPC), you can use any K8S IP address (not necessarily the Portal one) and then use the node port associated with the service that you want. You can discover all the services by running:

 

kubectl get services -n onap

 

The approach I use is to see the port that I use in Heat to discover the node port that I need to use for K8S. For example, for registering and accessing the SDNC portal, I look for the service, and then the port:

 

sdnc-portal                NodePort       10.43.165.179   <none>                                 8843:30201/TCP

 

The yellow part means that the port 8843 (which you would use in Heat) is associated with node port 30201. So, something like http://10.12.6.48:30201/signup works.

 

It’s worth mentioning that the same approach must be used for setting the IP and port of the VES collector in the VNF preload to SDNC. Once again, pick an IP in the K8S cluster and look for the VES collector node port:

 

root@rancher:~/oom/kubernetes# kubectl get services -n onap | grep ves

dcae-ves-collector         ClusterIP      10.43.103.224   <none>                                 8080/TCP

xdcae-ves-collector        NodePort       10.43.214.191   <none>                                 8080:30235/TCP 

 

It returns 2 records, you need to pick the node port of xdcae-ves-collector, which is 30235. All the node ports are defined in the Helm charts, so they are not going to change (unless you do manually).

 

Hope this helps.

 

Marco

View file
namevcpe.zip
height250
View file
namesniro_request.json
height250
View file
namesniro_response.json
height250

View file
View file
namecsars_20180515.zip
height250
View file
namereq3.json
height250
namevgmux-aai-sample.jsonmso.config.20180810.tar
height250

----------------------------------------------------------

Yes. I’ve kept SNIRO Functionality, all that is needed is to add a user param of Name:”Homing_Solution” Value:“sniro” when instantiating the vCPE service. If ”Homing_Solution” user param is omitted, or has value:”oof” it will use new homing/OOF flow. To use OOF the userParam “Customer_Location” is also needed.

Here is an example rest request, with user param highlighted:



            "vnf-id": "12312f32-cdcb-47cc-a6e5-822b849cc58e",

            "vnf-name": "zRegionOne05",

            "vnf-type": "vcpesvc_rescust_0529a/vcpevsp_vgw_0412 0",

            "service-id": "{
   "requestDetails":
      {
         "modelInfo":
            {
               "modelType":"service",
               "modelInvariantUuid":"uuid-miu-svc-011-abcdef",
               "modelVersionId":"ASDC_TOSCA_UUID",
               "modelName":"SIModelName1",
               "modelVersion":"2"
            },
         "subscriberInfo":
            {
               "globalSubscriberId":"SDN-ETHERNET-INTERNET",
               "subscriberName":"Kaneohe"
            },
         "requestInfo":
            {
               "instanceName":"VCPE1",
               "source":"VID",
               "suppressRollback":"false",
               "productFamilyId":"a9a77d5a-123e-4ca2-9eb9-0b015d2ee0fb"
            },
         "cloudConfiguration":
            {
               "lcpCloudRegionId":"cloudowner_mdt1",
               "tenantId":"8b1df54faa3b49078e3416e21370a3ba"
            },
            "owningEntity": {
               "owningEntityId": "randomStrings",
               "owningEntityName": "randomStrings"
            },
            "requestParameters": {
                  "subscriptionServiceType":"123456789",
                  "aLaCarte":"false",
                  "userParams":
                     [
                        {
                           "name":"BRG_WAN_MAC_Address",
                           "value":"brgmac"
                        },
                        {
                           "name": "Customer_Location",
                           "value": {
                              "customerLatitude": "32.897480",
                              "customerLongitude": "-97.040443",
                              "customerName": "some_company"
                          }
                        },
                        {
                           "name":"Homing_Solution",
                           "value":"sniro"
                        }
                     ]
            }
      }
}

Cheers,

Marcus Williams

IRC @ mgkwill

Network Software Engineer

,


View file
nameservice-VcpesvcInfra0529a-csar.csar
height250


View file
nameservice-VcpesvcInfra0412a-csar.csar
height250
Intel Corp. – Network Platforms Group