Issues with the Network Profile API (iaas-proxy-provider/network/profiles)
• Craig
First of all, the documentation states that you should authenticate as a Tenant Administrator to work with this API. This wont work because it is the job of the Fabric Administrator to manage network profiles. You simply get a 403 response when trying to use any of the methods.
Judging from a conversation I had on twitter, it seems that Phrashant Chamarty had already come across this.
But once you have authenticated with the right user most things appear to work…
What works
- Retrieve the network profile
- Creating a new network profile
- Update network profile properties
- Update defined range properties
What doesn’t work
- Updating a defined Address within a defined Range
I guess this is a fairly small issue but an interesting one none the less..
The idea of being able to consume a network profiles basic IPAM abilities with an advanced service is quite a neat one (in my opinion anyway).. it solves some issues.. especially if you don’t have a central IPAM solution.
The process would involve getting a network profile, then grabbing the next available IP address within a defined range and updating it’s state to ALLOCATED using the PUT method described here.
As stated above you can update properties of the network profile and any defined range within it. However, when you try to update the defined addresses within a range, it will mess up the configuration of the network profile.
If you had any addresses allocated to resources already in this range, these are wiped out. It also appears that the addresses become disassociated with the range.
Looking in to the last point in a bit more detail, I discovered that a subsequent GET of the updated profile returns a valid description, however the defined addresses which were there before are gone!
Digging in to the IaaS database shows that the what ever happens behind the scenes in the CAFE API is wiping out the StaticIPv4RangeID and I think the same is happening to the Hostname/VirtualMachineId too.
What confuses me even more is that the API description for staticIPv4Address shows a lot more fields than what is returned.
Anyway - this was pretty much a post about nothing! Maybe it’s a bug that is going to be fixed in a future release or this could even be handled completely differently in v7.
I’d be interested to hear if anyone has come across the same or similar issues. Get in touch via twitter if you have! :-)