[PROPOSAL] Locations and CM tools

[Hadrian Zbarcea <hz...@gmail.com>]

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

Re: [PROPOSAL] Locations and CM tools

[Hadrian Zbarcea <hz...@gmail.com>]

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 <hz...@gmail.com> 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
>>
>

Re: [PROPOSAL] Locations and CM tools

[Andrea Turli <an...@cloudsoftcorp.com>]

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 <hz...@gmail.com> 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
>