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

["Jonathan Hurley (JIRA)" <ji...@apache.org>]

Jonathan Hurley created AMBARI-24410:
----------------------------------------

             Summary: 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
             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)