The original design is using a hierarchical design to populate
configuration. We probably should use a flat structure at the global
level to make substation easy for values across multiple components.
For example, NameNode hostname can be used in core-site.xml, and name
node url can be used in hbase-site.xml.
The previous design looks like:
{
"stack"
"parent"
"repositories": [],
"configuration": {
"hadoop-env": {
},
"core-site": {
}
},
"components": {
}
"roles": {
}
}
Configuration section, "core-site" values are not re-usable in
"hbase-site" due to hierarchical design. It would be best to have
this expressed as:
"blueprint": {
"hadoop.namenode.host": "host.example.com",
"hadoop.namenode.port": "9000",
"hadoop.namenode.url" :
"hdfs://${hadoop.namenode.host}:${hadoop.namenode.port}"
}
When key/values pairs are applied to templates, it will construct the
proper information from the flat list of key value pairs.
The construction of the master cluster configuration can be simplified
like this:
"cluster": {
"packages": { ... },
"nodes": { ... },
"blueprint": { ... }
}
Package List looks like this:
"Packages" : {
"namenode": [ url1, url2 ],
"datanode": [ url1, url2 ],
}
Node List looks like this:
"Nodes" : {
"namenode" : [ "hostname1", "hostname2" ],
"datanode" : [ ... ]
}
"blueprint": {
"hadoop.namenode.host": "external.example.com",
"hadoop.namenode.port": "9000",
"hadoop.namenode.url" :
"hdfs://${hadoop.namenode.host}:${hadoop.namenode.port}"
}
Because there is a default blueprint, therefore, users usually don't
need to specify the default values such as "hadoop.namenode.url" or
"hadoop.namenode.port". This will keep the required config key/value
pairs to the minimum. Hope this is useful.
regards,
Eric
On Wed, Jul 11, 2012 at 12:04 PM, Mahadev Konar <[email protected]> wrote:
> Thanks Devaraj.
>
> mahadev
>
>
> On Tue, Jul 10, 2012 at 11:27 AM, Devaraj Das <[email protected]> wrote:
>> The attachment didn't go thru. Just checkout the trunk rev 1176156 [svn co
>> http://svn.apache.org/repos/asf/incubator/ambari@1176156] and then look at
>> trunk/examples directory..
>>
>> On Jul 9, 2012, at 10:39 PM, Devaraj Das wrote:
>>
>>> For the uninitiated, here is what I remember about blueprint:
>>> Blueprint was a concept for describing cluster configurations (including
>>> repositories, stack definitions and individual component configurations).
>>> Blueprints would be versioned, and, one could inherit from a blueprint,
>>> etc. to define/override properties. For example, Ambari could ship with a
>>> default blueprint which defines config values/properties that are
>>> appropriate to the best of the Ambari developer's knowledge. In the
>>> production site, one could inherit that blueprint and only override certain
>>> properties with site specific values.
>>> Attached a sample blueprint json file that inherits from another blueprint,
>>> and selectively overrides a property in the namenode config..
>>>
>>> <blueprint.json>
>>>
>>> On Jul 9, 2012, at 11:38 AM, Eric Yang wrote:
>>>
>>>> Hi all,
>>>>
>>>> The original cluster blue print has been removed from Ambari website,
>>>> and the cluster blue print concept has been removed from current
>>>> Ambari code base. It would be great to have a specification of master
>>>> configuration for construct or clone other clusters. This could be
>>>> offered as open specification for community to implement or enhance
>>>> the deployment execution engine. What does the community think about
>>>> this idea?
>>>>
>>>> regards,
>>>> Eric
>>>
>>
