Empty API response? /config/policies

[X2]

I have been using the Swagger UI for finding out what I can get using API calls. The aim is to conver my perl scripts (cumbersome) which collect my CMDB data from the backup domains to use API calls (easier). However, I have been hitting road-blocks often.

Currently, my call for /config/policies is successful, but returns the following only:

{"data":[] }

also, the /config/policies/{policyName} call returns "the specified polcy does not exist in the configuration database"!

Does anyone know why I'm getting this? Am I missing something?

PS: I'm using an API key for authorization

[RiaanBadenhorst]

There is a problem with some policy types and/or storage configuration i.e if the volume pool was set for a tape storage unit and then overridden with an SLP. Or something to that effect. You can verify which policies are messing your call up by calling each policy individually. You might one or more that respond with 500.

[X2]

Tried half a dozen policies one-by-one using /netbackup/config/policies/{policyName} and all of them give

the specified policy does not exist in configuration database

Is that normal?

[Krutons]

Are they all the same type of policy? Maybe those policies you chose have similar volume pools or something. I'd try a variety of policies. I know when I try to run /config/policies from my production environment it returns nothing but I can run /config/policies/<policy name> against a lot and it returns the correct info.

I did try /config/policies in a pretty small rebuilt development environment and it returned all the policies but there are less than 10 there currently and pretty default/standard configurations.

[X2]

I didn't make a note yesterday but they were definitely different policies but I'm sure they were not the same policy types.

So, I ran the call again using Standard, NDMP, Oracle, and MSSQL policies and got the same response! Is this a known issue? I don't see such behaviour documented in the API documentation.

[Krutons]

I have noticed that the policy names are case sensitive and during my testing, if I don't follow the exact policy name, I get the same message as you.

Trying an SAP policy for archive backups with 'virtual' volume pool I get this. I get this same error with NDMP policy with "onsite" volume pool.

{
  "errorCode": 8809,
  "errorMessage": "Policy API for the specified operation, version, and policy type is supported only using the generic schema, with the request header (X-NetBackup-Policy-Use-Generic-Schema) set to true.",
  "attributeErrors": {},
  "fileUploadErrors": [],
  "errorDetails": []
}

When I set X-NetBackup-Policy-Use-Generic-Schema to true

{
  "errorCode": 130,
  "errorMessage": "system error occurred",
  "attributeErrors": {},
  "fileUploadErrors": [],
  "errorDetails": []
}

I've seen several other errors which I assume is related to volume pool.

Here is another one, Standard policy type and "sap_onsite" volume pool.

{
  "errorCode": 130,
  "errorMessage": "system error occurred",
  "attributeErrors": {},
  "fileUploadErrors": [],
  "errorDetails": []
}

I think there are way to many bugs with this API as of now to try to recreate anything that is running in production if that's what you're trying to do. It seems like unless the volume pool with NetBackup, the API call will fail from what I've seen so far.

[X2]

@Krutons @RiaanBadenhorst  Thanks for your comments.

I have been trying different things with the /netbackup/policies/ call and have not been successful. The cleanest way that I thought should work was to create a simple Standard policy from scratch and try the API call. It still complained that the policy is not in the configuration database.

I understand that the API can be buggy but /netbackup/policies/ seems to be something that is yet to reach "alpha" testing stage. I agree @Krutons that the API is not mature enough to replace my production scripts. I shall wait till 8.3 to try my luck again.

[CliffordB]

Just an idea.

The WebUI is built entirely on the APIs.  If what you are trying to do does not exist in the current (8.2) WebUI, then it is possible you cannot get the data with APIs alone.  

For 8.3, we expect many more APIs will be availble.  Also with 8.3: more exposue of Policies in addtion to Protection Plans.

I have not personally played with them much.  Just a general knowlege of some of them via the swagger interface.

Hope that sparks a thought.  Cheers

[X2]

@CliffordB  Thanks for the information. I have gone into the SwaggerUI first to readup on what the call does. I try it out in the SwaggerUI and then try the same using curl command. Will wait for 8.3. Hopefully, it will give more information about tape robots too (wishful thinking).

Side note: opening a case with support is futile as they say "your code is not supported", even if it is a copy paste of the curl command from documentation! Atleast they should be able to provide document where the error is detailed.

[MarkColetta]

I assume you are doing a get... In swagger you should be able to run:

GET https://masterserver/netbackup/config/policies  - this should retrun all your policies

You can also use curl, or use an API tool like postman/insomnia to do the call, and run

curl -X GET "https://masterservename /netbackup/config/policies/" -H "accept: application/vnd.netbackup+json;version=4.0" -H "Authorization: enter_key_here"

[Krutons]

Mark, we know what should be capable but that just isn't the case. We've verified that there are issues regarding Volume Pools among other problems with the API.

This is from production, where multiple volume pools exist.

curl -X GET "https://<master>/netbackup/config/policies/" -H "accept: application/vnd.netbackup+json;version=3.0" -H "Authorization: <API Key>"

{
  "errorCode": 11,
  "errorMessage": "11",
  "attributeErrors": {},
  "fileUploadErrors": [],
  "errorDetails": [
    "system call failed"
  ]
}

This is from a newly built development/sandbox environment.

curl -X GET "https://<dev master>/netbackup/config/policies/" -H "accept: application/vnd.netbackup+json;version=3.0" -H "Authorization: <Dev API Key>"

{
  "data": [
    {
      "links": {
        "self": {
          "href": "/config/policies/Catalog_Backup"
        }
      },
      "type": "policy",
      "id": "Catalog_Backup",
      "attributes": {}
    },
    {
      "links": {
        "self": {
          "href": "/config/policies/<dev linux standard backup policy>"
        }
      },
      "type": "policy",
      "id": "<dev linux standard backup policy>",
      "attributes": {}
    },
    {
      "links": {
        "self": {
          "href": "/config/policies/<dev vmware policy>"
        }
      },
      "type": "policy",
      "id": "<dev vmware policy>",
      "attributes": {}
    }
  ]
}   

[punchinfotech]

We just resolved this issue on a tip from Netbackup support. 

The /usr/openv/netbackup/db/class directory should have subdirectories for every active policy installed on the master server.  For example, ./class/policy1, ./class/policy2, etc.

Each of these policies SHOULD have a file named "info" withinin the directory.  If ANY policies is missing that "info" file, the call cannot complete and {"data":[ ]} is returned.

Turns out, we had just completed a clean-up of old policies using the java client.  There must be a bug when deleting a policy this way; it doesn't completely remove the subdirectory and the "client" file underneath it.

Hope this helps!  

[vtas_chas]

Do you know if Support logged an eTrack on this?