You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ambari.apache.org by Nathan Falk <nf...@us.ibm.com> on 2015/12/08 15:22:07 UTC
component dependency inheritance
All,
I have been trying find a way to remove a dependency from a service
component definition in its metainfo.xml. It seems to me that it is not
possible, due to the fact that the parent and child are "merged".
For example, the OOZIE metainfo.xml
(common-services/OOZIE/4.0.0.2.0/metainfo.xml, or other versions) has this:
<component>
<name>OOZIE_CLIENT</name>
<displayName>Oozie Client</displayName>
<category>CLIENT</category>
<cardinality>1+</cardinality>
<versionAdvertised>true</versionAdvertised>
<dependencies>
<dependency>
<name>HDFS/HDFS_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
<dependency>
<name>MAPREDUCE2/MAPREDUCE2_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
</dependencies>
I would like to remove the dependency on HDFS_CLIENT (we have a different
distributed filesystem to replace HDFS in this stack), but simply removing
it in a child stack service definition does not really remove it. So if I
define /var/lib/ambari-server/resources/stacks/${STACK_TYPE}/$
{STACK_VERSION}/services/OOZIE/metainfo.xml with:
<component>
<name>OOZIE_CLIENT</name>
<displayName>Oozie Client</displayName>
<category>CLIENT</category>
<cardinality>1+</cardinality>
<versionAdvertised>true</versionAdvertised>
<dependencies>
<dependency>
<name>MAPREDUCE2/MAPREDUCE2_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
</dependencies>
The dependency on HDFS_CLIENT will still be there because it is still
picked up from the parent stack or parent common-service.
The only way I can see around this is by taking these steps:
1) Modify the service definition in common-services directly in order to
remove the unwanted dependency.
2) Add the dependency back in to the "base" stack version (for example,
resources/stacks/HDP/2.3/services/OOZIE/metainfo.xml)
3) Have the service definition in the child stack use <extends> to inherit
directly from common-services instead of from the parent stack (for
example, resources/stacks/HDP/2.3.Child/services/OOZIE/metainfo.xml)
Has anyone else encountered this and found a better solution?
Finally, does anyone know if this is addressed by the epic AMBARI-10023 for
HCFS? Will Ambari be able to simply ignore dependencies on HDFS_CLIENT?
Thanks,
Nate Falk
nfalk@us.ibm.com
Re: component dependency inheritance
Posted by Nathan Falk <nf...@us.ibm.com>.
Alejandro,
That's correct - I can define the entire list of dependencies in the child
stack, but that list gets merged with the parent stack(s); it does not
replace the list of dependencies from the parent.
This shows up when I try to add a service component on a host. (For example
the Oozie Client). The Ambari GUI first pops up a dialog that says "Oozie
Client requires null and MapReduce2 Client to be installed along with it on
the same host. Please add them first and then try adding Oozie Client".
(Note the "null".) After adding the MapReduce2 Client and attempting to add
the Oozie Client the Ambari GUI doesn't do anything at all. No message, no
action, nothing.
Using the browser's debugger, I can see that it's because there is an
exception. This HDFS_CLIENT dependency cannot be satisfied, but since there
is no HDFS service installed, the UI code cannot map that value to a string
when trying to generate the error message. So the UI just fails silently.
Using the debugger was how I was able to see that the dependency was still
there, even though I had removed it in the child stack.
Thanks,
Nate Falk
nfalk@us.ibm.com
From: Alejandro Fernandez <af...@hortonworks.com>
To: "user@ambari.apache.org" <us...@ambari.apache.org>, Nathan
Falk/Poughkeepsie/IBM@IBMUS
Date: 12/08/2015 01:22 PM
Subject: Re: component dependency inheritance
As far as I know, a service metainfo is only allowed to remove components,
but not dependencies.
Does overriding the dependencies in your service still inherit HDFS_CLIENT
from common services?
Thanks,
Alejandro
From: Nathan Falk <nf...@us.ibm.com>
Reply-To: "user@ambari.apache.org" <us...@ambari.apache.org>
Date: Tuesday, December 8, 2015 at 8:44 AM
To: "user@ambari.apache.org" <us...@ambari.apache.org>
Subject: Re: component dependency inheritance
So I tried something along the lines of what I described below, but I
missed one detail: If I extend directly from common-services instead of
extending from the parent stack version, then I also have to pay attention
to all of the other files for that service (scripts, configuration, alerts,
widgets, etc.).
It doesn't seem worth it to extend from common-services if I then also have
to copy all of the scripts, etc., from the parent stack.
For now, what I plan to do is modify the metainfo.xml files in the parent
stacks to remove the HDFS_CLIENT dependencies.
Thanks,
Nate Falk
nfalk@us.ibm.com
Inactive hide details for Nathan Falk---12/08/2015 09:22:22 AM---All, I
have been trying find a way to remove a dependency fromNathan
Falk---12/08/2015 09:22:22 AM---All, I have been trying find a way to
remove a dependency from a service
From: Nathan Falk/Poughkeepsie/IBM@IBMUS
To: user@ambari.apache.org
Date: 12/08/2015 09:22 AM
Subject: component dependency inheritance
All,
I have been trying find a way to remove a dependency from a service
component definition in its metainfo.xml. It seems to me that it is not
possible, due to the fact that the parent and child are "merged".
For example, the OOZIE metainfo.xml
(common-services/OOZIE/4.0.0.2.0/metainfo.xml, or other versions) has this:
<component>
<name>OOZIE_CLIENT</name>
<displayName>Oozie Client</displayName>
<category>CLIENT</category>
<cardinality>1+</cardinality>
<versionAdvertised>true</versionAdvertised>
<dependencies>
<dependency>
<name>HDFS/HDFS_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
<dependency>
<name>MAPREDUCE2/MAPREDUCE2_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
</dependencies>
I would like to remove the dependency on HDFS_CLIENT (we have a different
distributed filesystem to replace HDFS in this stack), but simply removing
it in a child stack service definition does not really remove it. So if I
define /var/lib/ambari-server/resources/stacks/${STACK_TYPE}/$
{STACK_VERSION}/services/OOZIE/metainfo.xml with:
<component>
<name>OOZIE_CLIENT</name>
<displayName>Oozie Client</displayName>
<category>CLIENT</category>
<cardinality>1+</cardinality>
<versionAdvertised>true</versionAdvertised>
<dependencies>
<dependency>
<name>MAPREDUCE2/MAPREDUCE2_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
</dependencies>
The dependency on HDFS_CLIENT will still be there because it is still
picked up from the parent stack or parent common-service.
The only way I can see around this is by taking these steps:
1) Modify the service definition in common-services directly in order to
remove the unwanted dependency.
2) Add the dependency back in to the "base" stack version (for example,
resources/stacks/HDP/2.3/services/OOZIE/metainfo.xml)
3) Have the service definition in the child stack use <extends> to inherit
directly from common-services instead of from the parent stack (for
example, resources/stacks/HDP/2.3.Child/services/OOZIE/metainfo.xml)
Has anyone else encountered this and found a better solution?
Finally, does anyone know if this is addressed by the epic AMBARI-10023 for
HCFS? Will Ambari be able to simply ignore dependencies on HDFS_CLIENT?
Thanks,
Nate Falk
nfalk@us.ibm.com
Re: component dependency inheritance
Posted by Alejandro Fernandez <af...@hortonworks.com>.
As far as I know, a service metainfo is only allowed to remove components, but not dependencies.
Does overriding the dependencies in your service still inherit HDFS_CLIENT from common services?
Thanks,
Alejandro
From: Nathan Falk <nf...@us.ibm.com>>
Reply-To: "user@ambari.apache.org<ma...@ambari.apache.org>" <us...@ambari.apache.org>>
Date: Tuesday, December 8, 2015 at 8:44 AM
To: "user@ambari.apache.org<ma...@ambari.apache.org>" <us...@ambari.apache.org>>
Subject: Re: component dependency inheritance
So I tried something along the lines of what I described below, but I missed one detail: If I extend directly from common-services instead of extending from the parent stack version, then I also have to pay attention to all of the other files for that service (scripts, configuration, alerts, widgets, etc.).
It doesn't seem worth it to extend from common-services if I then also have to copy all of the scripts, etc., from the parent stack.
For now, what I plan to do is modify the metainfo.xml files in the parent stacks to remove the HDFS_CLIENT dependencies.
Thanks,
Nate Falk
nfalk@us.ibm.com<ma...@us.ibm.com>
[Inactive hide details for Nathan Falk---12/08/2015 09:22:22 AM---All, I have been trying find a way to remove a dependency from]Nathan Falk---12/08/2015 09:22:22 AM---All, I have been trying find a way to remove a dependency from a service
From: Nathan Falk/Poughkeepsie/IBM@IBMUS
To: user@ambari.apache.org<ma...@ambari.apache.org>
Date: 12/08/2015 09:22 AM
Subject: component dependency inheritance
________________________________
All,
I have been trying find a way to remove a dependency from a service component definition in its metainfo.xml. It seems to me that it is not possible, due to the fact that the parent and child are "merged".
For example, the OOZIE metainfo.xml (common-services/OOZIE/4.0.0.2.0/metainfo.xml, or other versions) has this:
<component>
<name>OOZIE_CLIENT</name>
<displayName>Oozie Client</displayName>
<category>CLIENT</category>
<cardinality>1+</cardinality>
<versionAdvertised>true</versionAdvertised>
<dependencies>
<dependency>
<name>HDFS/HDFS_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
<dependency>
<name>MAPREDUCE2/MAPREDUCE2_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
</dependencies>
I would like to remove the dependency on HDFS_CLIENT (we have a different distributed filesystem to replace HDFS in this stack), but simply removing it in a child stack service definition does not really remove it. So if I define /var/lib/ambari-server/resources/stacks/${STACK_TYPE}/${STACK_VERSION}/services/OOZIE/metainfo.xml with:
<component>
<name>OOZIE_CLIENT</name>
<displayName>Oozie Client</displayName>
<category>CLIENT</category>
<cardinality>1+</cardinality>
<versionAdvertised>true</versionAdvertised>
<dependencies>
<dependency>
<name>MAPREDUCE2/MAPREDUCE2_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
</dependencies>
The dependency on HDFS_CLIENT will still be there because it is still picked up from the parent stack or parent common-service.
The only way I can see around this is by taking these steps:
1) Modify the service definition in common-services directly in order to remove the unwanted dependency.
2) Add the dependency back in to the "base" stack version (for example, resources/stacks/HDP/2.3/services/OOZIE/metainfo.xml)
3) Have the service definition in the child stack use <extends> to inherit directly from common-services instead of from the parent stack (for example, resources/stacks/HDP/2.3.Child/services/OOZIE/metainfo.xml)
Has anyone else encountered this and found a better solution?
Finally, does anyone know if this is addressed by the epic AMBARI-10023 for HCFS? Will Ambari be able to simply ignore dependencies on HDFS_CLIENT?
Thanks,
Nate Falk
nfalk@us.ibm.com<ma...@us.ibm.com>
Re: component dependency inheritance
Posted by Nathan Falk <nf...@us.ibm.com>.
So I tried something along the lines of what I described below, but I
missed one detail: If I extend directly from common-services instead of
extending from the parent stack version, then I also have to pay attention
to all of the other files for that service (scripts, configuration, alerts,
widgets, etc.).
It doesn't seem worth it to extend from common-services if I then also have
to copy all of the scripts, etc., from the parent stack.
For now, what I plan to do is modify the metainfo.xml files in the parent
stacks to remove the HDFS_CLIENT dependencies.
Thanks,
Nate Falk
nfalk@us.ibm.com
From: Nathan Falk/Poughkeepsie/IBM@IBMUS
To: user@ambari.apache.org
Date: 12/08/2015 09:22 AM
Subject: component dependency inheritance
All,
I have been trying find a way to remove a dependency from a service
component definition in its metainfo.xml. It seems to me that it is not
possible, due to the fact that the parent and child are "merged".
For example, the OOZIE metainfo.xml
(common-services/OOZIE/4.0.0.2.0/metainfo.xml, or other versions) has this:
<component>
<name>OOZIE_CLIENT</name>
<displayName>Oozie Client</displayName>
<category>CLIENT</category>
<cardinality>1+</cardinality>
<versionAdvertised>true</versionAdvertised>
<dependencies>
<dependency>
<name>HDFS/HDFS_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
<dependency>
<name>MAPREDUCE2/MAPREDUCE2_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
</dependencies>
I would like to remove the dependency on HDFS_CLIENT (we have a different
distributed filesystem to replace HDFS in this stack), but simply removing
it in a child stack service definition does not really remove it. So if I
define /var/lib/ambari-server/resources/stacks/${STACK_TYPE}/$
{STACK_VERSION}/services/OOZIE/metainfo.xml with:
<component>
<name>OOZIE_CLIENT</name>
<displayName>Oozie Client</displayName>
<category>CLIENT</category>
<cardinality>1+</cardinality>
<versionAdvertised>true</versionAdvertised>
<dependencies>
<dependency>
<name>MAPREDUCE2/MAPREDUCE2_CLIENT</name>
<scope>host</scope>
<auto-deploy>
<enabled>true</enabled>
</auto-deploy>
</dependency>
</dependencies>
The dependency on HDFS_CLIENT will still be there because it is still
picked up from the parent stack or parent common-service.
The only way I can see around this is by taking these steps:
1) Modify the service definition in common-services directly in order to
remove the unwanted dependency.
2) Add the dependency back in to the "base" stack version (for example,
resources/stacks/HDP/2.3/services/OOZIE/metainfo.xml)
3) Have the service definition in the child stack use <extends> to inherit
directly from common-services instead of from the parent stack (for
example, resources/stacks/HDP/2.3.Child/services/OOZIE/metainfo.xml)
Has anyone else encountered this and found a better solution?
Finally, does anyone know if this is addressed by the epic AMBARI-10023 for
HCFS? Will Ambari be able to simply ignore dependencies on HDFS_CLIENT?
Thanks,
Nate Falk
nfalk@us.ibm.com