I think this would be a sensible change.
The fact that the entity is still annotated @Beta almost two years after
its introduction suggests that it is due this kind of review and refactor!
Sam
On 17/03/2016 12:42, Aled Sage wrote:
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.
