[
https://issues.apache.org/jira/browse/AMBARI-14690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105535#comment-15105535
]
Vinod Kumar Vavilapalli commented on AMBARI-14690:
--------------------------------------------------
Thinking about it holistically, we have two options. A configuration property
in agent.ini can either determine
# which file to read resource requirements from (let’s call it resource-limits
file). Today the agent reads the values from a hard-coded resource-limits file
'/proc/meminfo'
# read the actual values specifying how much memory (and in future cpu etc) is
available to Ambari agent for its services.
The current patch does (2).
For heterogeneous cluster, there is a potential for different sized VMs /
containers on different hosts, *it is desirable to have the configuration
(final values) be specific to a machine and not a constant in the entire
cluster*.
Having them values read from configuration will *force* a higher layer to
generate these values per machine (a) *into a ambari specific file (agent ini)*
and (b) in *a format specific to Ambari*.
Instead I think we should support (may be in addition to what the patch does),
option (1) to be able to make the resource-limits file configurable. That way
- higher layers can write limits to a file (located within the container) that
they desire, and simply configure Ambari to read values from that file.
- Of course, this still doesn't solve the format problem - I think we should
model this limits fils close to /proc/meminfo so that there is some semblence
of communicating through a commonly known format.
Thoughts?
> Configurable system resource values for ambari-agent
> ----------------------------------------------------
>
> Key: AMBARI-14690
> URL: https://issues.apache.org/jira/browse/AMBARI-14690
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-agent
> Affects Versions: 2.4.0
> Reporter: Olivér Szabó
> Assignee: Olivér Szabó
> Fix For: 2.4.0
>
> Attachments: AMBARI-14690.patch
>
>
> When an ambari agent starts, host system details are registered into ambari
> server database. These values are calculated by ambari-agents based on
> different files on the hosts (e.g : /proc/meminfo).
> In some cases it isn't a correct behavior: If ambari-agent is in a
> docker-container, it will see the same memory/cpu details. (stack advisor
> also uses these values, its possible stack advisor can recommend a too high
> memory value for some services)
> Solution: Configurable system resources in ambari-agent.ini (if a value does
> not exist or empty, it will use the default behavior)
> {code:java}
> [system_resource]
> processorcount=2
> physicalprocessorcount=2
> memorysize=50000
> memoryfree=50000
> memorytotal=100000
> swapsize=20
> swapfree=20
> ...
> {code}
> In ambari-agent Facter.py set these values, all of the factor info values can
> be redefined in ambari-agent.ini file.
> That means ambari is not responsible to gather these values from the system.
> - use case:
> During 'docker run' , if there is a script which calls 'ambari-agent start',
> before that, some of the memory values can be replaced/inserted into the
> ambari-agent.ini file in that script. (e.g. the user knows that, 4
> ambari-agent containers will be started, with the same services, so the real
> memory needs to be devided by 4 etc.)
> Facter.py is called during ambari-agent start, so if the values will be
> modified later, ambari-agent needs to be restarted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
