Using infrastructures with workflows

Note: Support for workflows is experimental and subject to change

As described in the introduction the Metalsoft has a clear distinction between utilization and administration of resources. At utilization time, physical resources (such as servers) are associated to logical resources (such as instances). This association also comes with some assumptions about the topology if the network, about which IPAM to use etc.

Note: support for high level workflows is work in progress and is subject to change

An “Infrastructure” defines the user’s intent and, by default utilizes the built-in strategies for provisioning.

In a scenario where a completely custom provisioning process is required the user has the ability to pick and choose which parts of the current behavior are to be kept and which are not.

In this situation the infrastructure design acts as a blueprint for how the deployment is to happen describing the not just the infrastructure designer’s intent but also how to get to the desired outcome.

Attaching workflows

Workflows can be attached at multiple points as part of an infrastructure:

infrastructure with workflows

1. pre-deployment workflows will be executed before servers get allocated to instances. Typically at this stage you would allocate infrastructure-wide resources such as subnets.
2. InstanceArray workflows - these workflows will be executed in-lieu of the default provisioning steps for each instance of an InstanceArray (cluster of instances). One of these steps is the OS install step which is governed via the OS Template mechanism. More on this below.
3. post-deployment workflows will happen after everything else. This is where admins will add nodes to a cluster, notify external systems of provisioning completion etc.

Empty infrastructures

You can have a completely empty infrastructure with workflows attached to either pre or post deploy. In this case 1. no networking provisioning is done automatically 2. no server allocation is done automatically 3. a subnet is allocated but no IPs are allocated to servers

Attaching a workflow to a instance array

If you attach a workflow to an instance array, the workflow will be executed on each instance. You can control how provisioning will be done for that instance:

1. The InstanceArray’s definition will instruct the system on which servers to allocate from the pool of servers of the associated datacenter.
2. The iInstanceArray’s network port configurations will instruct the system to use the built-in support for networking. Left unattached the associated switch ports will be left in a shutdown state.
3. The InstanceArray’s template field will instruct the system on how to perform the OS install step. If populated with a pre-defined OS Template it will use the assets and steps defined in that template. If a regular built-in template is used, the system will use the built-in mechanism (which includes diskless setups).

Specifying certain server IDs

If a certain server has to be used it can be specified using the objDeployOptions object of the infrastructure_deploy() function.

For example:

{
	"instance_array": {
		// InstanceArray ID 99
		99: {
			// Server type ID 75
			"75": {
				"server_count": 1
                
                // If the preferred server is not of server type 99 an error will not be thrown and another server will be allocated.
                // If the preferred server cannot be allocated for any kind of reason, an error will not be thrown and another server will be allocated instead.
                // The preferred is only given allocation priority.
                "server_ids": [5]
			}
		}
	}
}

While supported, this mechanism is not recommended as it makes workflows less portable. Server types should be used instead.