vRA IPAM SDK - How to make changes to the schema?

[craigso]

Hello!

Thank you for taking the time to read this thread. Let me start out by saying I'm fairly new to vRA development so perhaps I'm taking the wrong approach.

Background:

My team has been tasked with building a custom IPAM connector/plugin for our open source IPAM solution. We've started by grabbing the vRA 7.3 IPAM SDK package and documentation and getting that imported into our development environment. While we are still digging into the SDK and crafting it to our needs, I had a few questions about the IPAM schema and how data is presented in vRA.

The issue:

We will be interacting with our IPAM solution via it's restful API. Authorization to the API requires a username, password, and a security key. The add and edit endpoint page allows for input of the following properties (below). I would like to also take input of a SecureString for the API key so this can easily be used within workflows.

From what I can tell, the bottom 3 fields are configured via the schema as shown below:

{
         "id": "address",
         "label": "Address",
         "description": null,
         "dataType": {
            "type": "primitive",
            "typeId": "STRING"
         },
         "displayAdvice": null,
         "orderIndex": 1,
         "permissibleValues": null,
         "state": {
            "dependencies": [],
            "facets": [
               {
                  "type": "mandatory",
                  "value": {
                     "type": "constant",
                     "value": {
                        "type": "boolean",
                        "value": true
                     }
                  }
               }
            ]
         },
         "isMultiValued": false,
         "columns": null
      },
      {
         "id": "username",
         "label": "User name",
         "description": null,
         "dataType": {
            "type": "primitive",
            "typeId": "STRING"
         },
         "displayAdvice": null,
         "orderIndex": 2,
         "permissibleValues": null,
         "state": {
            "dependencies": [],
            "facets": [
               {
                  "type": "mandatory",
                  "value": {
                     "type": "constant",
                     "value": {
                        "type": "boolean",
                        "value": true
                     }
                  }
               }
            ]
         },
         "isMultiValued": false,
         "columns": null
      },
{
         "id": "password",
         "label": "Password",
         "description": null,
         "dataType": {
            "type": "primitive",
            "typeId": "SECURE_STRING"
         },
         "displayAdvice": null,
         "orderIndex": 3,
         "permissibleValues": null,
         "state": {
            "dependencies": [],
            "facets": [
               {
                  "type": "mandatory",
                  "value": {
                     "type": "constant",
                     "value": {
                        "type": "boolean",
                        "value": true
                     }
                  }
               }
            ]
         },
         "isMultiValued": false,
         "columns": null
      },

Solution?

I'm wondering, is it possible to add additional fields to this endpoint page? If so, do I need to do that via somehow updating the schema (ipam_endpoint_class_id) with the additional field? Again excuse me if I'm taking the wrong approach.

Thank you!

[craigso]

reading the SDK documentation a bit more it shows how to update the get the default schema and how to update it, I guess the question is, if I modify it and add another field, will that be presented on the endpoint page?

[craigso]

Rather than extending the schema, I just created a encrypted property and passed the API key to the workflow that way. Seems to work just as good. Would be good to know how to extend the endpoint page. Is there any documentation on the vRA 'core' ? Seems like somewhat of a black box, which makes it difficult to develop against.

[craigso]

We are discussing the IPAM SDK with the VMware SDK support team. They were not immediately aware of who wrote or maintains it, so they are doing some research. Hope to hear something back soon.

[xian_]

I'm also working on a IPAM plugin.

I do not bother with vRA interface too much, just implemented a vRO workflow to register the RESTHost in vRO and create endpoint via vRA REST API. Mostly based on the SDK content.

I store the credentials only in vRO and added a custom property to vRA to identify the RESTHost. vRA sends all the credentials but I skip them and use vRO endpoint auth only based on the custom prop.

If you want to go the other way (using vRA creds) I would still add the extra encrypted property to vRA but the interface to register it is still a vRO workflow. Even the "big ones" (Infoblox, ...) do it this way. If you want to, you can still present the workflow as an XaaS blueprint in vRA but most of the time this is not an end-user service and admins should not be afraid of running a bare vRO workflow.

- just my opinions, I'm also learning on my own

[craigso]

I'm interested in your work, we've been hitting a few roadblocks but for the most part it works great.

We configured the IPAM solution as an endpoint using the IPAM sdk

We then setup additional properties like this:

Since the IPAM SDK workflows have Endpoint as an input, the properties are accessible. Via Endpoint.properties.propertyname.

What we are struggling with now is if the IPAM workflows are not called via vRA, we can't pass the endpoint. As a result, we can't access the additional properties, mainly anything that is a secure string or encrypted.

In our workflows we embedded the API calls using RESTHostManager.createHost(). This method has worked okay, but support has mentioned it could become an issue. Something with it being a singleton.

Can you elaborate on your work a bit? I'm generally curious if we should plan to migrate to using the rest host and rest operations.

[xian_]

I just tried to read endpoint properties from vRO but was not able to fetch anything besides name, id, extensionData (regular credentials) and some other useless data.

The API explorer mentions vCACCAFEEndPoint.getEndPointAttributes() but it was not working for me.

So if your workflows are not started by vRA than I see no way of getting those properties.

Wrt. my approach I registered a REST Host in vRO (so I don't have to create one with createHost() every time a request is made). I added the id of that REST Host to the vRA endpoint as a property and in my workflows I use it to search for the correct vRO REST endpoint (I could also use the name but I trust the id instead). This does not solve your problem of getting that information from vRA if vRA is not the initiator.

As a workaround you can store that info in vRO config element as well and fall back to it as default if vRA is not involved. Or if you have a single IPAM host, you can hardcode (bind directly) it into your workflow inputs. I wonder what else triggers those IPAM workflows?

With RESTHostManager.createHost() you are already using REST Host so I don't think you need to migrate, maybe just how you use the REST plugin.

In my case I created an action with all the inputs (RESTHost, method, URL, content) needed to make the API call and use RESTHost.createRequest() and RESTRequest.execute() to send and receive the data, so I don't have to write the same javascript code every time.

[craigso]

Thanks for sharing. Give me some great ideas to try later on. I think it's probably a good idea to switch to the built in rest operations. I'll put it on the todo list for v2. We've got some pretty tight deadlines on this project so perfecting the IPAM plugin in phase 1 is unlikely.

In my case I created an action with all the inputs (RESTHost, method, URL, content) needed to make the API call and use RESTHost.createRequest() and RESTRequest.execute() to send and receive the data, so I don't have to write the same javascript code every time.

I just finished doing this about 2 weeks ago. It also allowed us to write a bunch of error handling into the action and keeps the workflow scripts nice and clean.