[ 
https://issues.apache.org/jira/browse/AMBARI-24698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei-Chiu Chuang updated AMBARI-24698:
-------------------------------------
    Fix Version/s: 3.1.0
                       (was: 3.0.0)

> Use service instance level configs instead of cluster level configs
> -------------------------------------------------------------------
>
>                 Key: AMBARI-24698
>                 URL: https://issues.apache.org/jira/browse/AMBARI-24698
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 3.0.0
>            Reporter: Balázs Bence Sári
>            Assignee: Balázs Bence Sári
>            Priority: Critical
>             Fix For: 3.1.0
>
>
> *Service instance level* configs are the ones that are associated with a 
> *serviceId* while *cluster level* configurations are those which are not. 
> Historically all configs were *cluster level* as there were no service 
> instances. In the future all configs will be service instance level with the 
> temporary exception of _cluster-env_.
> Ambari code uses *Cluster.getConfig(String configType)* method almost 
> everywhere which returns *cluster level* configurations only. Luckily, all 
> configs on *service instance level* are also stored as *cluster level* 
> configs in memory in *ClusterImpl*, this is why it has worked so far.
> Double-storing *service instance level* configs on the *cluster level* will 
> not work once multiple service instances will be enabled as ambiguity would 
> occur.
> The *Cluster.getConfig(String configType)* method should be eliminated and 
> the *Cluster.getConfig(String configType, Optional<Long> serviceId)* method 
> used instead. *serviceId* should be given in all cases except when not 
> applicable (_cluster-env_)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to