Hi,
I was thinking about it for a few months and I still don't have a
complete proposal, but since discussions already go in that direction
I'll put it out there and we'll see where it goes.
There are a few motivating factors for this proposal:
1. The docs say that a Location is a "A location that an entity can be
in". The getParent(), getChildren() methods (if one didn't know the
interface name) makes the abstraction more of a tree node.
2. In addition to the tree like organization of Locations, there is a
second tree hierarchy of the kind of location (e.g.
ProvisioningLocation, SimulatedLocation, AddressableLocation, etc. This
piece is related to what Andrea mentioned on the other thread (i.e. we
could use a SimulatedDriver to operate at a Location).
3. In my mind the relation is more of a graph.
After a few conversations with Brooklyn contributors and committers, I
come to believe that we should refactor a Location to mean something that:
- is addressable (probably in multiple ways)
- provides an API, actually probably more to operate at that location
(e.g. ssh, http, bash commands, etc). Credentials may be required to use
the API.
In my model Locations are flat, i.e. no in-memory references (pointers)
to other locations, just URLs. A location manager (registry, need to
find a reasonable name) maintains one or more data structures to manage
the locations.
Example:
List<String> Location.getAddresses() would return something like:
- deployed-at:<id> (equivalent to getParent() today)
- geoip:(lat, long)
- ssh:root@localhost
- karaf:karaf@<ip>
- ssh+yum:root@localhost
- ssh+npm:root@localhost
- ssh+ansible:root@localhost
- winrm:<service address>
(obviously in the above example we have a both Windows and RHEL box,
which is wrong, but it'll do for this proposal :) ).
An external service would build a graph and would allow for searches on
a graph given some criteria.
Another thought I will mention is that the way our entities are
implemented, they give the impression that Brooklyn is more of a CM
tools with the logic of deploying provided in Java. This is both not
accurate and doesn't do Brooklyn justice. It is imo next to impossible
to build an entity that would satisfy a large majority of users. The
complexity becomes prohibitive. For that reason I see Brooklyn more of
an enabler for implementers of entities to provide and promote their
implementation. E.g. it's next to impossible to implement a best,
complete entity for mysql, and it's more likely to see: hadrian-mysql
(that has some characteristics, say it's super secure, deployed with
bash, only works on ubuntu), and andrea-mysql (which is deployed with
chef and is supper fast) and cipi-mysql (deployed in a cluster topology,
super resilient). A user would pick the one they prefer and use it in
their blueprint. This is no different than the kind of ecosystem docker,
chef, puppet, etc, created.
I'll stop here hoping for some feedback. This proposal has a more
significant backwards compatibility impact and should be considered
independently of the other proposal related to locations.
Cheers,
Hadrian
