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: i) Mark Volumes as orphans which have a tag 'foo=bar', creation date before 14 days and status as 'available' or 'error' ii) Mark Snapshots as orphans which have a description starting with 'foo' OR 'foo1' OR 'foo2' etc and don't have a iii) 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 report the data (Console Output / PDF etc.) With this, all custom filtering logic has to then move out so that anybody who uses this tool can just easily specify his custom logic to mark a resource as orphan. I had some ideas along the following lines: i) 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 ? Will it support all combinations that user might want.. < , > , >= , != etc.. ii) 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 ? iii) 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 ? Plan 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 use 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. Best Regards, Akshay -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
