fullerene icon indicating copy to clipboard operation
fullerene copied to clipboard

Globbing support in collections/hostgroups

Open bitprophet opened this issue 14 years ago • 0 comments

Spinoff of #9.

Allow globbing/patterns in the host string values of the collections data structure, which would then expand based upon the automatic host list. This turns it from being "static" into just another way of organizing the known hosts. Probably not a problem -- it makes no sense to define a host which...doesn't actually exist in the metrics system.

E.g.:

collections:
   by-project:
      giantbomb:
        - web*.giantbomb.com
        - db.giantbomb.com
        - lb[23].whiskeymedia.com

Except of course that we'd really just compress that down to this:

collections:
   by-project:
      giantbomb:
        - *.giantbomb.com
        - lb[23].whiskeymedia.com

And it might be useful to use "aliasing" here too, so we end up with:

collections:
  shared-systems:
    - lb[23].whiskeymedia.com
    - cache1[01].whiskeymedia.com
    - mongo2.whiskeymedia.com
  by-project:
    giantbomb:
      - shared-systems
      - *.giantbomb.com

However, that (the aliasing) is extra work to implement (and more crap for users to deal with), and only truly useful if you are hand-generating these configs -- assuming config management templating, it's just as easy to do the refactoring of truly shared systems in your config management DB.

The same argument could be applied to the globbing as well, but that is less clear-cut IMO, especially if you don't want to force people to have to config manage this to be useful.

bitprophet avatar Oct 27 '11 00:10 bitprophet