You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Jonathan Hurley (JIRA)" <ji...@apache.org> on 2018/08/08 15:28:00 UTC
[jira] [Resolved] (AMBARI-24410) Remove conf-select Tool From
Ambari Framework
[ 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)