FAQ
Hi!

I am new to salt, and I am running into this problem:


I want to define data private to a machine by using an SLS like this:


machinename.sls: <--- according to the value of grains['id']
key1: value1
key2: value2
...


I have these all in a subdirectory, and I have an init.sls like this:

--------------------- cut
include:
   - {{ grains['id'] }}

--------------------- cut

I intend to modify this to read something like

{{ grains['id'] | default("nohost.sls") }}

to cope for absent files after validating the principle.

This is supposed to ensure that only the machine with the given id can
see these values at all, and also free me from having to maintain a list
of files in the init.sls file. The machine specific file is then
supposed to have values like the operating system it should run, or what
roles are being assigned to it, etc.

Unfortunately, when I try to use this data, I get an error message that
I do not really understand ('sid-1' is a test VM used in this
experiment):


# salt -l debug 'sid-1*' pillar.data 2>&1|grep -C5 -E '(os_|error)'
sid-1:
     ----------
     _errors:
         - Specified SLS 'sid-1' in environment 'base' is not available on the salt master
     master:
         ----------
         ... more values here


The file in question has this content:

# cat sid-1.sls
os_family: Debian
os_release: testing
#


How can I fix this so as to not inadvertantly deliver data to minions
which are not destined for them?


TIA!


I am using the 2014.* variant of packages everywhere, eg.
2014.1.7+ds-1~bpo70+1 on the salt master.



