Skip to content
This repository has been archived by the owner on Mar 25, 2018. It is now read-only.

NodePool Notes

Jump to bottom
jclouds edited this page Apr 3, 2012 · 4 revisions

Pool Provider Design

a pool provider needs to accept a ComputeService as the backing provider, and check-in/out resources on create/destroy. a node is eagerly provisioned (i.e. backfilled) as until mincount is met, limited by max count a means for reducing response time to user. (see normal pool semantics :) ) references

There is a pool of vms behind a facade that implements PooledComputeService.

PooledComputeService extends ComputeService and adds startPool() method

The pool is only configured with the following:

  • a backend cloud connection (backingProvider)
    • ex. providername, identity, credentials, properties
  • a jclouds group (backingGroup) used for the pool
    • ex. “backing”
  • a template (backingTemplate) used to create the pool
    • ex. templateBuilder.osFamily(UBUNTU).options().inboundPorts(22, 8080).build());
  • a minimum pool size.

PooledComputeService.startPool

  • backfills to minimum pool size, backingProvider.createNodesInGroup(backingGroup, minpool - current, backingTemplate)

PooledComputeService returns the following:

  • listAssignableLocations returns ImmutableSet.of(backingTemplate.getLocation());
  • listHardwareProfiles returns ImmutableSet.of(backingTemplate.getHardware());
  • listImages returns ImmutableSet.of(backingTemplate.getImage());

now.. on create/destroyNodes, we have to employ logic to associate/dissociate the nodes with the groupName the user of the pool specifies.

When a user of the pool implementation of ComputeService goes to createNode, the following happens:

a node is taked out of the available pool

state is associated with it, at least the groupName

When a user of the pool implementation of ComputeService goes to destroyNode, the following happens:

state is dissociated with it, at least the groupName

a node is returned to the available pool

Staining node with a temporary group name:

Nodes in the backing store may have a group “backing”, but we still want to support groups.

So, in this way, a user can issue createNodesInGroup(“foo”, 1) createNodesInGroup(“bar”, 1)

The nodes, technically will be a member of “backing” in whatever the back-end provider is. In order to keep the contract of the api consistent, we need to overlay a temporary groupName on top, so that software expecting the node from createNodesInGroup(“foo”, 1) to have node.group = “foo”, as opposed to it being “backing”

There’s a couple ways to do this. The easiest way is to use providers who support userMetadata. In this case, we can make a metadata value for “jclouds.pool.group” and set this on create, remove on delete, and convert on get/list.

ex. listNodes would need to employ a function like:

Function<NodeMetadata, NodeMetadata> apply() return NodeMetadataBuilder.fromNode(in).group(in.getUserMetadata().get(‘jclouds.pool.group”).build();

or similarly, this could just be done with a shared singleton Map. Only slight glitch is that the group mappings won’t persist JVM crash, but this is not currently a requirement.

idea is to copy https://github.com/jclouds/jclouds/tree/master/apis/byon into https://github.com/jclouds/jclouds/tree/master/labs/nodepool and make similar objects that implement only the above requirements.

Clone this wiki locally