FAQ
Hi All,



I would like to place one minion in two different environments in the top file, is this possible? I am using logic based on the salt populated env variable to try and make my sls files environment agnostic.



I tried and it seems to pull in pillar data from both environments into state files in one environment...is that because of the order in which state files are compiled, or is it due to caching such that the files with the same name but in different environments are treated the same because of the unified file system.....



or should I just avoid trying to place one minion in two different environments...or perhaps I should run two minions on the same host?



Regards,

Chandra



Chandra Amarasingham
Analyst Programmer
Specialist Diagnostic Services Pty Ltd
17 Enterprise Grove, Mt Helen, 3350
Federation University Technology Park

T: (03) 5330 1056 ext 212

This email (including any attachments) is intended only for the addressee. It may contain confidential or legally privileged information. Confidentiality and privilege are not waived or lost if you are not the intended recipient of this email, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. If you receive this email in error, please delete it and any attachments from your system and notify us immediately. It is your responsibility to check this email and any attachments, before opening or using them, for viruses or defects. You assume all liability arising from opening or using this email and any attachment.

--
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

  • David Boucha at Jan 14, 2015 at 10:44 pm
    A minion can definitely match in more than one environment in both your
    pillar top file and your state top file.

    When you run a highstate, the minion evaluates the state top file found at
    /srv/salt/top.sls, by default, and searches each of the match lines for a
    match.
    It keeps track of each sls file listed under the places it matches and
    pulls them all down to the minion to be evaluated.

    Pillar top files work the same way, except that the Salt Master evaluates
    the pillar top file found at /srv/pillar/top.sls, by default, on behalf of
    the minion.
    On Wed, Jan 14, 2015 at 3:30 PM, AMARASINGHAM, Chandra wrote:

    Hi All,



    I would like to place one minion in two different environments in the top
    file, is this possible? I am using logic based on the salt populated env
    variable to try and make my sls files environment agnostic.



    I tried and it seems to pull in pillar data from both environments into
    state files in one environment...is that because of the order in which
    state files are compiled, or is it due to caching such that the files with
    the same name but in different environments are treated the same because of
    the unified file system.....



    or should I just avoid trying to place one minion in two different
    environments...or perhaps I should run two minions on the same host?



    Regards,

    Chandra


    *Chandra Amarasingham*
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the
    addressee. It may contain confidential or legally privileged information.
    Confidentiality and privilege are not waived or lost if you are not the
    intended recipient of this email, nor may you use, review, disclose,
    disseminate or copy any information contained in or attached to it. If you
    receive this email in error, please delete it and any attachments from your
    system and notify us immediately. It is your responsibility to check this
    email and any attachments, before opening or using them, for viruses or
    defects. You assume all liability arising from opening or using this email
    and any attachment.

    --
    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.
  • Alex Leonhardt at Jan 14, 2015 at 10:55 pm
    Hmmm how would the result be if you have, say a repo config for "dev",
    which is different than for "stg", and the minion is part of both? Which
    one wins?

    Alex
    On Wed, 14 Jan 2015 22:44 David Boucha wrote:

    A minion can definitely match in more than one environment in both your
    pillar top file and your state top file.

    When you run a highstate, the minion evaluates the state top file found at
    /srv/salt/top.sls, by default, and searches each of the match lines for a
    match.
    It keeps track of each sls file listed under the places it matches and
    pulls them all down to the minion to be evaluated.

    Pillar top files work the same way, except that the Salt Master evaluates
    the pillar top file found at /srv/pillar/top.sls, by default, on behalf of
    the minion.

    On Wed, Jan 14, 2015 at 3:30 PM, AMARASINGHAM, Chandra <
    chandra.amarasingham@sdspathology.com.au> wrote:
    Hi All,



    I would like to place one minion in two different environments in the top
    file, is this possible? I am using logic based on the salt populated env
    variable to try and make my sls files environment agnostic.



    I tried and it seems to pull in pillar data from both environments into
    state files in one environment...is that because of the order in which
    state files are compiled, or is it due to caching such that the files with
    the same name but in different environments are treated the same because of
    the unified file system.....



    or should I just avoid trying to place one minion in two different
    environments...or perhaps I should run two minions on the same host?



    Regards,

    Chandra


    *Chandra Amarasingham*
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the
    addressee. It may contain confidential or legally privileged information.
    Confidentiality and privilege are not waived or lost if you are not the
    intended recipient of this email, nor may you use, review, disclose,
    disseminate or copy any information contained in or attached to it. If you
    receive this email in error, please delete it and any attachments from your
    system and notify us immediately. It is your responsibility to check this
    email and any attachments, before opening or using them, for viruses or
    defects. You assume all liability arising from opening or using this email
    and any attachment.

    --
    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.
    --
    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.
  • AMARASINGHAM, Chandra at Jan 15, 2015 at 12:55 am
    Hi Alex,



    I would think that both repos get configured if they can be, the trouble would be if states can't co-exist....or the one getting applied last may overwrite the other one perhaps......



    Chandra



    Chandra Amarasingham
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the addressee. It may contain confidential or legally privileged information. Confidentiality and privilege are not waived or lost if you are not the intended recipient of this email, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. If you receive this email in error, please delete it and any attachments from your system and notify us immediately. It is your responsibility to check this email and any attachments, before opening or using them, for viruses or defects. You assume all liability arising from opening or using this email and any attachment.
    ________________________________
    From: salt-users@googlegroups.com [salt-users@googlegroups.com] on behalf of Alex Leonhardt [aleonhardt.py@gmail.com]
    Sent: Thursday, 15 January 2015 9:55 AM
    To: salt-users@googlegroups.com
    Subject: Re: [salt-users] Can one minion belong to two different environments?


    Hmmm how would the result be if you have, say a repo config for "dev", which is different than for "stg", and the minion is part of both? Which one wins?

    Alex

    On Wed, 14 Jan 2015 22:44 David Boucha wrote:
    A minion can definitely match in more than one environment in both your pillar top file and your state top file.

    When you run a highstate, the minion evaluates the state top file found at /srv/salt/top.sls, by default, and searches each of the match lines for a match.
    It keeps track of each sls file listed under the places it matches and pulls them all down to the minion to be evaluated.

    Pillar top files work the same way, except that the Salt Master evaluates the pillar top file found at /srv/pillar/top.sls, by default, on behalf of the minion.

    On Wed, Jan 14, 2015 at 3:30 PM, AMARASINGHAM, Chandra wrote:

    Hi All,



    I would like to place one minion in two different environments in the top file, is this possible? I am using logic based on the salt populated env variable to try and make my sls files environment agnostic.



    I tried and it seems to pull in pillar data from both environments into state files in one environment...is that because of the order in which state files are compiled, or is it due to caching such that the files with the same name but in different environments are treated the same because of the unified file system.....



    or should I just avoid trying to place one minion in two different environments...or perhaps I should run two minions on the same host?



    Regards,

    Chandra



    Chandra Amarasingham
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the addressee. It may contain confidential or legally privileged information. Confidentiality and privilege are not waived or lost if you are not the intended recipient of this email, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. If you receive this email in error, please delete it and any attachments from your system and notify us immediately. It is your responsibility to check this email and any attachments, before opening or using them, for viruses or defects. You assume all liability arising from opening or using this email and any attachment.

    --
    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.

    --
    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.
  • Stephen Spencer at Jan 15, 2015 at 12:59 am
    Saltstack operates, at the data layer, on dictionaries. While (pre-2014.7)
    pillar would use the last key:value defined for a particular key, the state
    system errors out because of those duplicate keys.

    So if you use an identical state identifier for both dev and staging, the
    state run will error out, but only if a minion is matched by those two
    environments' match patterns. Otherwise it will appear to work until that
    time when it doesn't.

    In such a case, if the identifiers are not identical but operate on the
    same repository only with (production-level) environment arguments, the
    first will run, modifying the repository definition and return
    changed=True. The next environment's state will be similarly processed
    changing the repo definition to its target, also returning
    changed=True--every time. In this scenario you will kind of get to where
    you want to be as long as your top file defines your state's in the correct
    linear order, however; the return data will always show the minion as being
    at variance with your defined states.

    The best way to handle this sort of situation is to use templating to set
    the target value based on the (production-level) environment rather than
    forcing it onto the file server (server_root) environment functionality.

    It is confusing at first. I am sure there are perfect use-cases for file
    server environments. I don't know what they are.

    -S
    On Jan 14, 2015 4:55 PM, "Alex Leonhardt" wrote:

    Hmmm how would the result be if you have, say a repo config for "dev",
    which is different than for "stg", and the minion is part of both? Which
    one wins?

    Alex
    On Wed, 14 Jan 2015 22:44 David Boucha wrote:

    A minion can definitely match in more than one environment in both your
    pillar top file and your state top file.

    When you run a highstate, the minion evaluates the state top file found
    at /srv/salt/top.sls, by default, and searches each of the match lines for
    a match.
    It keeps track of each sls file listed under the places it matches and
    pulls them all down to the minion to be evaluated.

    Pillar top files work the same way, except that the Salt Master evaluates
    the pillar top file found at /srv/pillar/top.sls, by default, on behalf of
    the minion.

    On Wed, Jan 14, 2015 at 3:30 PM, AMARASINGHAM, Chandra <
    chandra.amarasingham@sdspathology.com.au> wrote:
    Hi All,



    I would like to place one minion in two different environments in the
    top file, is this possible? I am using logic based on the salt populated
    env variable to try and make my sls files environment agnostic.



    I tried and it seems to pull in pillar data from both environments into
    state files in one environment...is that because of the order in which
    state files are compiled, or is it due to caching such that the files with
    the same name but in different environments are treated the same because of
    the unified file system.....



    or should I just avoid trying to place one minion in two different
    environments...or perhaps I should run two minions on the same host?



    Regards,

    Chandra


    *Chandra Amarasingham*
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the
    addressee. It may contain confidential or legally privileged information.
    Confidentiality and privilege are not waived or lost if you are not the
    intended recipient of this email, nor may you use, review, disclose,
    disseminate or copy any information contained in or attached to it. If you
    receive this email in error, please delete it and any attachments from your
    system and notify us immediately. It is your responsibility to check this
    email and any attachments, before opening or using them, for viruses or
    defects. You assume all liability arising from opening or using this email
    and any attachment.

    --
    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.
    --
    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.
  • AMARASINGHAM, Chandra at Jan 15, 2015 at 1:17 am
    Thanks Stephen,



    I am fairly new to salt and confused by some of your terminology. I was wondering if you had to expand on the following paragraph



    The best way to handle this sort of situation is to use templating to set the target value based on the (production-level) environment rather than forcing it onto the file server (server_root) environment functionality.



    especially "production-level" and "server_root".....are there two levels of environments?



    Regards,

    Chandra



    Chandra Amarasingham
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the addressee. It may contain confidential or legally privileged information. Confidentiality and privilege are not waived or lost if you are not the intended recipient of this email, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. If you receive this email in error, please delete it and any attachments from your system and notify us immediately. It is your responsibility to check this email and any attachments, before opening or using them, for viruses or defects. You assume all liability arising from opening or using this email and any attachment.
    ________________________________
    From: salt-users@googlegroups.com [salt-users@googlegroups.com] on behalf of Stephen Spencer [gladiatr72@gmail.com]
    Sent: Thursday, 15 January 2015 11:59 AM
    To: salt-users@googlegroups.com
    Subject: Re: [salt-users] Can one minion belong to two different environments?


    Saltstack operates, at the data layer, on dictionaries. While (pre-2014.7) pillar would use the last key:value defined for a particular key, the state system errors out because of those duplicate keys.

    So if you use an identical state identifier for both dev and staging, the state run will error out, but only if a minion is matched by those two environments' match patterns. Otherwise it will appear to work until that time when it doesn't.

    In such a case, if the identifiers are not identical but operate on the same repository only with (production-level) environment arguments, the first will run, modifying the repository definition and return changed=True. The next environment's state will be similarly processed changing the repo definition to its target, also returning changed=True--every time. In this scenario you will kind of get to where you want to be as long as your top file defines your state's in the correct linear order, however; the return data will always show the minion as being at variance with your defined states.

    The best way to handle this sort of situation is to use templating to set the target value based on the (production-level) environment rather than forcing it onto the file server (server_root) environment functionality.

    It is confusing at first. I am sure there are perfect use-cases for file server environments. I don't know what they are.

    -S

    On Jan 14, 2015 4:55 PM, "Alex Leonhardt" wrote:

    Hmmm how would the result be if you have, say a repo config for "dev", which is different than for "stg", and the minion is part of both? Which one wins?

    Alex

    On Wed, 14 Jan 2015 22:44 David Boucha wrote:
    A minion can definitely match in more than one environment in both your pillar top file and your state top file.

    When you run a highstate, the minion evaluates the state top file found at /srv/salt/top.sls, by default, and searches each of the match lines for a match.
    It keeps track of each sls file listed under the places it matches and pulls them all down to the minion to be evaluated.

    Pillar top files work the same way, except that the Salt Master evaluates the pillar top file found at /srv/pillar/top.sls, by default, on behalf of the minion.

    On Wed, Jan 14, 2015 at 3:30 PM, AMARASINGHAM, Chandra wrote:

    Hi All,



    I would like to place one minion in two different environments in the top file, is this possible? I am using logic based on the salt populated env variable to try and make my sls files environment agnostic.



    I tried and it seems to pull in pillar data from both environments into state files in one environment...is that because of the order in which state files are compiled, or is it due to caching such that the files with the same name but in different environments are treated the same because of the unified file system.....



    or should I just avoid trying to place one minion in two different environments...or perhaps I should run two minions on the same host?



    Regards,

    Chandra



    Chandra Amarasingham
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the addressee. It may contain confidential or legally privileged information. Confidentiality and privilege are not waived or lost if you are not the intended recipient of this email, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. If you receive this email in error, please delete it and any attachments from your system and notify us immediately. It is your responsibility to check this email and any attachments, before opening or using them, for viruses or defects. You assume all liability arising from opening or using this email and any attachment.

    --
    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.

    --
    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.

    --
    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.
  • AMARASINGHAM, Chandra at Jan 15, 2015 at 1:37 am
    Sorry I messed that email up.., the old email may have sounded a little rude which was not my intention....trying again



    Thanks Stephen,



    I am fairly new to salt and confused by some of your terminology. I was wondering if you had time to expand on the following paragraph



    The best way to handle this sort of situation is to use templating to set the target value based on the (production-level) environment rather than forcing it onto the file server (server_root) environment functionality.



    especially "production-level" and "server_root".....are there two levels of environments?



    Regards,

    Chandra





    Chandra Amarasingham
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the addressee. It may contain confidential or legally privileged information. Confidentiality and privilege are not waived or lost if you are not the intended recipient of this email, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. If you receive this email in error, please delete it and any attachments from your system and notify us immediately. It is your responsibility to check this email and any attachments, before opening or using them, for viruses or defects. You assume all liability arising from opening or using this email and any attachment.
    ________________________________
    From: salt-users@googlegroups.com [salt-users@googlegroups.com] on behalf of AMARASINGHAM, Chandra
    Sent: Thursday, 15 January 2015 12:17 PM
    To: salt-users@googlegroups.com
    Subject: RE: [salt-users] Can one minion belong to two different environments?


    Thanks Stephen,



    I am fairly new to salt and confused by some of your terminology. I was wondering if you had to expand on the following paragraph



    The best way to handle this sort of situation is to use templating to set the target value based on the (production-level) environment rather than forcing it onto the file server (server_root) environment functionality.



    especially "production-level" and "server_root".....are there two levels of environments?



    Regards,

    Chandra



    Chandra Amarasingham
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the addressee. It may contain confidential or legally privileged information. Confidentiality and privilege are not waived or lost if you are not the intended recipient of this email, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. If you receive this email in error, please delete it and any attachments from your system and notify us immediately. It is your responsibility to check this email and any attachments, before opening or using them, for viruses or defects. You assume all liability arising from opening or using this email and any attachment.
    ________________________________
    From: salt-users@googlegroups.com [salt-users@googlegroups.com] on behalf of Stephen Spencer [gladiatr72@gmail.com]
    Sent: Thursday, 15 January 2015 11:59 AM
    To: salt-users@googlegroups.com
    Subject: Re: [salt-users] Can one minion belong to two different environments?


    Saltstack operates, at the data layer, on dictionaries. While (pre-2014.7) pillar would use the last key:value defined for a particular key, the state system errors out because of those duplicate keys.

    So if you use an identical state identifier for both dev and staging, the state run will error out, but only if a minion is matched by those two environments' match patterns. Otherwise it will appear to work until that time when it doesn't.

    In such a case, if the identifiers are not identical but operate on the same repository only with (production-level) environment arguments, the first will run, modifying the repository definition and return changed=True. The next environment's state will be similarly processed changing the repo definition to its target, also returning changed=True--every time. In this scenario you will kind of get to where you want to be as long as your top file defines your state's in the correct linear order, however; the return data will always show the minion as being at variance with your defined states.

    The best way to handle this sort of situation is to use templating to set the target value based on the (production-level) environment rather than forcing it onto the file server (server_root) environment functionality.

    It is confusing at first. I am sure there are perfect use-cases for file server environments. I don't know what they are.

    -S

    On Jan 14, 2015 4:55 PM, "Alex Leonhardt" wrote:

    Hmmm how would the result be if you have, say a repo config for "dev", which is different than for "stg", and the minion is part of both? Which one wins?

    Alex

    On Wed, 14 Jan 2015 22:44 David Boucha wrote:
    A minion can definitely match in more than one environment in both your pillar top file and your state top file.

    When you run a highstate, the minion evaluates the state top file found at /srv/salt/top.sls, by default, and searches each of the match lines for a match.
    It keeps track of each sls file listed under the places it matches and pulls them all down to the minion to be evaluated.

    Pillar top files work the same way, except that the Salt Master evaluates the pillar top file found at /srv/pillar/top.sls, by default, on behalf of the minion.

    On Wed, Jan 14, 2015 at 3:30 PM, AMARASINGHAM, Chandra wrote:

    Hi All,



    I would like to place one minion in two different environments in the top file, is this possible? I am using logic based on the salt populated env variable to try and make my sls files environment agnostic.



    I tried and it seems to pull in pillar data from both environments into state files in one environment...is that because of the order in which state files are compiled, or is it due to caching such that the files with the same name but in different environments are treated the same because of the unified file system.....



    or should I just avoid trying to place one minion in two different environments...or perhaps I should run two minions on the same host?



    Regards,

    Chandra



    Chandra Amarasingham
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the addressee. It may contain confidential or legally privileged information. Confidentiality and privilege are not waived or lost if you are not the intended recipient of this email, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. If you receive this email in error, please delete it and any attachments from your system and notify us immediately. It is your responsibility to check this email and any attachments, before opening or using them, for viruses or defects. You assume all liability arising from opening or using this email and any attachment.

    --
    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.

    --
    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.

    --
    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.
  • Stephen Spencer at Jan 15, 2015 at 3:59 am
    An example would be something to the effect of:

    {% if grains.somegrainkey == 'dev' -%}
       {% set reponame = 'environment_specific_repo_name '-%}
    {% else -%}
       {% set reponame = 'another_environment_specific_repo_name' -%}
    {% endif -%}

    our_local_repository:
       pkgrepo.managed:
         - name: Our Local Software Repository
         - baseurl: http://local_repo_host.mydomain/repos/{{ reponame }}
         - gpgcheck: 0
         - gpgkey: http://url.host.somedomain/for/your/gpg.key.pub

    -S
    On Wed, Jan 14, 2015 at 7:37 PM, AMARASINGHAM, Chandra wrote:

    Sorry I messed that email up.., the old email may have sounded a little
    rude which was not my intention....trying again



    Thanks Stephen,



    I am fairly new to salt and confused by some of your terminology. I was
    wondering if you had time to expand on the following paragraph



    The best way to handle this sort of situation is to use templating to set
    the target value based on the (production-level) environment rather than
    forcing it onto the file server (server_root) environment functionality.



    especially "production-level" and "server_root".....are there two levels
    of environments?



    Regards,

    Chandra




    *Chandra Amarasingham*
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the
    addressee. It may contain confidential or legally privileged information.
    Confidentiality and privilege are not waived or lost if you are not the
    intended recipient of this email, nor may you use, review, disclose,
    disseminate or copy any information contained in or attached to it. If you
    receive this email in error, please delete it and any attachments from your
    system and notify us immediately. It is your responsibility to check this
    email and any attachments, before opening or using them, for viruses or
    defects. You assume all liability arising from opening or using this email
    and any attachment.
    ------------------------------
    *From:* salt-users@googlegroups.com [salt-users@googlegroups.com] on
    behalf of AMARASINGHAM, Chandra
    *Sent:* Thursday, 15 January 2015 12:17 PM
    *To:* salt-users@googlegroups.com
    *Subject:* RE: [salt-users] Can one minion belong to two different
    environments?

    Thanks Stephen,



    I am fairly new to salt and confused by some of your terminology. I was
    wondering if you had to expand on the following paragraph



    The best way to handle this sort of situation is to use templating to set
    the target value based on the (production-level) environment rather than
    forcing it onto the file server (server_root) environment functionality.



    especially "production-level" and "server_root".....are there two levels
    of environments?



    Regards,

    Chandra


    *Chandra Amarasingham*
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the
    addressee. It may contain confidential or legally privileged information.
    Confidentiality and privilege are not waived or lost if you are not the
    intended recipient of this email, nor may you use, review, disclose,
    disseminate or copy any information contained in or attached to it. If you
    receive this email in error, please delete it and any attachments from your
    system and notify us immediately. It is your responsibility to check this
    email and any attachments, before opening or using them, for viruses or
    defects. You assume all liability arising from opening or using this email
    and any attachment.
    ------------------------------
    *From:* salt-users@googlegroups.com [salt-users@googlegroups.com] on
    behalf of Stephen Spencer [gladiatr72@gmail.com]
    *Sent:* Thursday, 15 January 2015 11:59 AM
    *To:* salt-users@googlegroups.com
    *Subject:* Re: [salt-users] Can one minion belong to two different
    environments?

    Saltstack operates, at the data layer, on dictionaries. While
    (pre-2014.7) pillar would use the last key:value defined for a particular
    key, the state system errors out because of those duplicate keys.

    So if you use an identical state identifier for both dev and staging, the
    state run will error out, but only if a minion is matched by those two
    environments' match patterns. Otherwise it will appear to work until that
    time when it doesn't.

    In such a case, if the identifiers are not identical but operate on the
    same repository only with (production-level) environment arguments, the
    first will run, modifying the repository definition and return
    changed=True. The next environment's state will be similarly processed
    changing the repo definition to its target, also returning
    changed=True--every time. In this scenario you will kind of get to where
    you want to be as long as your top file defines your state's in the correct
    linear order, however; the return data will always show the minion as being
    at variance with your defined states.

    The best way to handle this sort of situation is to use templating to set
    the target value based on the (production-level) environment rather than
    forcing it onto the file server (server_root) environment functionality.

    It is confusing at first. I am sure there are perfect use-cases for file
    server environments. I don't know what they are.

    -S
    On Jan 14, 2015 4:55 PM, "Alex Leonhardt" wrote:

    Hmmm how would the result be if you have, say a repo config for "dev",
    which is different than for "stg", and the minion is part of both? Which
    one wins?

    Alex
    On Wed, 14 Jan 2015 22:44 David Boucha wrote:

    A minion can definitely match in more than one environment in both
    your pillar top file and your state top file.

    When you run a highstate, the minion evaluates the state top file found
    at /srv/salt/top.sls, by default, and searches each of the match lines for
    a match.
    It keeps track of each sls file listed under the places it matches and
    pulls them all down to the minion to be evaluated.

    Pillar top files work the same way, except that the Salt Master
    evaluates the pillar top file found at /srv/pillar/top.sls, by default, on
    behalf of the minion.

    On Wed, Jan 14, 2015 at 3:30 PM, AMARASINGHAM, Chandra <
    chandra.amarasingham@sdspathology.com.au> wrote:
    Hi All,



    I would like to place one minion in two different environments in the
    top file, is this possible? I am using logic based on the salt populated
    env variable to try and make my sls files environment agnostic.



    I tried and it seems to pull in pillar data from both environments into
    state files in one environment...is that because of the order in which
    state files are compiled, or is it due to caching such that the files with
    the same name but in different environments are treated the same because of
    the unified file system.....



    or should I just avoid trying to place one minion in two different
    environments...or perhaps I should run two minions on the same host?



    Regards,

    Chandra


    *Chandra Amarasingham*
    Analyst Programmer
    Specialist Diagnostic Services Pty Ltd
    17 Enterprise Grove, Mt Helen, 3350
    Federation University Technology Park

    T: (03) 5330 1056 ext 212

    This email (including any attachments) is intended only for the
    addressee. It may contain confidential or legally privileged information.
    Confidentiality and privilege are not waived or lost if you are not the
    intended recipient of this email, nor may you use, review, disclose,
    disseminate or copy any information contained in or attached to it. If you
    receive this email in error, please delete it and any attachments from your
    system and notify us immediately. It is your responsibility to check this
    email and any attachments, before opening or using them, for viruses or
    defects. You assume all liability arising from opening or using this email
    and any attachment.

    --
    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.
    --
    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.

    --
    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.


    --
    You know, I used to think it was awful that life was so unfair. Then I
    thought, wouldn't it be much worse if life were fair, and all the terrible
    things that happen to us come because we actually deserve them? So, now I
    take great comfort in the general hostility and unfairness of the universe.

    --
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedJan 14, '15 at 10:30p
activeJan 15, '15 at 3:59a
posts8
users4

People

Translate

site design / logo © 2022 Grokbase