Fwd: Support OS without packaging system

[Elazar Leibovich <el...@gmail.com>]

Forwarding to ambari-user, since I suspect ambari-dev is primarily used for
JIRA.

---------- Forwarded message ----------
From: Elazar Leibovich <el...@gmail.com>
Date: Fri, Jul 5, 2013 at 4:11 PM
Subject: Support OS without packaging system
To: ambari-dev@incubator.apache.org


Hi,
I'm currently consider deploying Ambari on home brew hardened Operating
Systems which does not feature package managements. You cannot use anything
like RPM, deb packages etc.

The way I was thinking of handling it is:

1. compile all the required package to a certain shared directory:

//fileserver/opt/{hbase,hadoop,oozie}

2. Define fictive package manager for Ambari that would simply copy the
files to a node instead of triggering actual installtion script.

Ambari will then act as usual and will try to install those packages using
my fictive package manager.

If the base OS installation has all the dependencies, Ambari should still
work.

1. Can that work? I'm don't know too much about Ambari's architecture,
besides a few slides decks I found.
2. Is that interesting as a JIRA? I think that this flexibility (work on
any linux system at all, if you can ./configure && make hadoop on it -
ambari will take care if that) is beneficial for more people than just
myself. If it is, I'd like to coordinate my efforts with the project, and
to submit the code eventually.
Note that this is a change with relatively low risk, since I'm just adding
a support for different system, and not changing the usual flow at all.
3. If everything will work correctly, there's at least one big organization
that would be using Ambari, I think it'll be good for the project.

Thanks,
Elazar Leibovich

Re: Support OS without packaging system

[Siddharth Wagle <sw...@hortonworks.com>]

Hi Ealzar,

I can across this link while searching for "puppet writing custom package
providers", again my knowledge regarding this topic is quite limited.
http://projects.puppetlabs.com/projects/1/wiki/Development_Provider_Development

Here is a link to the open source users groups,
https://groups.google.com/forum/#!forum/puppet-users
It might be worthwhile to explore the community forums to get some insight.

Best Regards,
Sid



On Mon, Jul 8, 2013 at 5:49 AM, Elazar Leibovich <el...@gmail.com> wrote:

> Hi Siddharth,
>
> Thanks for your answer!
>
> Can you refer me to a documentation or to a similar piece of code
> examplifying the usage of puppet Resource providers? I haven't found
> something like that in the Ambari Design link you provided.
>
> Thanks again!
>
>
> On Sun, Jul 7, 2013 at 8:40 PM, Siddharth Wagle <sw...@hortonworks.com>wrote:
>
>> Hi Elazar,
>>
>> Thank you for looking into Ambari. Following is the link to the Ambari
>> wiki with information regarding Ambari architecture that you might find
>> useful,
>>
>> https://cwiki.apache.org/confluence/display/AMBARI/Ambari+Design
>>
>> Amabri agents that heartebat with the ambari server are written in python
>> and delegate the responsibility of installing packages to puppet scripts.
>> The agent architecture utilizes puppet in a sandboxed fashion (limited
>> context and responsibility), in order to enable the package management to
>> be mutable.
>> On a side not, it is actually possible to write a custom Provider
>> implementation for puppet and hook it up with puppet Resource provider, I
>> have not looked into the details of doing this just know that it is
>> supported.
>>
>> Best Regards,
>> Sid
>>
>>
>> On Sat, Jul 6, 2013 at 5:11 PM, Elazar Leibovich <el...@gmail.com>wrote:
>>
>>> Forwarding to ambari-user, since I suspect ambari-dev is primarily used
>>> for JIRA.
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Elazar Leibovich <el...@gmail.com>
>>> Date: Fri, Jul 5, 2013 at 4:11 PM
>>> Subject: Support OS without packaging system
>>> To: ambari-dev@incubator.apache.org
>>>
>>>
>>> Hi,
>>> I'm currently consider deploying Ambari on home brew hardened Operating
>>> Systems which does not feature package managements. You cannot use anything
>>> like RPM, deb packages etc.
>>>
>>> The way I was thinking of handling it is:
>>>
>>> 1. compile all the required package to a certain shared directory:
>>>
>>> //fileserver/opt/{hbase,hadoop,oozie}
>>>
>>> 2. Define fictive package manager for Ambari that would simply copy the
>>> files to a node instead of triggering actual installtion script.
>>>
>>> Ambari will then act as usual and will try to install those packages
>>> using my fictive package manager.
>>>
>>> If the base OS installation has all the dependencies, Ambari should
>>> still work.
>>>
>>> 1. Can that work? I'm don't know too much about Ambari's architecture,
>>> besides a few slides decks I found.
>>> 2. Is that interesting as a JIRA? I think that this flexibility (work on
>>> any linux system at all, if you can ./configure && make hadoop on it -
>>> ambari will take care if that) is beneficial for more people than just
>>> myself. If it is, I'd like to coordinate my efforts with the project, and
>>> to submit the code eventually.
>>> Note that this is a change with relatively low risk, since I'm just
>>> adding a support for different system, and not changing the usual flow at
>>> all.
>>> 3. If everything will work correctly, there's at least one big
>>> organization that would be using Ambari, I think it'll be good for the
>>> project.
>>>
>>> Thanks,
>>> Elazar Leibovich
>>>
>>>
>>
>

Re: Support OS without packaging system

[Elazar Leibovich <el...@gmail.com>]

Hi Siddharth,

Thanks for your answer!

