[jira] [Updated] (AMBARI-24410) Remove conf-select Tool From Ambari Framework

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot updated AMBARI-24410:
------------------------------------
    Labels: pull-request-available  (was: )

> Remove conf-select Tool From Ambari Framework
> ---------------------------------------------
>
>                 Key: AMBARI-24410
>                 URL: https://issues.apache.org/jira/browse/AMBARI-24410
>             Project: Ambari
>          Issue Type: Task
>    Affects Versions: 3.0.0
>            Reporter: Jonathan Hurley
>            Assignee: Jonathan Hurley
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 3.0.0
>
>
> Mpack do not provide a replacement for {{conf-select}}, a utility which was previously used to provide parallel configurations so that 2 components (such as NameNode and DataNode) could use different configurations while in an upgrade. It ensured that breaking configuration changes stay isolated in their respective directories:
> {noformat}
> /usr/hdp/2.5.0.0/zookeeper/conf -> /etc/zookeeper/2.5.0.0/0
> /usr/hdp/2.6.0.0/zookeeper/conf -> /etc/zookeeper/2.6.0.0/0
> /usr/hdp/current/zookeeper-server -> /usr/hdp/2.5.0.0/zookeeper
> {noformat}
>  
> When {{hdp-select}} was used to change the {{current}} symlink, the {{conf}} directories would “automatically” switch over. This allowed a complete separation of configurations and the ability to have parallel configurations on disk. 
>  
> If Ambari is managing your configurations, then we know what to write and when to write it
> Even in cases where breaking configuration changes were made, since Ambari kept both old and new configurations in our database, a downgrade would always write out the correct configurations for the version being downgraded to
>  
> Let’s fast-forward to Ambari 3.0 and mpacks … The current structure does not allow for multiple configurations for a given service inside of a service group:
>  
> {noformat}
> instances
> └── hdpcore
>     ├── default -> /usr/hwx/instances/hdpcore/HDPCORE
>     └── HDPCORE
>         └── default
>             ├── zookeeper
>             │   └── zookeeper_server
>             │       └── ZOOKEEPER
>             │           ├── conf
>             │           │   ├── configuration.xsl
>             │           │   ├── log4j.properties
>             │           │   ├── zoo.cfg
>             │           │   ├── zookeeper-env.sh
>             │           │   └── zoo_sample.cfg
> {noformat} 
>  
> Instead of symlinks scoped by a version, each service instance has a regular conf directory. A few points here:
> - Since configurations are now at the component instance level, DataNode and NameNode won't share configs during an upgrade.
> - For Ambari managed configurations, this should be fine since we keep track of old and new versions. So, even on a downgrade, we’d know to write the correct values in here
> - If Ambari is not managing a configuration file, say foo-site.xml, then:
> -- We don’t have to worry about copying it from one versioned directory to another. This seeding process is necessary in Ambari 2.x, but wouldn’t be here
> -- If there was a change to the structure of a file which Ambari does not manage, then we have a problem on downgrade as Ambari wouldn’t know to replace anything. I suppose it’s the same issue on upgrade too since Ambari wouldn’t know to change the file either.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)