ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmytro Sen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-22095) Make hooks stack agnostic
Date Tue, 03 Oct 2017 12:55:02 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-22095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dmytro Sen updated AMBARI-22095:
--------------------------------
    Resolution: Fixed
        Status: Resolved  (was: Patch Available)

> Make hooks stack agnostic
> -------------------------
>
>                 Key: AMBARI-22095
>                 URL: https://issues.apache.org/jira/browse/AMBARI-22095
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 3.0.0
>            Reporter: Dmytro Sen
>            Assignee: Dmytro Sen
>            Priority: Critical
>             Fix For: 3.0.0
>
>         Attachments: AMBARI-22095.patch
>
>
> - At present hooks are located inside stacks 
> - For all HDP stacks, we use https://github.com/apache/ambari/tree/trunk/ambari-server/src/main/resources/stacks/HDP/2.0.6/hooks
> - Similarly for all HDF stacks, we use https://github.com/apache/ambari/tree/trunk/contrib/management-packs/hdf-ambari-mpack/src/main/resources/stacks/HDF/2.0/hooks
> - Any time the HDP hooks are updated, the changes have to be ported to HDF branch. This
is a maintenance overhead
> - In Ambari 3.0 when we move to mpack based operations model, this will be a maint nightmare.

> *Requirements*
> # We should look into making hooks stack agnostic. 
> # Hooks should be moved from resources/stacks/HDP/2.0.6/hooks to resources/stack-hooks
> # Hooks should be entirely config driven
> # There should be no HDP or HDF specific logic in the hooks (hdp-select, conf-select,
hdf-select, hdfconf-select) 
> # There should be no service specific logic in the hooks (for example: hardcoded service
user to service group mapping etc. this should be stack driven see: AMBARI-20034).
> # Any service specific logic that doesn't make sense should be removed and refactored
into respective service definitions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message