Context

Our goal is to reach VNF from APP-C through Ansible, but we're facing couple of issues. In reach I mean to be able to execute arbitrary playbook in Ansible server instance from APP-C. We have Ansible server installed and configured which is accessible on this endpoint: http://10.74.1.84:8000/Dispatch, we have verified following request works (playbook gets actually executed):

curl -X POST \
  http://10.74.1.84:8000/Dispatch \
  -H 'Content-Type: application/json' \
  -d '{"Id": "12", "PlaybookName": "ansible_sleep", "NodeList": ["host"], "Timeout": "60", "EnvParameters": {"Sleep": "1"}}'

We performed demo VNF onboarding and instantiation with the help of materials available here: Running the ONAP Demos. Note we don't care about closed-loop yet, our sole goal is to interact with virtual network functions through APP-C.

Problem #1

For simplicity we tried to execute Restart action first, we believe it does not require any interaction with Ansible server, rather it uses OpenStack directly to restart whole VM.

Restart

curl -X POST \
  http://10.74.1.74:30230/restconf/operations/appc-provider-lcm:restart \
  -H 'Authorization: Basic YWRtaW46S3A4Yko0U1hzek0wV1hsaGFrM2VIbGNzZTJnQXc4NHZhb0dHbUp2VXkyVQ==' \
  -H 'Content-Type: application/json' \
  -H 'X-Transaction-id: 1521720096' \
  -d '{
"input": {
            "common-header": {"timestamp": "2018-03-22T12:00:00.00Z",
                                    "api-ver": "2.00",
                                    "originator-id": "Test-Originator",
                                    "request-id": "1",
                                    "flags": {
                                               "mode": "NORMAL",
                                               "force": "FALSE",
                                               "ttl": "2000"
                                             }
                             },
            "action": "Restart",
            "action-identifiers": {
                                    "vnf-id": "9feb6ea5-05ac-435a-8760-575befa9a5c9",
                                    "vserver-id": "2f1b24ee-6382-4e2c-b405-e8fbaa3a2d64"
                                  },
            "payload": "{\"vm-id\": \"2f1b24ee-6382-4e2c-b405-e8fbaa3a2d64\"}"
         }
}'

We got ACCEPTED as a response, however nothing happened. Here are the debug logs from APP-C ODL console: https://pastebin.com/raw/5W6quZSt.

We also see similar messages in logs:

2018-03-22 11:59:18,134 | ERROR | Appc-Listener-2  | HttpDmaapConsumerImpl            | 365 - appc-dmaap-adapter-bundle - 1.2.0 | Did not get 200 from DMaaP. Got 404 - {"mrstatus":3001,"helpURL":"https://wiki.web.att.com/display/DMAAP/DMaaP+Home","message":"No such topic exists.-[APPC-LCM-READ]","status":404}

Q1: We are expecting whole VM to be restarted, is our assumption correct? If yes what could be the cause of failure above?

Then we tried to check the status by ActionStatus action which is new in Beijing (http://onap.readthedocs.io/en/latest/submodules/appc.git/docs/APPC%20LCM%20API%20Guide/APPC%20LCM%20API%20Guide.html#actionstatus):

ActionStatus

curl -X POST \
  http://10.74.1.74:30230/restconf/operations/appc-provider-lcm:action-status \
  -H 'Authorization: Basic YWRtaW46S3A4Yko0U1hzek0wV1hsaGFrM2VIbGNzZTJnQXc4NHZhb0dHbUp2VXkyVQ==' \
  -H 'Content-Type: application/json' \
  -H 'X-Transaction-id: 1521730814' \
  -d '{
"input": {
            "common-header": {"timestamp": "2018-03-21T10:49:00.00Z",
                                    "api-ver": "2.00",
                                    "originator-id": "Test-Originator",
                                    "request-id": "2",
                                    "flags": {
                                               "mode": "NORMAL",
                                               "force": "FALSE",
                                               "ttl": "2000"
                                             }
                             },
            "action": "ActionStatus",
            "action-identifiers": {
                                    "vnf-id": "9feb6ea5-05ac-435a-8760-575befa9a5c9",
                                    "vserver-id": "2f1b24ee-6382-4e2c-b405-e8fbaa3a2d64"
                                  },
            "payload": "{\"request-id\": \"1\"}"
         }
}'

but surprisingly request was rejected with following response:

{
    "errors": {
        "error": [
            {
                "error-type": "protocol",
                "error-tag": "invalid-value",
                "error-message": "URI has bad format. Possible reasons:\n 1. \"appc-provider-lcm:action-status\" was not found in parent data node.\n 2. \"appc-provider-lcm:action-status\" is behind mount point. Then it should be in format \"/yang-ext:mount/appc-provider-lcm:action-status\"."
            }
        ]
    }
}

Now we're starting to doubt whether we really have Beijing, because I was told elsewhere that our installation looks like an Amsterdam release.

Q2: What is the definition of Beijing release? In the OOM project there are 2 branches: amsterdam and master. We assumed running OOM scripts from master branch would install Beijing. Is it correct?

Problem #2

Next we attempted to bypass LCM API and hit directly SLI, we executed following Ansible DG:

curl -X POST http://10.74.1.74:30230/restconf/operations/SLI-API:execute-graph -H 'Authorization: Basic YWRtaW46S3A4Yko0U1hzek0wV1hsaGFrM2VIbGNzZTJnQXc4NHZhb0dHbUp2VXkyVQ==' -H 'Cache-Control: no-cache' -H 'Content-Type: application/json' -d '{"input":{"module-name":"APPC","rpc-name":"ansible-adapter-1.0","mode":"sync","sli-parameter":[{"parameter-name":"User","string-value":""},{"parameter-name":"Password","string-value":""},{"parameter-name":"AgentUrl","string-value":"http://10.74.1.84:8000/Dispatch"},{"parameter-name":"PlaybookName","string-value":"ansible_sleep"},{"parameter-name":"Action","string-value":"None"},{"parameter-name":"EnvParameters","string-value":""},{"parameter-name":"FileParameters","string-value":""},{"parameter-name":"Timeout","string-value":""},{"parameter-name":"NodeList","string-value":""}]}}'

We were expecting playbook to be executed, but it didn't. Seems there is some error in the logs: https://pastebin.com/raw/hrQihnEc

Q3: Is our expectation correct? What could error from the logs mean? From the package name org.openecomp.appc.adapter in stacktrace I can presume Ansible adapter which is deployed currently is little bit old, in the current source code package is renamed to org.onap.appc.adapter, again this looks like an amsterdam realease, doesn't it?

Bonus questions

How does APP-C determine which adapter to use: Ansible, Chef or NETCONF directly?
We assume Ansible server should be installed only once manually and it's not the part of the ONAP automation, is this correct?
Does vFW/vSink demo VNF support NETCONF interface?

Thanks!

Beka

Space shortcuts

APP-C and bonus questions

Context

Problem #1

Problem #2

Bonus questions

2 answers