[ 
https://issues.apache.org/jira/browse/AMBARI-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205681#comment-14205681
 ] 

Newton Alex commented on AMBARI-8225:
-------------------------------------

Thanks [~sposetti]

1) When showing sync status on the services summary area, if a subset of hosts 
are out of sync, what will it display? Think a red icon with "X of Y hosts out 
of sync" 
Newton> Sounds like a good idea. Was initially thinking about just a yes/no 
like solution.

2) I think that text would link to hosts page so users can find the out of sync 
hosts
Newton> Thats correct. I briefly mentioned about it in the Web UI section. The 
new page will have the details provided in the "JSON structures" section of the 
doc

3) Would need to think about how this is shown and filtered per host on the 
Hosts page so  a user can find host(s) that have out of sync config status
Newton> Thanks, I missed this one. I'll add a section for the Hosts screen too. 
I'm thinking of this one to be similar to the Service screen summary.  When the 
user clicks on the link, it could take them to a details page that only shows 
the differences for that host.

4) And on the Host details page, show sync icon info with each component (i.e. 
my DataNode component might be out of sync but not the NodeManager on a given 
host)
Newton> In the current design proposed, the JSON structure deals at the level 
of files. So in order to implement this requirement, we will have to map the 
config files back to components. I guess this can be done as an improvement?

5) Also will need a phase 3: on save config, if configs are out of sync, how 
will the flow go. Should prompt user to proceed + overwrite or merge?
Newton> Sure, will add a phase 3 to the doc. Prompting user to proceed with 
overwrite should be easy and straight forward but auto-merging might be a bit 
complicated. For example, if the user has done similar changes on a bunch of 
nodes, we will have to find all nodes with similar changes, group them into the 
same config groups and deploy them. Unless, we do some more intelligent 
diff'ing at the agent side, it might be difficult. 


> Configuration Monitor - Ability to indicate if the configurations have been 
> changed manually outside Ambari
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: AMBARI-8225
>                 URL: https://issues.apache.org/jira/browse/AMBARI-8225
>             Project: Ambari
>          Issue Type: Improvement
>            Reporter: Newton Alex
>            Assignee: Newton Alex
>             Fix For: 2.0.0
>
>         Attachments: AmbariConfigurationMonitor-ProposalAndDesign.pdf
>
>
> Users who are familiar with Hadoop configurations (or any other service) tend 
> to change the configuration files directly on the cluster nodes without using 
> Ambari. It is quicker and convenient for them to just directly change the 
> files and restart the service on a particular node rather than going through 
> Ambari.  The downside of this is that Ambari doesn’t recognize these changes 
> and overwrites them during cluster upgrades or while reconfiguring services. 
> Ambari should not be preventing the users from making changes themselves, as 
> it would be too restrictive. On the other hand, it would greatly benefit 
> Ambari, if it is aware of the manual configuration changes on the nodes as it 
> can then alert the users of the changes before doing any of its own.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to