This post is part 2 in a series on the backend processes we use to manage the Hands-on Labs. The first part is available here.
Before I get into the guts of handling export, replication and import, I think it is important to understand how to identify which templates we need to work with. Sure, starting from scratch is simple: you have a bunch of templates in cloud A that you need to replicate to cloud B. Typically, that is going to take quite a bit of time. The problems involved with initial transfer to the cloud are similar to those encountered when standing up a new DR facility. Namely, how do you “seed” the DR site with the data from production. Shipping a box of tapes and performing a restore is often the least expensive option, but may not provide what you expect if your data change rate is high. That discussion is beyond the scope of this post, but I can come back around to it if there is enough interest.
Back to the topic at hand. Once we have a set of clouds that host our content, we need to ensure that the templates available in each cloud are the same. As we revise our content, we check in new versions with new names. Each of our labs have a “Lab Code” or “SKU” that we use to identify them internally. For example, our wildly popular NSX lab has a SKU of “HOL-SDC-1303,” which is easier to track than the full name, “VMware NSX Network Virtualization Platform.” The first template for this lab might be called HOL-SDC-1303-v1. When we make a change to that lab, we check it in as HOL-SDC-1303-v2, then HOL-SDC-1303-v3, and so on. This is a rather simplistic practice, but it serves its purpose. Continue reading