pillar matcher?

[Tom Vaughan]

I know there is no pillar matcher currently. Is there something that would prevent me from writing a pillar matcher?

I had played around with something like this in salt/top.sls:

    'role:production':

      - match: grain

This was set in the minion config. But now I want this set in pillar/top.sls on the master. So all I want to be able to do is swap "match: grain" with "match: pillar" in the example above.

Thanks.

-Tom

[Thomas S Hatch]

Yes, I am definitely open to having a pillar matcher! In reality it should not be too hard to add if you want to take a swing at it.

[Jeff Schroeder]

Now would you add 2 new matchers?

pillar glob (default) and pillar pcre?

--
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com

[Thomas S Hatch]

Oh, we would, and it would need to traverse data the same way it does in grains, so that you can match list components

[Tom Vaughan]

I'm a little stumped. salt/top.sls and pillar/top.sls seem to be parsed differently. This:

    base:

      'foo':

        - match: bar

causes an appropriate error ("Attempting to match with unknown matcher") in pillar/top.sls, but not salt/top.sls. For salt/top.sls, if:

 - Does not exist, then "Top data not found..."

 - No content, then "No states found..."

 - Any content, (like sendmail.cf, seriously), then nothing happens. There just wasn't a match. So in the example above nothing happens.

I just simply copied "grains_match" and replaced "grain" or "grains" with "pillar" and that seems to work. But I can't tell for certain since I never seem to be able to produce any errors in my tests.

Could someone point me to where salt/top.sls is parsed. I followed "get_tops" in state.py, and that doesn't seem to be it. No?

Thanks.

-Tom

On Thursday, May 17, 2012 11:57:26 AM UTC-4, Thomas Hatch wrote:

Yes, I am definitely open to having a pillar matcher! In reality it should not be too hard to add if you want to take a swing at it.

[Thomas S Hatch]

There are some extra checks in the state system that need to be added to pillar, or better yet the code for gathering and parsing the top files needs to be unified. To add a matcher what you really need to look at is the matcher class in minion.py

[Tom Vaughan]

I understand that what I've done so far is incomplete. But the example below salt/top.sls is independent of a pillar matcher. I'm a little confused as to why the example doesn't cause any error, even with a current, totally unmodified salt.

I did see how there seems to be some duplication in code that parses salt/top.sls and pillar/top.sls. The code that parses pillar/top.sls did catch the errors. Given that, when you say the code should be unified, should the code that parses pillar/top.sls be given preference, or something else?

On Thursday, May 17, 2012 4:10:52 PM UTC-4, Thomas Hatch wrote:

There are some extra checks in the state system that need to be added to pillar, or better yet the code for gathering and parsing the top files needs to be unified. To add a matcher what you really need to look at is the matcher class in minion.py

[Tom Vaughan]

Hm. I think I may have already done what you suggest. When I said I copied "grain_match" to make "pillar_match" previously that was in the Matcher class in minion.py. I don't see that there is more to add there. What else should I add?

I can see by the exsel matcher that there are more places to touch so that this is supported by the command-line client and by batches. I've added those now too.

Besides tests and documentation, what else would be necessary to make this complete?

I could start a pull-request if you'd rather have the discussion about this on GitHub.

Thanks.

-Tom

On Thursday, May 17, 2012 4:10:52 PM UTC-4, Thomas Hatch wrote:

There are some extra checks in the state system that need to be added to pillar, or better yet the code for gathering and parsing the top files needs to be unified. To add a matcher what you really need to look at is the matcher class in minion.py

[Thomas S Hatch]

Lets start a pull request if you have it working and we can evaluate the code and see what needs to be added.

Thanks Tom!

[Tom Vaughan]

Cool. https://github.com/saltstack/salt/pull/1299

On Thursday, May 17, 2012 10:14:57 PM UTC-4, Thomas Hatch wrote:

Lets start a pull request if you have it working and we can evaluate the code and see what needs to be added.

Thanks Tom!