APIC REST API produces inconsistent response

[toan.nguyen1]

Hi all, 

I'm using python to write REST API calls to the APIC, version 1.0(3f), and I get inconsistent results. API inspector shows the payload and I POST the same payload but the results are 50% successful. Here's an example of a JSON payload in configuring a SNMP Trap Destination:

payload = {"snmpGroup":{"attributes":{"dn":"uni/fabric/snmpgroup-test_Solarwind","name":"test_Solarwind","descr":"test_Solarwind_desc","rn":"snmpgroup-test_Solarwind","status":"created"},"children":[{"snmpTrapDest":{"attributes":{"dn":"uni/fabric/snmpgroup-test_Solarwind/trapdest-10.1.1.220-port-162","host":"10.1.1.220","secName":"public","rn":"trapdest-10.1.1.220-port-162","status":"created"},"children":[{"fileRsARemoteHostToEpg":{"attributes":{"tDn":"uni/tn-mgmt/mgmtp-default/oob-default","status":"created"},"children":[]}}]}}]}}

The results come back as:

[fail]

{'imdata': [{'error': {'attributes': {'code': '822', 'text': "naming property ('snmpTrapDest.host') is not set."}}}]}

[success]

{'imdata': []}

I'm basically POST'ing over and over until I get a successful response. In the payload, I've even removed the empty 'children' array in the end and the results are the same. 

Has anyone ran into this situation? Looks like I'm running into this problem only when I POST a json payload that has children arrays in it. 

Thank you.

[mtimm]

I can not recreate this with 1.0(3k).  I could downgrade one of my setup's to try and recreate it on 1.0(3f) in a few hours.  Honestly though, 1.0(3f) is not a version I would recommend running.  We are recommending all customers move to 1.0(4o) or 1.1(1o) or later at this point.  

If you want to try and look at some logs that may give a hint as to what happened, you can ssh in as admin and view the nginx access and error log at /var/log/dme/nginx, and APIC's own log for nginx at /var/log/dme/log/nginx.bin.log.  Viewing the nginx.bin.log may be more than most are willing to do, it's very verbose.

Mike

[toan.nguyen1]

Hi Mike, 

Thanks for the quick response. I looked at the error log and it just shows a 400 request. /var/log/dme/lolg/nginx.bin.log shows nothing revealing to me: 

2287||15-08-14 05:46:39.506+00:00||aaa||DBG4||co=doer:255:127:0xff00000000f56657:1||WebToken request user admin (local)||../common/src/rest/./Auth.cc||280
2287||15-08-14 05:46:39.506+00:00||exception_handling||ERROR||co=doer:255:127:0xff00000000f56657:1||FATAL[5|822]: ../common/src/framework/core/meta/RnComponentImp.h(156):process (null)[None] : naming property ('snmpTrapDest.host') is no t set.||../common/src/framework/./core/error/Report.cc||125
2287||15-08-14 05:46:39.506+00:00||nginx||DBG4||co=doer:255:127:0xff00000000f56657:1||outCode: 400||../common/src/rest/./Worker.cc||354
2287||15-08-14 05:46:39.506+00:00||nginx||DBG4||co=doer:255:127:0xff00000000f56657:1||No moModifier||../common/src/rest/./Request.cc||1500
2287||15-08-14 05:46:39.506+00:00||nginx||DBG4||co=doer:255:127:0xff00000000f56657:1||notifyEvent data ready 0x0||../common/src/rest/./Worker.cc||367
2256||15-08-14 05:46:39.506+00:00||nginx||DBG4||||Reply data (request 30847 size 111) {"imdata":[{"error":{"attributes":{"code":"822","text":"naming property ('snmpTrapDest.host') is not set."}}}]} Cookie: NONE||../common/src/rest/./Res t.cc||114

I would love our network team to use a higher version but that can't be done since this version is already being used in our prod environment. Were you able to reproduce this in your lab? Thank you very much for your help. 

Toan

[mtimm]

Hi Toan,

Sorry I could not successfully downgrade to that version and the other system that is running 1.0(3k) is being used for a recreate and I can not downgrade it either.

I ran this situation by a few others and the only suggestion we could come up with is to try without the Dn/Rn attributes.  I know the GUI uses them but what happens if you do not?  There was a bug fix for 1.0(3*) where duplicate submissions should return an error like:

snmp:TrapDest with same host and port already exists

Do you see that type of an error if you try to submit it twice in a row?  I'll keep trying to downgrade my setup.

Mike

[toan.nguyen1]

Hi Mike, 

Yes, I do see that 'exists' error if I continue to submit that same payload over and over. But sometimes it returns: 

