Thanks Andrea,
Actually my proposal is not that close to what you mention, but remember
I mentioned two proposals :). The second one is less pretty in terms of
backwards compatibility, but I didn't want to muddy the waters.
Actually, the last part of this proposal could be considered as a 3rd
(corollary) proposal. What I didn't mention is that anything that allows
the deployment of compute resources (kinda like a Package Manager) can
be seen as a location: Karaf (for features, bundles), Tomcat (for wars),
mysql (for databases, schemas, tables). Obviously, docker (already on
that path) and cloudfoundry as well.
Since the cat is out of the box, let me post the second proposal too.
Will do so shortly.
Thanks,
Hadrian
On 12/01/2015 06:52 AM, Andrea Turli wrote:
Hadrian,
I think there is an additional point we need to consider: paas locations.
There is an ongoing discussion on Brooklyn on how to support things like
cloudfoundry location. That discussion seems to favor the drivers approach:
we'd like to model the entity once and being able to deploy and manage it
with the right driver that depends on the target location.
I see your proposal close to this approach but it is using an hoerarchy of
locations rather than multiple drivers. Do you think these two approaches
should be merged or you think we should keep them separate?
Best,
Andrea
Il giorno mar 1 dic 2015 04:36 Hadrian Zbarcea <[email protected]> ha
scritto:
Hi,
Over the Thanksgiving weekend I spend a lot of time looking at Salt and
Ansible. I used the Chef and old Salt support as a starting point and
got to things somewhat working, but not in a way that satisfied me. I
got back to the concept of Location that caused my problems in the past
and I knew I'll have to look more into. Yesterday I had a short chat
with Cipi@ and he threw a very interesting idea that got me thinking all
day. There are 2 proposals coming out of it, this being the first.
Brooklyn is not really a CM tool, although sometimes it's perceive as
such because of its advertised features (I do get the "oh, but I could
do this with <my cm tool of choice> already" answer many a time).
Brooklyn could (and should) use such a CM tool under the hood. Brooklyn
is more concerned with the "what" (via blueprints) not the "how". As
such, unless I am mistaken, there is no concept of Package Manager, or
Location where deployment is governed by a Package Manager. (The closest
we got is BashCommands.installPackage(...) flavors and helpers like
BashCommands.if<Cond>Else0/1.
I believe a better model would be to have something like ChefLocation,
SaltLocation, AnsibleLocation, etc. layered on top of another
MachineProvisioningLocation (which could be elastic or not). Note that
multiple such ConfigurationManagementLocations (of the same or different
kind) could coexist layered on top of MachineProvisioningLocation (such
as a public cloud or byon). One or more machines at such a location
would be designated as "master", managing the other Locations at that
location.
The architectural rationale (imo) for such a model is that CM tools
actually manage machines (Locations) and not services directly.
Related to this I think a PackageManager (and maybe a
PackageManagedLocation) may be necessary. The same box could use yum
(Centos et al) and npm, or pip, or gems to manage packages and they
could all coexist on the same box. This starts to move on the CM tools
turf, but I feel it's needed.
Thoughts?
Hadrian
