[
https://issues.apache.org/jira/browse/AMBARI-24410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley resolved AMBARI-24410.
--------------------------------------
Resolution: Fixed
> 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
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 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)