{'imdata': [{'error': {'attributes': {'code': '822', 'text': "naming property ('snmpTrapDest.host') is not set."}}}]}

I have tried removing the Dn/Rn in the children arrays as well. My results are: 

• Removing just Rn's in children arrays - same results; 50% fail or success
• Removing just Dn's in children arrays - same results; 50% fail or success
• Removing both Dn's/Rn's in children arrays - 100% fail. The failure message is:

{'imdata': [{'error': {'attributes': {'code': '822', 'text': "naming property ('snmpTrapDest.port') is not set."}}}]}

Let me know what other ideas you might have and I'll try them. Thanks!

[mtimm]

Sorry I forgot to mention that the port number is what we call a naming property and all naming properties are required.  Naming properties are properties that make up part of the relative name (Rn) and they are required otherwise we don't know where to put the object in the MIT.  

Without the dn and rn you would need to explicitly include the property as part of the POST because the apic can not determine what the port should be without it being explicitly provided or in a dn or rn property.  So try:

{
    "snmpGroup": {
        "attributes": {
            "descr": "test_Solarwind_desc",
            "name": "test_Solarwind",
            "status": "created"
        },
        "children": [
            {
                "snmpTrapDest": {
                    "attributes": {
                        "host": "10.1.1.220",
                        "port": "162",
                        "secName": "public",
                        "status": "created"
                    },
                    "children": [
                        {
                            "fileRsARemoteHostToEpg": {
                                "attributes": {
                                    "status": "created",
                                    "tDn": "uni/tn-mgmt/mgmtp-default/oob-default"
                                },
                                "children": []
                            }
                        }
                    ]
                }
            }
        ]
    }
}

Mike

[toan.nguyen1]

Hey Mike, 

Thanks for clarifying that for me. I tried your json payload and same result. I even removed the empty 'children' array at the end and same result as well. My results are: 

{'imdata': [{'error': {'attributes': {'text': "Cannot create; object 'uni/fabric/snmpgroup-test_Solarwind' class 'snmpGroup' already exists.", 'code': '103'}}}]}

or 

{'imdata': [{'error': {'attributes': {'text': "naming property ('snmpTrapDest.host') is not set.", 'code': '822'}}}]}

[toan.nguyen1]

Hi Mike, 

I have upgrade my lab APIC to version 1.1(3f) and I'm still seeing inconsistent results with a different error. I thought this would be fixed going forward with 1.1. Perhaps I'm constructing the REST payload incorrectly? My payload is this:

{
    "snmpGroup": {
        "attributes": {
            "dn":"uni/fabric/snmpgroup-testSolarwind",
            "descr": "test_Solarwind_desc",
            "name": "testSolarwind",
            "rn": "snmpgroup-testSolarwind",
            "status": "created"
        },
        "children": [
            {
                "snmpTrapDest": {
                    "attributes": {
                        "host": "10.1.1.220",
                        "port": "162",
                        "secName": "public",
                        "status": "created"
                    },
                    "children": [
                        {
                            "fileRsARemoteHostToEpg": {
                                "attributes": {
                                    "status": "created",
                                    "tDn": "uni/tn-mgmt/mgmtp-default/oob-default"
                                },
                                "children": []
                            }
                        }
                    ]
                }
            }
        ]
    }
}

Half the time it works and the other half gives me this error:

ERROR: {'imdata': [{'error': {'attributes': {'text': "invalid data at line '1'. Attributes are missing, tag 'attributes' must be specified first, before any other tag", 'code': '400'}}}], 'totalCount': '1'}

Any ideas as to why this is still inconsistent with a recent version release? Thank you!

[mtimm · Accepted solution]

Since you are using python to POST this JSON, are you sorting the keys of the JSON?  If not you will need to.  The attributes *MUST* come before the children, this is contrary to what the JSON specification allows - objects do not have order in most JSON implementations.  The APIC JSON decoder is not standard JSON compliant in this regard.

Mike

[toan.nguyen1]

Mike, 

You are awesome!! That was the problem. I appreciate your quick response on this! 

[mtimm]

:) I wouldn't say it was necessarily quick - you asked your first question 4 months ago.  The truth is I ran across this back in February when I fixed the exact same bug in the ACI Python SDK (cobra) and I guess when I originally looked at your question I just skipped over python.

Please see the following doc which was updated 10 months ago to cover this specific scenario:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/api/rest/b_APIC_RESTful_API_User_Guide/b_IFC_RESTful_API_User_Guide_chapter_010.html#concept_D88562359A8A4A87B6B62C7D1B83EEB5

"Although the JSON specification allows unordered elements, the APIC REST API requires that the JSON 'attributes' element precede the 'children' array or other elements."