+1 on the changes This will obviously help Clocker as well; thanks, Aled.
Andrew. On Thu, 17 Mar 2016 at 14:11 Sam Corbett <sam.corb...@cloudsoftcorp.com> wrote: > 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. > > > > > > -- Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
