Introducing service_vars for Service Provisioning

We’ve made it easier to share data between Service objects during Service Bundle provisioning.

Introducing service_vars, an enhancement that allows users to store information about a Service in the root Service object.


Service provisioning is widely used today and offers many advantages.

One major advantage is the ability to use Service Bundles to provision multiple Services.

Service bundles contain multiple Service items that can be provisioned at the same time, or in an order specified by the Service designer.

Using Service Bundles to provision multiple Services has a disadvantage in that it is difficult to share data between the Service objects during provisioning.

When provisioning a Service Bundles items in order, many times there is data from an individual Service Item provisioning that needs to be shared with some/all of the subsequent Service Items.

Q. What’s new?
A. We’ve added the ability to store data in the root Service during provisioning.

New methods:

$evm.set_service_var(key, value)

Implementation Details:

  • Get/Set update the root Service(top level parent Service).
  • Values are stored in the Service object options hash.
  • Can use substitution syntax to get service_var values.
  • The naming convention is up to the user.

The call to get/set service_vars is very similar to the call to get/set state_vars.

For example:

Setting a service_var:

$evm.set_service_var(‘test_service_var’, “test value for service var”)

Checking to see if a service_var exists:

var = $evm.service_var_exist?(‘test_service_var’) && $evm.get_service_var(‘test_service_var’)
$evm.log(“info”, “service var: test_service_var = #{var}”)

Passing data between Service Items in a Service Bundle:

For example:
A Service bundle containing 3 Service items, using provision priority. Service item 1 completes, followed by Service item 2, and finally Service item 3.

Service item 1 provisions a VM, and Service item 2 needs the IP and other information to configure the VM. There’s no easy way to access the first Service item VM ip address in the second Service item.

Using the new set_service_var would allow the user to set values from Service item 1 in the root Service to be accessed in Service item 2.

Similarly, post processing in the second Service item could provide necessary information for Service item 3.

Q. What is the root Service?
A. The root Service is defined as a Service object that doesn’t have a parent Service.
A Service object is created each time a Service Item is provisioned. Provisioning a Service Item will create a single Service object. (It is also the root Service since it is has no parent Service.)

Since a Service Bundle contains multiple Service Items, multiple Service objects are created during provisioning. The root Service is the top level(Bundle) Service.

Stay tuned for the next post where we’ll discuss:

  • Using service_vars with set_stats
  • setting object values from set_stats

Check out the set_stats post:

[RFE] As a Service Designer, I should be able to pass variables between Catalog Items in a Bundle.