This will likely be a mult-part series… let’s just jump right into it and see where we end up.
I’m preparing to potentially roll-out VMware’s VeloCloud SD-WAN solution to 650 locations globally. In a recent conversation with VMware I heard how difficult and expensive it was going to be from a professional services standpoint to accomplish all that work, and it was suggested that I needed to work with a partner for all the application coding and development time that would be needed. The work was suggested to potentially cost 5 or even 6 figures. I’ m not talking about the physical logistics of such an undertaking, I’m talking about just the steps needed to programatically build and configure 650 Edge profiles, with names, IPv4 addresses, etc.
I called bullsh*t.
I’m assuming this is another example of a vendor or manufacturer trying to appease their partners and resellers. If they provide the customer and end-user too much information, there might not be a need for any professional services by the resellers or partners. This is completely the wrong approach to take IMHO… the vendor should empower their customers and end-users. There will always be customers that don’t have the skill sets or resources to tackle the job for themselves and that’s where the resellers and partners should fill the role.
I took a few hours this weekend and wrote some quick cURL commands and Python code to understand if the effort was really worth 5 and 6 figures. In short it wasn’t. I understand resellers and partners want to be compensated but if you are going to be unreasonable then I’m going to go do it myself, and then I’ll likely open source the code just to prove my point.
Here are the steps I believe we’ll need (yet to be fully tested);
- Step 1. Login via rest/login/enterpriseLogin (store authentication cookie)
- Step 2. Call rest/enterprise/getEnterpriseConfigurationsPolicies to get the profileId that we’ll be using for all the devices (this is the Profiles in the UI)
- Step 3. Call rest/edge/edgeProvision with template passing STORE_NAME along with profileId (again this is the Profiles in the UI), result will be edgeId and activation key
- Step 4. Call rest/enterprise/getEnterpriseEdges passing edgeId to confirm
- Step 5. Call rest/edge/getEdgeConfigurationStack to get profileId of new edge profile (this is the device specific profile for anything that is overridden from the “Profile” set in the device configuration)
- Step 6. Call rest/configuration/updateConfigurationModule with template replacing edgeId and profileId along with IPv4 addresses, etc parse result to confirm – THE MAJORITY OF WORK IS ACCOMPLISHED IN THIS STEP
- Step 7. Logout via /rest/logout
I can’t completely trash VMware because there is a well documented API available and VMware has made examples available but when talking face to face with VMware personnel it’s almost as if they are forbidden from talking about any of that. VMware even hosts a community repository (click on Related Code Samples) which is open to the public.
Why not just create the 650 Edge profiles in the WebUI?
- Time – I would estimate it would take about 5 minutes to create a single Edge profile in the WebUI. 650 * 5 = 3,250 / 60 = 54 hours
- Errors – There would inevitably be a lot of errors from all the typing or cutting-n-pasting required which would create additional deployment issues and delays downstream.
- Future – Wouldn’t it be nice to have a proven method of deploying new devices programtically? Yes it most certainly would be.
It boils down to these two facts; 1) It will take me much less time to write this code now than it would to sit at a keyboard for 54 hours, and 2) the rate at which we are rolling these out, I can’t afford any fat finger errors in the configuration – I don’t have the backend resources to support troubleshooting “stupid” fat finger mistakes down the road.
So now I have a general outline of what I need to-do. The store names can easily be generated programatically along with all the IPv4 addressing so what’s left then is to decide what language to use in writing this beast?
Perl or Python?
I’ve used Perl since 1997 and I’m really comfortable writing code in Perl and more so re-using all the different snippets of code I’ve written in the past. So I’ll probably use Python to help expand my experience writing code in Python although I likely won’t use the VMware SDK, I’ll just write directly against the REST API.
You have any recommendations?
Cheers!
Del says
Excellent post. Great read. Looking forward to the follow ups very much.