Return-Path: X-Original-To: apmail-ambari-user-archive@www.apache.org Delivered-To: apmail-ambari-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7CED911076 for ; Fri, 5 Sep 2014 13:54:35 +0000 (UTC) Received: (qmail 25558 invoked by uid 500); 5 Sep 2014 13:54:35 -0000 Delivered-To: apmail-ambari-user-archive@ambari.apache.org Received: (qmail 25530 invoked by uid 500); 5 Sep 2014 13:54:35 -0000 Mailing-List: contact user-help@ambari.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ambari.apache.org Delivered-To: mailing list user@ambari.apache.org Received: (qmail 25520 invoked by uid 99); 5 Sep 2014 13:54:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Sep 2014 13:54:35 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of smohanty@hortonworks.com designates 209.85.160.180 as permitted sender) Received: from [209.85.160.180] (HELO mail-yk0-f180.google.com) (209.85.160.180) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Sep 2014 13:54:29 +0000 Received: by mail-yk0-f180.google.com with SMTP id 9so6971114ykp.39 for ; Fri, 05 Sep 2014 06:54:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=H3DOBuueldccU/FL++4ahcsVVky6CJ6U9chjvBITkT0=; b=APJ7l8mNWN5UAPCXN4PJadbrVFxJrSMohx0fHd5x9STW0jLCk6yeFULQkmxd5MVteb Ex/OldSQR7YEdFFE4kFs1I0OKremKGnxmM0a32erFTXksMh/5dN0NYSrZCQPFKJWzmhI uokHtuXsmUuiRJlLIAq/VDkxlvl3fSZ/y0BaurQH+MWyIDV4Pw4giWWXmJZ87ldD6z1Z sLt+q0pVSd1WV1hqc82/DtBPlr2g7GCwAHBps1S8CUOHppVvweOW5wiV33iLSxfJZ4GM dU9wts9UfFfgdBVG4K2PDzcQ9Bj6hptRTQSh4x5CG6CIAhQGn68iiZlps3cBGtT5fXRU Mk2A== X-Gm-Message-State: ALoCoQlO45kZYWf9ibkpxSHLTWuNvrVCpn4GvN3ASIXBBVWUsO/PwYtB1pSqqgAhAVT/eu9kNDC6PqCuEBf+d/zrvELusXEEvmOfPgBDGLyZb9/cgzi9ICw= MIME-Version: 1.0 X-Received: by 10.236.147.34 with SMTP id s22mr2047807yhj.172.1409925248259; Fri, 05 Sep 2014 06:54:08 -0700 (PDT) Received: by 10.170.146.134 with HTTP; Fri, 5 Sep 2014 06:54:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Sep 2014 06:54:08 -0700 Message-ID: Subject: Re: question on [STACK]/[SERVICE]/metainfo.xml inheritance rules From: Sumit Mohanty To: "user@ambari.apache.org" Content-Type: multipart/alternative; boundary=20cf303a337d952b11050251cdf8 X-Virus-Checked: Checked by ClamAV on apache.org --20cf303a337d952b11050251cdf8 Content-Type: text/plain; charset=UTF-8 Could we save these as FAQs on the Ambari wiki? -Sumit On Thu, Sep 4, 2014 at 5:53 PM, Siddharth Wagle wrote: > Hi Alex, > > Replies inline. > > 1. If a component exists in the parent stack and is defined again in the > child stack with just a few attributes, are these values just to override > the parent's values or the whole component definition is replaced. > > We go property by property and merge them from parent to child. So if you > remove a category for example from the child it will be inherited from > parent, that goes for pretty much all properties. > So, the question is how do we tackle existence of a property in both > parent and child. Here, most of the decision still follow same paradigm as > take the child value instead of parent and every property in parent, not > explicitly deleted from child using a marker like tag, is > included in the merge. > > - For config-dependencies, we take all or nothing approach, if this > property exists in child use it and all of its children else take it from > parent. > - The custom commands are merged based on names, such that merged > definition is a union of commands with child commands with same name > overriding those fro parent. > - Cardinality is overwritten by a child or take from the parent if child > has not provided one. > > You could look at this method for more details: > org.apache.ambari.server.api.util.StackExtensionHelper#mergeServices > > 2. If a component is missing in the new definition but is present in the > parent, does it get inherited ? > > Generally yes. > > 3. Configuration dependencies for the service -- are they overwritten or > merged ? > > Overwritten. > > 4. What about other elements in metainfo.xml -- which rules apply ? > > Answered in 1. > > -Sid > > > > > > > On Thu, Sep 4, 2014 at 5:02 PM, Alexander Denissov > wrote: > >> I am trying to understand the inheritance rules that govern services >> metainfo.xml file contents. I looked at >> https://issues.apache.org/jira/browse/AMBARI-2819 but it didn't answer >> the following: >> >> 1. If a component exists in the parent stack and is defined again in the >> child stack with just a few attributes, are these values just to override >> the parent's values or the whole component definition is replaced. >> >> Example: HDP-2.1 YARN/metainfo.xml contains definition of RESOURCEMANAGER >> with just 4 attributes, out of which only the value for "cardinality" is >> different one in HDP-2.0.6 definition. But 2.0.6 definition also has a lot >> more attributes (such as custom commands) that are not mentioned in 2.1. >> Will these "missing" attributes be inherited by 2.1 stack ? If yes, why >> other attributes (category and configuration-dependencies) are defined >> again with the same values instead of being inherited ? >> >> 2. If a component is missing in the new definition but is present in the >> parent, does it get inherited ? >> >> 3. Configuration dependencies for the service -- are they overwritten or >> merged ? >> >> Example: HDP-2.1 YARN/metainfo.xml contains >> element with 4 , where as in HDP-2.0.6 the same element has >> 5 (extra line is mapred-site). So will mapred >> -site be inherited and present in 2.1 definition or was >> this the way to get rid of this specific line for the new stack ? >> >> 4. What about other elements in metainfo.xml -- which rules apply ? >> >> -- >> Thanks, >> Alex. >> > > > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity > to which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. --20cf303a337d952b11050251cdf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Could we save these as FAQs on the Ambari wiki?

