[
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)
