I also tested the lookup and it seems it is working:
When I perform a search like index=hunktest environmentid=123 I can navigate through the matches and see the environment_name field has been created and matches the CSV contents. I can also see that just one subfolder (123) has raised matches.
However, if I try to run index=hunktest environmentname=Test or index=hunktest environmentname="Test", upon inspecting the search.log, it seems like Hunk crawled the whole HDFS store instead of crawling just /logs/123/
Is it possible to define a lookup so that it act as a filter on search time?
While lookups help in forward translating the values, when we perform reverse lookups the search gets translated into (environmentid=123 OR environmentname=Test) , which unfortunately means that the search based partition pruning cannot help. We'll take that in as an enhancement request and do some research on how we can solve this problem. In the mean time one workaround that I think of would be using form searches to aid users in picking up an environment (show a user friendly string, but use the id to populate the search)