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

Robert Nettleton commented on AMBARI-14555:
-------------------------------------------

h2. Proposal

The existing abstractions for "provision_action" defined in AMBARI-14283 should 
be re-used and extended, in order to support a user marking individual 
components with a specific provisioning action.  In the current implementation, 
the two provisioning actions are "INSTALL_ONLY" and "INSTALL_AND_START".  

This new feature should support an extension to allow users to specify a 
provision action on an individual component.  This would be considered an 
override to the cluster-wide setting, if that setting is used.  Otherwise, it 
would override the default “INSTALL_AND_START” action, which seems to be the 
most straightforward, and is the default for the cluster-wide setting anyway. 

Here’s an example host group definition from a Blueprint using the current 
syntax:

{code}
{
      "name" : "host_group_2",
      "configurations" : [ ],
      "components" : [
        {
          "name" : "ZOOKEEPER_SERVER"
        },
        {
          "name" : "HISTORYSERVER"
        },
        {
          "name" : "APP_TIMELINE_SERVER"
        },
       ...
      ],
      "cardinality" : "1"
    },”
{code}

I propose that we allow the setting of the “provision_action” at the component 
level as well, so that the syntax would look something like:

{code}
{
      "name" : "host_group_2",
      "configurations" : [ ],
      "components" : [
        {
          "name" : "ZOOKEEPER_SERVER"
        },
        {
          "name" : "HISTORYSERVER"
        },
        {
          "name" : “APP_TIMELINE_SERVER”,
          “provision_action” : “INSTALL_ONLY"
        },
       ...
      ],
      "cardinality" : "1"
    },”
{code}

The default provision_action for components would be the same as the 
cluster-wide default, which is “INSTALL_AND_START”.  In the example snippet 
above, I’ve marked the “APP_TIMELINE_SERVER” as a component that should only be 
installed.

I believe that this might be the most straightforward way to implement this, 
and may be the least intrusive with respect to existing Blueprint syntax. 

This work would likely involve some minor changes to the Blueprint Database 
tables, and so would also require some upgrade-related work as well,  




> Add Blueprints support for starting only a subset of components within a host 
> group
> -----------------------------------------------------------------------------------
>
>                 Key: AMBARI-14555
>                 URL: https://issues.apache.org/jira/browse/AMBARI-14555
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.1.0
>            Reporter: Robert Nettleton
>            Assignee: Robert Nettleton
>            Priority: Critical
>             Fix For: 2.2.1
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> Currently, the Blueprint deployment process for a cluster will always take a 
> component through the "INSTALL" and "START" phases.  
> While this is the correct default behavior for most cluster deployments, 
> there are cases where a user would like more fine-grained control over when 
> certain components are started. 
> There is currently some support for this, implemented by AMBARI-14283, 
> however this support is currently cluster-wide, so that START commands can be 
> disabled for the entire cluster, but not on a component-basis.
> I propose that we extend the work in AMBARI-14283 to also allow a Blueprint 
> to specify that certain components may only use the "INSTALL" phase, and skip 
> the "START" phase.  
> This work will require some minor additions to the Blueprint syntax, that 
> I'll publish in this proposal.  
> The Blueprint syntax should support marking each comopnent as having a 
> "provision_action" that can override the default "INSTALL_AND_START" 
> behavior.  



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

Reply via email to