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