[ 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)