Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

In a YARN environment, the current handling of classpath configuration using the yarn.provided.lib.dirs property has shown limitations. The yarn.ship-files property is utilized to add specific files to the classpath by including their parent directories. This approach is particularly useful when certain resources, such as hive-site.xml, need to be accessible to the application. However, there's an issue when the application employs Thread.currentThread().getContextClassLoader().getResource("hive-site.xml") to load hive-site.xml, as the parent directory of the resource is not included within Flink's classpath. This limitation prevents the application from effectively accessing the required configuration files.

To address this limitation, this is a proposal to extend the existing approach. The intention is to also incorporate the parent directory of files specified in yarn.provided.lib.dirs to the classpath. This extension will enable the inclusion of the necessary resources in these directories within the application's classpath, thereby providing access to the required configuration files.

Public Interfaces

No new public interfaces are introduced by this proposal.

Proposed Changes

The proposed changes involve enhancing the classpath configuration mechanism when using the yarn.provided.lib.dirs property. Specifically, the current method of utilizing yarn.ship-files to add specific files' parent directories to the classpath will be extended. This extension will encompass the inclusion of the parent directory of files designated in yarn.provided.lib.dirs as well. This improvement aims to fix the issue where resources required for application configuration are inaccessible due to their parent directories not being included in Flink's classpath.

This FLIP also addresses a concern related to treating all non-Flink dist-jar or plugin files as resource files. This approach might be considered excessive and could lead to resource overloading. An alternative approach that offers greater accuracy and explicitness is to follow a pattern similar to the handling of plugins. Specifically, introducing a reserved directory named resources can be considered. All files placed within the resources directory would be explicitly treated as resources. This approach offers a structured and controlled way to manage resources while avoiding potential overloading.

Compatibility, Deprecation, and Migration Plan

• No impact on the existing users.
• The proposed change is not introducing new parameters to the configuration file.
• No special migration tools required.
• There is an enhancement to the existing behavior.

Test Plan

• Unit Test: New unit tests will be introduced to ensure proper inclusion of the parent directories of files specified in yarn.provided.lib.dirs to the classpath. 

• Manual Test: Add following configuration to flink-conf.yaml and submit Flink job. 

  yarn.provided.lib.dirs: hdfs:///user/argoyal/flinkTest/mapreduce/;hdfs:///user/argoyal/flinkTest/lib/;hdfs:///user/argoyal/flinkTest/plugins/;hdfs:///user/argoyal/flinkTest/opt/;hdfs:///user/argoyal/resources/;

Rejected Alternatives

No other ways to accomplish the same.