In case of a deployment of an multi tiered application, it is often necessary to store information which was generated while provisioning the first VM, so it can be retrieved during provisioning of the following VMs.
A simple example could be a service catalog bundle consisting of one DB VM and two application servers. The two application servers have to be configured to use the previously created DB.
One way to store and retrieve this information, is to use the parent miq_request object. The following code block is doing this:
1 db_ip = $evm.root['miq_provision'].miq_request.get_option(:db_ip)
2 if db_ip.nil?
3 $evm.log("info", "#{@method} - Storing IP address #{vm.ipaddresses[0]} in db_ip for later use")
4 $evm.root['miq_provision'].miq_request.set_option(:db_ip,vm.ipaddresses[0])
5 else
6 $evm.log("info", "#{@method} - db_ip is #{db_ip}")
7 end
As you can see, the option db_ip is only set, if it was nil. This should make it easier to reuse the same code in all provisioning state machines, but only set the db_ip while provisioning the (first) Database instance.
When creating the service catalog bundle, it is important to make sure, the DB Instance is created first. The application servers are second - and since they do not depend on each, they can be deployed in parallel, to speed up the overall process.
To retreive the db_ip during provisioning of the applicatin servers, this code block can be used:
1db_ip = $evm.root['miq_provision'].miq_request.get_option(:db_ip)
2if not db_ip.nil?
3 $evm.log("info", "#{@method} - Found db_ip #{db_ip} and storing it for later...")
4 prov.set_option(:db_ip,db_ip)
5end
If this is added in the customize_request method, the following methods can retrieve the db_ip by using
1db_ip = prov.get_option(:db_ip)
Retrieving the IP from the miq_request and storing it in the prov.options is optional. However, storing the information in the provisioning object is more efficient, if the variable is needed in multiple methods.