Pillar glob matching weird behavior
164 views
Skip to first unread message
Will Platnick
Apr 10, 2013, 1:49:45 PM4/10/13
to salt-...@googlegroups.com
- My pillar glob matching is acting weird for one server in particular. Master and minion are both running 0.14.0 built from dev about a week and a half ago. I didn't see any issues or code changes in github that affected this since then.
- glob matching on pillars seems to be working very funky. If I try to match on the glob, it's not working. If I type the hostname fully, the pillars get set but my renderer output is messed up when I run a highstate.Details below-------------pillar top.sls
- -------
- base:
- '*':
- - users
- - production
- - softlayer-dfw
- 'willtest*':
- - development
- '*-dev.youversion.com':
- - development
- 'staging*.youversion.com':
- - staging
- - solr-slave
- 'graphdb*':
- - digitalocean-ny
- - memcache01-dfw
- production.sls assigns ENVIRONMENT = production (among other things)
- staging.sls assigns ENVIRONMENT = staging (among other things)
- development.sls assigns ENVIRONMENT = development (among other things)
- # Refresh pillar
- root@salt:/srv/pillar# salt 'staging*' saltutil.refresh_pillar
- True
- # View pillar data for ENVIRONMENT
- root@salt:/srv/pillar# salt 'staging*' pillar.items ENVIRONMENT
- production
- So, as we can see, it is not getting the staging pillar. I change the top.sls to no longer match on 'staging*.youversion.com', but to match the hostname exactly.
- top.sls
- base:
- '*':
- - users
- - production
- - softlayer-dfw
- 'willtest*':
- - development
- '*-dev.youversion.com':
- - development
- - staging
- - solr-slave
- 'graphdb*':
- - digitalocean-ny
- - memcache01-dfw
- # Refresh
- root@salt:/srv/pillar# salt 'staging*' saltutil.refresh_pillar
- True
- # BINGO!
- root@salt:/srv/pillar# salt 'staging*' pillar.items ENVIRONMENT
- staging
- BUUUTTTTT. Now that it gets pillar correctly, my RENDERER output is messed up when I run a highstate against it.
- This is what returns now that my pillar matches correctly. Look at the funkiness in the apt_repository_|-neo4j_|-neo4j_|-present and __run_num__ appearing in the output.
- ----------
- apt_repository_|-neo4j_|-neo4j_|-present:
- ----------
- __run_num__:
- 0
- changes:
- ----------
- comment:
- Appended 0 lines and unless executed successfully
- name:
- debian.neo4j.org-repo
- result:
- True
- I then revert my top.sls back to the way it was at the top of the file, with the glob matching. ENVIRONMENT is back to production, but when I highstate, my renderer is no longer returning funky data, and a highstate now returns something with sane output:
- ----------
- State: - apt_repository
- Name: neo4j
- Function: present
- Result: True
- Comment: Appended 0 lines and unless executed successfully
- Changes:
- And just in case anybody wants to see them
- production.sls
- ENVIRONMENT: production
- SOLR_MEMORY: 14336m
- SOLR_NEWRELIC: -javaagent:$SOLR_PATH/newrelic.jar -Dnewrelic.environment=production
- SOLR_ROLE: master
- IS_MONITORED: True
- POSTGRESQL_VERSION: 9.2
- PHPFPM_MAX_CHILDREN: 128
- PHPFPM_START_SERVERS: 32
- PHPFPM_MIN_SPARE_SERVERS: 8
- PHPFPM_MAX_SPARE_SERVERS: 32
- PHPFPM_MAX_REQUESTS: 9000
- PHPFPM_ENV_CONF: /var/www/youversion.com/current/config/php_fpm_env
- MEMCACHED_SIZE: 95232
- MEMCACHED_PORT: 11211
- GEARMAN_3X_PROCS: 25
- GEARMAN_2X_PROCS: 5
- MYSQL_VERSION: 5.5
- staging.sls
- ENVIRONMENT: staging
- SOLR_MEMORY: 2048m
- SOLR_NEWRELIC: -javaagent:/var/www/solr/youversion/newrelic.jar -Dnewrelic.environment=staging
- SOLR_ROLE: master
- IS_MONITORED: True
- POSTGRESQL_VERSION: 9.2
- PHPFPM_MAX_CHILDREN: 128
- PHPFPM_START_SERVERS: 32
- PHPFPM_MIN_SPARE_SERVERS: 8
- PHPFPM_MAX_SPARE_SERVERS: 32
- PHPFPM_MAX_REQUESTS: 9000
- PHPFPM_ENV_CONF: /var/www/youversion.com/current/config/php_fpm_env
- MEMCACHED_SIZE: 8
- MEMCACHED_PORT: 11212
- GEARMAN_3X_PROCS: 5
- GEARMAN_2X_PROCS: 5
- MYSQL_VERSION: 5.5
Will Platnick
Apr 10, 2013, 2:00:29 PM4/10/13
to salt-...@googlegroups.com
To rule out any new code, I just built new packages for minion and master from current dev, and the issue is still occuring
Will Platnick
Apr 10, 2013, 2:17:47 PM4/10/13
to salt-...@googlegroups.com
It looks like the issue is going deeper than glob matching. It appears to be an inheritance problem as well. To make things simpler, consider the following setup:
On Wednesday, April 10, 2013 1:49:45 PM UTC-4, Will Platnick wrote:
root@salt:/srv/pillar# cat top.sls
base:
'*':
- master
- override
root@salt:/srv/pillar# cat master.sls
WHATAMI: master
root@salt:/srv/pillar# cat override.sls
WHATAMI: overridden
Thomas S Hatch
Apr 11, 2013, 2:41:12 PM4/11/13
to salt-...@googlegroups.com
This type of overriding does not work and is not part of pillar, is there some documentation that suggests this that we can correct?
Thomas S. Hatch | Founder, CTO
--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Max Arnold
Apr 11, 2013, 9:09:40 PM4/11/13
to salt-...@googlegroups.com
On Thu, Apr 11, 2013 at 12:41:12PM -0600, Thomas S Hatch wrote:
> This type of overriding does not work and is not part of pillar, is there
> some documentation that suggests this that we can correct?
There is no recommended way to override pillar in the docs, so people turn to Google.
> This type of overriding does not work and is not part of pillar, is there
> some documentation that suggests this that we can correct?
And google leads to several github issues:
https://github.com/saltstack/salt/pull/1287
https://github.com/saltstack/salt/issues/3991
An example of proper way to override/extend pillar with host-specific values would be
great addition to official documentation.
Reply all
Reply to author
Forward
0 new messages