How to implement DSL or custom filtering logic in Golang

Since quite some time I have been working on an IaaS Resource Monitoring Utility for different clouds (AWS, GCP, Azure, Openstack). Such a utility is particularly useful to my team because we develop a PaaS product (that gets deployed on all these IaaS platforms) and as a result of dev/testing/bugs there are lots of resources that pile up on all of these IaaS platforms. This results in increased costs + exhaustion of quota.

Idea behind this utility was to give a overview of a particular IaaS account (VMs, Snapshots, Volumes, Object Store Containers etc.) as well as support cleanup of such orphan/stale resources.

Now, I feel such a utility could also be useful for other teams/community outside our company - hence I intend to open source the Golang utility now. The problem is that the code in it's current form has reached a stage where we have lot of custom code which is very specific to our use-case. Something along the lines of:

• Mark Volumes as orphans which have a tag 'foo=bar', creation date before 14 days and status as 'available' or 'error'
• Mark Snapshots as orphans which have a description starting with 'foo' OR 'foo1' OR 'foo2' etc
• Mark Objectstore container files as orphans which have 'foo' somewhere in the object name and creation_date should be minimum X days back

Hope that gives you an idea.

Now, I plan to somehow decouple all this logic and restrict the actual tool's code to just interact with the IaaS and fetch/report the data. With this, all custom filtering logic then moves out so that anybody who uses this tool can just specify his custom logic on what should be the criteria to mark/report a resource as orphan.

I had some ideas along the following lines:

• Have a json/yaml configuration file which defines the logic of marking a resource as stale/orphan. How/Where would user define his logic ? Some sort of DSL ? What if users also need regex support tomorrow ?
• Have these filters as part of code itself. Somebody then forks the repository and adds some custom Go code which acts as the filter - Something around chain of filters pattern ?
• Expose all possible filters variations as config/environment variables. Probably this won't be a good approach as this would require a lot of input to actually use the tool ?

Idea is to keep the tool implementation as thin as possible and all custom filters/logic to be easily configurable by the user and not compromising on the ease of tool usage at the same time.

Any suggestions/help around best practices for such an implementation would be really helpful. Please let me know if you need any further information.

Thanks !