brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Turli <>
Subject Re: [PROPOSAL] Locations and CM tools
Date Tue, 01 Dec 2015 11:52:02 GMT

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?


Il giorno mar 1 dic 2015 04:36 Hadrian Zbarcea <> ha

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message