[jira] [Comment Edited] (AMBARI-10385) On nodes that already have packages pre-installed, Ambari should skip install altogether

["Sumit Mohanty (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMBARI-10385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14524085#comment-14524085 ] 

Sumit Mohanty edited comment on AMBARI-10385 at 5/1/15 10:06 PM:
-----------------------------------------------------------------

As discussed above, sys prep can be broadly divided into two categories

1. Pre-installing packages (e.g. use VM images that already have the packages pre-installed)
2. HCFS or shared storage seeding (copy files and folders to HCFS prior to bringing up the cluster)
3. Host preparation (a variant of package installation except it involves creating local folders, local files, local groups, users etc.)

Currently ambari properties allow {{packages.pre.installed=true/false}} which is being used to indicate everything.

Instead, we could use distinct properties for each types of system readiness.

* packages.pre.installed
* hcfs.pre.provisioned
* host.pre.provisioned

Depending on what is true/false, the Service Definition scripts in the Stack Definition can choose to skip various operations.

The advantage of splitting into distinct types of system readiness is that users can choose to select what works for their system. Its is more common to just have packages pre-installed. {{hcfs.pre.provisioned}} depends if an externally provisioned HCFS is used or not. Host pre-provisioning depends on the VM image as well but its a much granular level of preparation than just installing packages.


was (Author: sumitmohanty):
As discussed above, sys prep can be broadly divided into two categories

1. Pre-installing packages (e.g. use VM images that already have the packages pre-installed)
2. HCFS or shared storage seeding (copy files and folders to HCFS prior to bringing up the cluster)
3. Host preparation (a variant of package installation except it involves creating local folders, local files, local groups, users etc.)

Currently ambari properties allow {{packages.pre.installed=true/false}}

Instead, we could use distinct properties for each types of system readiness.

* packages.pre.installed
* hcfs.pre.provisioned
* host.prep.provisioned

Depending on what is true/false, the Service Definition scripts in the Stack Definition can choose to skip various operations.

The advantage of splitting into distinct types of system readiness is that users can choose to select what works for their system. Its is more common to just have packages pre-installed. {{hcfs.pre.provisioned}} depends if an externally provisioned HCFS is used or not. Host pre-provisioning depends on the VM image as well but its a much granular level of preparation than just installing packages.

> On nodes that already have packages pre-installed, Ambari should skip install altogether
> ----------------------------------------------------------------------------------------
>
>                 Key: AMBARI-10385
>                 URL: https://issues.apache.org/jira/browse/AMBARI-10385
>             Project: Ambari
>          Issue Type: Improvement
>          Components: ambari-agent, ambari-server
>            Reporter: Sumit Mohanty
>             Fix For: 2.2.0
>
>
> Especially in hosted deployment settings, its beneficial to create VM images with all packages pre-installed. When Ambari is used to deploy hadoop on such hosts, INSTALL operation should not be needed. The way INSTALL is implemented by Ambari today there are potentially three ways to skip installation.
> 1. *Skip installation commands*
> In this approach, Ambari Server should not issue install commands and silently move all components to {{INSTALLED}} state. This solution is ideal as it will eliminate command creation, execution etc. This approach will require:
> ** Modification to Ambari Server internal state machine to handle transparent transition through INSTALL phase.
> ** Introduce explicit CONFIGURE commands to configure the clients
> ** Ensure that none of the stack definitions do anything more than installing packages
> As a work-around, agents can be made to short-circuit INSTALL calls. This is if Ambari Server internal state machine needs to issue INSTALL command. The pre-conditions of CONFIGURE command a a clean implementation of install() functions still remain.
> 2. *Skip install_package() calls*
> In this approach, Ambari Server does not change but a configuration allows Agents to skip doing any work when install_package() is called.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)