Vishal Suvagia updated AMBARI-19524:
    Attachment: AMBARI-19524_trunk.patch

> Use stack-level Atlas conf directory instead of hard-coded /etc/atlas/conf 
> path
> -------------------------------------------------------------------------------
>                 Key: AMBARI-19524
>                 URL: https://issues.apache.org/jira/browse/AMBARI-19524
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.4.0
>         Environment: All
>            Reporter: Vishal Suvagia
>            Assignee: Vishal Suvagia
>             Fix For: 2.5.0
>         Attachments: AMBARI-19524_branch-2.5.patch, AMBARI-19524_trunk.patch
> This is a bug that should have been fixed in Ambari 2.4 but showed up too 
> late in the release and has repercussions to test it.
> Basically, status_params.py for Atlas service in Ambari sets
> {code}
> conf_dir = os.environ['METADATA_CONF'] if 'METADATA_CONF' in os.environ else 
> '/etc/atlas/conf'
> {code}
> This is technically incorrect since /etc/atlas/conf is a symlink to 
> /usr/hdp/current/atlas-client/conf, which is then a symlink to 
> /etc/atlas/$some_version/0
> During Rolling Upgrade,
> 1. Atlas Server is stopped, new configs are written to 
> /etc/atlas/$new_version/0, then symlink is changed so that 
> /usr/hdp/current/atlas-server points to new version, and Atlas Server is 
> started
> At this point, /etc/atlas/conf -> /usr/hdp/current/atlas-client/conf (which 
> is still using the old version) since the client has not yet been updated.
> 2. Atlas Client has new configs written to /etc/atlas/$new_version/0, then 
> symlink is changed so that /usr/hdp/current/atlas-client points to new version
> Basically, we need to look at the usages of conf_dir and make sure it is 
> correct during all scenarios.

This message was sent by Atlassian JIRA

Reply via email to