Can you refer me to a documentation or to a similar piece of code
examplifying the usage of puppet Resource providers? I haven't found
something like that in the Ambari Design link you provided.

Thanks again!


On Sun, Jul 7, 2013 at 8:40 PM, Siddharth Wagle <sw...@hortonworks.com>wrote:

> Hi Elazar,
>
> Thank you for looking into Ambari. Following is the link to the Ambari
> wiki with information regarding Ambari architecture that you might find
> useful,
>
> https://cwiki.apache.org/confluence/display/AMBARI/Ambari+Design
>
> Amabri agents that heartebat with the ambari server are written in python
> and delegate the responsibility of installing packages to puppet scripts.
> The agent architecture utilizes puppet in a sandboxed fashion (limited
> context and responsibility), in order to enable the package management to
> be mutable.
> On a side not, it is actually possible to write a custom Provider
> implementation for puppet and hook it up with puppet Resource provider, I
> have not looked into the details of doing this just know that it is
> supported.
>
> Best Regards,
> Sid
>
>
> On Sat, Jul 6, 2013 at 5:11 PM, Elazar Leibovich <el...@gmail.com>wrote:
>
>> Forwarding to ambari-user, since I suspect ambari-dev is primarily used
>> for JIRA.
>>
>>
>> ---------- Forwarded message ----------
>> From: Elazar Leibovich <el...@gmail.com>
>> Date: Fri, Jul 5, 2013 at 4:11 PM
>> Subject: Support OS without packaging system
>> To: ambari-dev@incubator.apache.org
>>
>>
>> Hi,
>> I'm currently consider deploying Ambari on home brew hardened Operating
>> Systems which does not feature package managements. You cannot use anything
>> like RPM, deb packages etc.
>>
>> The way I was thinking of handling it is:
>>
>> 1. compile all the required package to a certain shared directory:
>>
>> //fileserver/opt/{hbase,hadoop,oozie}
>>
>> 2. Define fictive package manager for Ambari that would simply copy the
>> files to a node instead of triggering actual installtion script.
>>
>> Ambari will then act as usual and will try to install those packages
>> using my fictive package manager.
>>
>> If the base OS installation has all the dependencies, Ambari should still
>> work.
>>
>> 1. Can that work? I'm don't know too much about Ambari's architecture,
>> besides a few slides decks I found.
>> 2. Is that interesting as a JIRA? I think that this flexibility (work on
>> any linux system at all, if you can ./configure && make hadoop on it -
>> ambari will take care if that) is beneficial for more people than just
>> myself. If it is, I'd like to coordinate my efforts with the project, and
>> to submit the code eventually.
>> Note that this is a change with relatively low risk, since I'm just
>> adding a support for different system, and not changing the usual flow at
>> all.
>> 3. If everything will work correctly, there's at least one big
>> organization that would be using Ambari, I think it'll be good for the
>> project.
>>
>> Thanks,
>> Elazar Leibovich
>>
>>
>

Re: Support OS without packaging system

[Siddharth Wagle <sw...@hortonworks.com>]

Hi Elazar,

Thank you for looking into Ambari. Following is the link to the Ambari wiki
with information regarding Ambari architecture that you might find useful,

https://cwiki.apache.org/confluence/display/AMBARI/Ambari+Design

Amabri agents that heartebat with the ambari server are written in python
and delegate the responsibility of installing packages to puppet scripts.
The agent architecture utilizes puppet in a sandboxed fashion (limited
context and responsibility), in order to enable the package management to
be mutable.
On a side not, it is actually possible to write a custom Provider
implementation for puppet and hook it up with puppet Resource provider, I
have not looked into the details of doing this just know that it is
supported.

Best Regards,
Sid


On Sat, Jul 6, 2013 at 5:11 PM, Elazar Leibovich <el...@gmail.com> wrote:

> Forwarding to ambari-user, since I suspect ambari-dev is primarily used
> for JIRA.
>
>
> ---------- Forwarded message ----------
> From: Elazar Leibovich <el...@gmail.com>
> Date: Fri, Jul 5, 2013 at 4:11 PM
> Subject: Support OS without packaging system
> To: ambari-dev@incubator.apache.org
>
>
> Hi,
> I'm currently consider deploying Ambari on home brew hardened Operating
> Systems which does not feature package managements. You cannot use anything
> like RPM, deb packages etc.
>
> The way I was thinking of handling it is:
>
> 1. compile all the required package to a certain shared directory:
>
> //fileserver/opt/{hbase,hadoop,oozie}
>
> 2. Define fictive package manager for Ambari that would simply copy the
> files to a node instead of triggering actual installtion script.
>
> Ambari will then act as usual and will try to install those packages using
> my fictive package manager.
>
> If the base OS installation has all the dependencies, Ambari should still
> work.
>
> 1. Can that work? I'm don't know too much about Ambari's architecture,
> besides a few slides decks I found.
> 2. Is that interesting as a JIRA? I think that this flexibility (work on
> any linux system at all, if you can ./configure && make hadoop on it -
> ambari will take care if that) is beneficial for more people than just
> myself. If it is, I'd like to coordinate my efforts with the project, and
> to submit the code eventually.
> Note that this is a change with relatively low risk, since I'm just adding
> a support for different system, and not changing the usual flow at all.
> 3. If everything will work correctly, there's at least one big
> organization that would be using Ambari, I think it'll be good for the
> project.
>
> Thanks,
> Elazar Leibovich
>
>