RFC for light-4j issue #309

[ddobrin]

No description provided.

[bkuberek]

I plus one this with the exception that keystoreName and truststoreName would still be an issue.

Both keystoreName and truststoreName have to be relative to the external config folder when one is defined, while the proposal outlined in this RFC will solve many problems I'm not sure how it would address the this.

I think one way to solve this is to check if the vslue of these variables start with a / or appropriate OS separator and load it as an absolute path otherwise relative to either the config or resources.

[ddobrin]

@bkuberek: right, you can use that.

This RFC proposes just additional flexibility, which we have observed that it served us well when I updated light-bot with merging status.yml files and had to read from multiple locations.

While the light-config-dir stays, this added functionality allows APIs (my client wishes to use it) to separate configs and load API specific YAML files from a different location. It's a utility only

[stevehu]

@ddobrin I think @bkuberek has proposed another approach to support config files to be loaded from multiple directories. As of today, all config files are loaded from the externalized folder specified by -Dlight-4j-config-dir or subfolders relative to that folder. Instead of overriding the existing method with an additional parameter to specify the config directory, why not just support absolute path for the config file? With this feature, the light-bot config file can be something like the following.

    repository:
      - /light-4j/status/src/main/resources/config/status.yml
      - /api-abc-status/src/main/resources/config/common/status.yml
      - /api-abc-status/src/main/resources/config/abcde/status.yml

As you see, all three files are using the absolute paths in the operating system and we just need to open them directly. In this way, we don't need to add another method to support directory as an additional parameter but only need to check if the configName is started with / or not. If it starts with / then load the file directly as an absolute path. If not, load it from the externalized config folder. What do you think?

[bkuberek]

I think yet another option, which is not exclusive but can be added to the one above, is to set the external config path to a list as opposed to a single path, then the application will look for configuration in all paths.

Example

-Dlight-4j-config-dir='/config:/etc/service:/var/secrets'

If a path is given absolute URL, load it as an absolute path but if not search all the configured external config folders. Similar to the $PATH variable in linux environment.

[ddobrin]

@stevehu & @bkuberek : I think that both of you make points which we should add, and I see this used in various use cases. I would like us to maintain the status quo of the light-config-dir, yet also have a utility to load configs from arbitrary directories, which users can leverage.

@stevehu : using both a relative path (from light-config-dir), as well as an absolute path, starting with / is something we should support.
It gives flexibility to whomever requires it

@bkuberek : I do like the idea of multiple config paths, provided as a list. Client code can simply load a config file, as long as it can be found within that list.
Now, we would have to agree that the list would contain absolute paths only. Documentation would indicate how the functionality can be leveraged in APIs.

If you guys agree, we can amend the doc.

[stevehu]

Multiple externalized config folders are doable but they introduce more challenges. We need to define the overwriting rules between these folders and in the cases of status.yml, we need to define the merging rules. The immediate target is to make it work for absolute paths so that we can have the release out. We can discuss the design and implementation for the multiple externalized folder in a future release.

[ddobrin]

After consulting with some folks, looking at options, here's what we'll do; please see the list below.

The rationale:

• supporting absolute paths is not a panacea for this issue
• light-bot works fine with its current functionality for a few months and absolute paths would not warrant itself the retrofitting with this module.

1. this PR stays as is
2. a new RFC will be created for supporting absolute/relative paths
3. a third RFC will be created for supporting @bkuberek idea of a list

This gives flexibility in addressing them and addresses all needs.

I will handle this today

[bkuberek]

@ddobrin thanks for handling all this

[ddobrin]

@stevehu @NicholasAzar @ChenYan71 @bkuberek:
another file has already been merged with the same name.

I will close this PR and put 3 separate PRs for the 3 items as discussed above

[ddobrin]

This PR will be closed and is replaced by:
#15