-Sumit


On Thu, Sep 4, 2014 at 5:53 PM, Siddharth Wagle <swagle= @hortonworks.com> wrote:
Hi Alex,

Replies inline.

1= . If a component exists in the parent stack and is defined again in the child stack with just a few attributes, are these values just to=20 override the parent's values or the whole component definition is=20 replaced.

We go property by property and merge them fro= m parent to child. So if you remove a category for example from the child i= t will be inherited from parent, that goes for pretty much all properties.<= br>
So, the question is how do we tackle existence of a property in both = parent and child. Here, most of the decision still follow same paradigm as = take the child value instead of parent and every property in parent, not ex= plicitly deleted from child using a marker like <deleted> tag, is inc= luded in the merge.

- For config-dependencies, we take all or nothing approach, if th= is property exists in child use it and all of its children else take it fro= m parent.
- The custom commands are merged based on names, such th= at merged definition is a union of commands with child commands with same n= ame overriding those fro parent.
- Cardinality is overwritten by a child or take from the parent = if child has not provided one.

You could look at th= is method for more details: org.apache.ambari.server.api.util.StackExtensio= nHelper#mergeServices

2. If a component is missing in t= he new definition but is present in the parent, does it get inherited ?

Generally yes.

3. Config= uration dependencies for the service -- are they overwritten or merged ?

Overwritten.

4. What about other elements in metainfo.xml -- which rules apply ?

Answered in 1.

<= div>-Sid






On Thu,= Sep 4, 2014 at 5:02 PM, Alexander Denissov <adenissov@pivotal.io= > wrote:
I am trying to understand t= he inheritance rules that govern services metainfo.xml file contents. I loo= ked at=C2=A0http= s://issues.apache.org/jira/browse/AMBARI-2819=C2=A0but it didn't an= swer the following:

1. If a component exists in the parent stack and is defined = again in the child stack with just a few attributes, are these values just = to override the parent's values or the whole component definition is re= placed.

Example: HDP-2.1 YARN/metainfo.xml contains definition = of RESOURCEMANAGER with just 4 attributes, out of which only the value for = "cardinality" is different one in HDP-2.0.6 definition. But 2.0.6= definition also has a lot more attributes (such as custom commands) that a= re not mentioned in 2.1. Will these "missing" attributes be inher= ited by 2.1 stack ? If yes, why other attributes (category and configuratio= n-dependencies) are defined again with the same values instead of being inh= erited ?

2. If a component is missing in the new definition but = is present in the parent, does it get inherited ?

= 3. Configuration dependencies for the service -- are they overwritten or me= rged ?

Example: HDP-2.1 YARN/metainfo.xml contains <configu= ration-dependencies> element with 4 <config-type>, where as in HDP= -2.0.6 the same element has 5=C2=A0<config-type>=C2=A0(extra line is = mapred-site). So will=C2=A0<config-type>mapred-site</config-type> b= e inherited and present in 2.1 definition or was this the way to get rid of= this specific line for the new stack ?

4. What about other elements in meta= info.xml -- which rules apply ?

--
Thanks,
Alex.


CONFIDENTIALITY NOTICE
NOTICE: This message is = intended for the use of the individual or entity to which it is addressed a= nd may contain information that is confidential, privileged and exempt from= disclosure under applicable law. If the reader of this message is not the = intended recipient, you are hereby notified that any printing, copying, dis= semination, distribution, disclosure or forwarding of this communication is= strictly prohibited. If you have received this communication in error, ple= ase contact the sender immediately and delete it from your system. Thank Yo= u.

CONFIDENTIALITY NOTICE
NOTICE: This message is = intended for the use of the individual or entity to which it is addressed a= nd may contain information that is confidential, privileged and exempt from= disclosure under applicable law. If the reader of this message is not the = intended recipient, you are hereby notified that any printing, copying, dis= semination, distribution, disclosure or forwarding of this communication is= strictly prohibited. If you have received this communication in error, ple= ase contact the sender immediately and delete it from your system. Thank Yo= u. --20cf303a337d952b11050251cdf8--