Kind regards,
--Toni++

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Tonthon at Jul 31, 2014 at 11:40 am
    Hi,

    Aren't you missing a top.sls file in the pillar directory ?

    Cheers

    Le 31/07/2014 13:37, Toni Mueller a écrit :
    Hi!

    I am new to salt, and I am running into this problem:


    I want to define data private to a machine by using an SLS like this:


    machinename.sls: <--- according to the value of grains['id']
    key1: value1
    key2: value2
    ...


    I have these all in a subdirectory, and I have an init.sls like this:

    --------------------- cut
    include:
    - {{ grains['id'] }}

    --------------------- cut

    I intend to modify this to read something like

    {{ grains['id'] | default("nohost.sls") }}

    to cope for absent files after validating the principle.

    This is supposed to ensure that only the machine with the given id can
    see these values at all, and also free me from having to maintain a list
    of files in the init.sls file. The machine specific file is then
    supposed to have values like the operating system it should run, or what
    roles are being assigned to it, etc.

    Unfortunately, when I try to use this data, I get an error message that
    I do not really understand ('sid-1' is a test VM used in this
    experiment):


    # salt -l debug 'sid-1*' pillar.data 2>&1|grep -C5 -E '(os_|error)'
    sid-1:
    ----------
    _errors:
    - Specified SLS 'sid-1' in environment 'base' is not available on the salt master
    master:
    ----------
    ... more values here


    The file in question has this content:

    # cat sid-1.sls
    os_family: Debian
    os_release: testing
    #


    How can I fix this so as to not inadvertantly deliver data to minions
    which are not destined for them?


    TIA!


    I am using the 2014.* variant of packages everywhere, eg.
    2014.1.7+ds-1~bpo70+1 on the salt master.



    Kind regards,
    --Toni++
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Toni Mueller at Jul 31, 2014 at 11:53 am
    Hi,
    On Thu, Jul 31, 2014 at 01:40:40PM +0200, tonthon wrote:
    Aren't you missing a top.sls file in the pillar directory ?
    no? There, I have:


    # cat ../top.sls
    base:
       '*':
         - data
         - hosts
         - users
    #


    with 'hosts' being the subdirectory where this 'include' statement
    fails.


    What are the best practices to assign pillar data private to specific
    minions, and to assign roles to hosts?



    Kind regards,
    --Toni++

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • JC Lawrence at Jul 31, 2014 at 2:23 pm
    I use grains and do:

    {% if grains...something %]
       name: value
    {% else %}
       name: value
    {% endif %}

    and then simply list that SLS in top under "*".

    -- JCL
    On 31 Jul 2014, at 04:53, Toni Mueller wrote:


    Hi,
    On Thu, Jul 31, 2014 at 01:40:40PM +0200, tonthon wrote:
    Aren't you missing a top.sls file in the pillar directory ?
    no? There, I have:


    # cat ../top.sls
    base:
    '*':
    - data
    - hosts
    - users
    #


    with 'hosts' being the subdirectory where this 'include' statement
    fails.


    What are the best practices to assign pillar data private to specific
    minions, and to assign roles to hosts?



    Kind regards,
    --Toni++

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Toni Mueller at Jul 31, 2014 at 2:30 pm
    Hi,
    On Thu, Jul 31, 2014 at 07:23:14AM -0700, JC Lawrence wrote:
    I use grains and do:

    {% if grains...something %]
    name: value
    {% else %}
    name: value
    {% endif %}

    and then simply list that SLS in top under "*".

    that works, but this approach does not scale, and it looks messy to me.


    How do you generally deliver data which is private to specific minions,
    and at some scale?


    Kind regards,
    --Toni++

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Jagszent at Jul 31, 2014 at 3:19 pm
    Hi Toni,


    I have the following in the pillar's top.sls:
    # Anything that is specific for one host gets in a special file.
    # The file for the minion "my-minion.subdomain.example.com" can be found
    # under pillar/minions/com/example/subdomain/my-minion.sls
    {% set reverse_id_dot = grains.id.split('.') | reverse() | join('.') %}
    {% set reverse_id_slash = grains.id.split('.') | reverse() | join('/') %}
    {% if
    salt['file.file_exists']('/srv/pillar/minions/'+reverse_id_slash+'.sls') %}
       {{ grains.id }}:
         - minions.{{ reverse_id_dot }}
    {% endif %}

    Works quite well. This works since the pillar data gets compiled on the
    master and send back to the minion. So the execution modules you call in
    a minion (here file.file_exists) get executed on the master not the minion.

    Toni Mueller wrote:
    Hi,
    On Thu, Jul 31, 2014 at 07:23:14AM -0700, JC Lawrence wrote:
    I use grains and do:

    {% if grains...something %]
    name: value
    {% else %}
    name: value
    {% endif %}

    and then simply list that SLS in top under "*".

    that works, but this approach does not scale, and it looks messy to me.


    How do you generally deliver data which is private to specific minions,
    and at some scale?


    Kind regards,
    --Toni++
  • Toni Mueller at Aug 1, 2014 at 12:07 pm
    Hi Daniel,
    On Thu, Jul 31, 2014 at 05:19:52PM +0200, Daniel Jagszent wrote:
    I have the following in the pillar's top.sls:
    thank you for sharing! This works nicely, albeit only from the top.sls,
    not from the init.sls in the 'hosts' subdirectory.

    Any ideas as to why that might be, please?

    What should I read to understand this behaviour, so I can plan, instead
    of guess, the next steps?


    TIA!


    Kind regards,
    --Toni++
  • Daniel Jagszent at Aug 3, 2014 at 8:39 am
    Hi Toni,

    the top.sls of the pillar system is comparable to the state tree's top.sls.
    http://docs.saltstack.com/en/latest/ref/states/top.html

    It is the only place that defines the environments and uses matchers to
    figure out which SLS files to include for a minion.

    If you would want to use this in a SLS file other than top.sls, you
    could use the special "include" key:

    {% set reverse_id_dot = grains.id.split('.') | reverse() | join('.') %}
    {% set reverse_id_slash = grains.id.split('.') | reverse() | join('/') %}
    {% if
    salt['file.file_exists']('/srv/pillar/minions/'+reverse_id_slash+'.sls') %}
    include:
    - minions.{{ reverse_id_dot }}
    {% endif %}

    or

    include:
    - something.to.always.include
    {% set reverse_id_dot = grains.id.split('.') | reverse() | join('.') %}
    {% set reverse_id_slash = grains.id.split('.') | reverse() | join('/') %}
    {% if
    salt['file.file_exists']('/srv/pillar/minions/'+reverse_id_slash+'.sls') %}
    - minions.{{ reverse_id_dot }}
    {% endif %}


    Toni Mueller wrote:
    Hi Daniel,
    On Thu, Jul 31, 2014 at 05:19:52PM +0200, Daniel Jagszent wrote:
    I have the following in the pillar's top.sls:
    thank you for sharing! This works nicely, albeit only from the top.sls,
    not from the init.sls in the 'hosts' subdirectory.

    Any ideas as to why that might be, please?

    What should I read to understand this behaviour, so I can plan, instead
    of guess, the next steps?


    TIA!


    Kind regards,
    --Toni++

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedJul 31, '14 at 11:37a
activeAug 3, '14 at 8:39a
posts8
users4

People

Translate

site design / logo © 2022 Grokbase