External IPAM | VRA Internal References - Use Case

[joaoluisfaria]

Hello,

I would like to ask for feedback from the community regarding a use case.

Generally speaking, when we integrate an external IPAM plugin with Aria Automation we establish a way for Automation to ask an external IPAM for a new IP. The plugin talks to the IPAM, and returns a specific structure that says what is the allocated IP and how to reference it on the IPAM solution.(examples: rangeid, address space id., record id, etc)

Automation in return saves that information internally for later use.

On decomission of an IP, Automation feeds that "allocation information" back to the plugin, and ask's the plugin to talk to the external IPAM and deallocate it. So far so good, the internal references are given and the plugin does its job.

Now, let's assume that after 3 years of continuous deployments, the external IPAM need's to be replaced by a different solution (does not matter what, as long as we have a corresponding plugin to work with.)

So new deployments will talk with the new IPAM. using a new plugin. The new plugin will return it's own information on each allocated new IP and how to reach it in case of a decomission.

Now regarding old deployments:

The allocation of IPs was done with the previous plugin, which means that the stored information has no longer a viable structure for the new plugin with the new IPAM.

Automation will not succeed in deallocating the IP's that were given by the old IPAM, even though the new IPAM platform could have all the old information from the old platform migrated to it's own new structure, 

So the question is, how can we replace the old stored information with new information so the IP's can be properly referenced on the new IPAM using a new plugin?

The alternative basically is that all active deployments from 3 years that used IP's prior to the new IPAM, will allways fail when asked for decomission. 

Happy to hear your thoughts.

Best Regards,

[Czernobog]

The IPAM plugin in this case should not save/cache any data regarding the VM's IP configuration. It's just there to grab and assign an IP adress from your IPAM to a Automation provisioned machine. On a provisioning operation it looks up IPAM for a free adress in a range that you can select, for example by using constraints in Automation. It selects the IP, saves this information in the IPAM (ex. IP 1.2.3.4 is assigned to MAC aa:bb:cc, hostname is xyz) and either feeds this IP to the VM directly (static assignement) or just makes an IP reservation and is done. Similar during deprovisioning, it grabs the MAC address of the VM, looks up IPAM for this MAC, if it finds an IP - a delete operation for the IP and associated objects (hostname, dns entry...) executed.

This way no information needs to be saved by the plugin itself. In case of Aria Automation having a plugin save something would not be possible anyway, without using an external database or maybe an Orchestrator Resource element or dynamic type or a similar workaround. 

I have done a similar migration in the past. We went from a NSX-DHCP provisioned network to another external solution - Infoblox. Infoblox provides a plugin for Automation. Really the only 2 things we had to do was move the IP reservations from NSX DHCP to Infoblox and re-configure the networks in Automation, by selecting them as provisioned by an external resource and adding new tags, so that the constraints work during provisioning. No VM/IP-relevant data was touched.

IPAM should be the only source of truth for IP information, in my opinion, a the role of the plugin is to manage the communication between Automation and IPAM, this is all. 

[joaoluisfaria]

The output of the IP address allocation is saved into VRA as json information that the plugin gave in the moment of the allocation. That information is used later on deallocation

If you look into ipam_integration_contract_reqs.pdf you will see that on page 14 the id field is set with an internal ID information given from the IPAM side that matched the Allocation result. I speculate that each plugin from each IPAM solution will have its own format to represent the proper record in their side.

The same ID appears on page 16 for the IPDeallocation.

This information is kept during the entire lifecycle of each IP allocation, hence if the IPAM changes the way to represent the ID information to that specific IPAM record, the vra platform will not reflect that. hence my question, how to update the id information that it kept.