Hi all,
I'd like to restructure the
org.apache.brooklyn.entity.machine.pool.ServerPool entity and associated
location, in a way that is not backwards compatible. This entity is
marked "@Beta". This is motivated by some changes in Clocker.
This will be quick to do - if there is agreement I'll do it within the
next couple of days so we can get these changes in 0.9.0.
_*Background*_
The ServerPool creates a pre-allocated set of machines (managed as a
DynamicCluster) that other applications can deploy to. It registers a
"location type" that allows other apps to treat this as a target - the
location's obtain() will claim a machine; the release() will return it
to the pool.
Multiple locations can be created that are all backed by this same
ServerPool.
The ServerPool makes use of the LocationOwner and DynamicLocation
interfaces.
_*Comparing to Clocker's usage*_
Clocker also makes use of the LocationOwner and DynamicLocation. When a
cluster of Docker hosts is provisioned, it automatically creates a
"docker location" that can be targeted by other applications (and
similarly for a single Docker host).
Importantly, Clocker creates that single location immediately. All
applications share that location object.
_*ServerPool Limitations*_
The ServerPool's usage of LocationOwner is inconsistency: the ServerPool
"owns" multiple locations, which is not modelled in the LocationOwner
interface.
When a machine is released (making it reusable by the server pool), it
is not cleaned up. e.g. if the previous app left software installed (or
even running), then that will still be on the machine!
If you call serverPoolLocation.obtain(config) then the config is
currently ignored. It just claims the next available machine from the
ServerPool cluster.
_*Short-term Changes*_
Short-term, I'd like to change ServerPool so that it has *one* location.
Any app that makes use of that location will be re-using the same
location object. There are two reasons:
1. this is more consistent with LocationOwner, and with the usage in
Clocker;
2. this is closer to what actually happens under-the-covers: it is
sharing the same ServerPool, and not respecting different config for
different locations.
I'd also like to change the DynamicLocation interface to make explicit
its responsibilities for register/unregister - this will give it an
opportunity to register the location so it can be used by other apps.
_*Longer term*_
Much longer term, we could have a new implementation of ServerPool that
deals better with the cleanup. For example, instead of returning a
direct reference to the machine, it could create a single Docker
container with sshd running, and return that. On release, it would
delete the docker container.
