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 [email protected] From: Alejandro Fernandez <[email protected]> To: "[email protected]" <[email protected]>, 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 <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Tuesday, December 8, 2015 at 8:44 AM To: "[email protected]" <[email protected]> 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 [email protected] 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: [email protected] 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 [email protected]
