FAQ
<disclaimer: I'm very new to Salt>

*Short description:*
I need some perspective on how to implement a versioned minion state so
that 'highstate' calls don't deploy new components until told explictly to
do so.

*Long Description:*
We are building a ThoughtWorks GoCD setup to handle continuous deployment.

In GoCD, every deployment pipeline run is versioned and utilizes versioned
artifacts or materials (e.g., war, jar, RPM, properties, settings, etc.) as
part of that version of the pipeline.

This served as our "rollback" plan at my previous company. If something
failed when deploying a newer version, we could simply go back and re-run
the last successful pipeline and it would deploy using the exact same
artifact versions previously used.

I was hoping to do something similar at my current job using SaltStack.
Our initial implementation is currently moving toward the *master-minion*
model with *GitFS *managing our states/pillars.

Is it possible to associate a particular revision (or commit) of my salt
states/pillars with a minion so that until told otherwise, it uses that
version of pillars/states?

Let's say I have tomcat server in each of our dev, qa, stage and production
environments, the version of the WAR file in production might be version
1.0, but dev might be up to 1.2.15 and stage may have 1.0.2. I would like
to make it so that running 'state.highstate' would not change anything
until told to use different state/pillar versions.

So if the current version of our application state in 'dev' is based on:

    - github.com/myrepo/salt-states commit
    734713bc047d87bf7eac9674765ae793478c50d3
    - github.com/myrepo/salt-pillars commit
    893802bc047d87bf7eac9674765ae69a47bc7fdc

It would be interesting if I could somehow set a persistent revision of the
state I want a given minion to use, such as:

#> salt 'tomcat-dev01' state.revision
github.commit=734713bc047d87bf7eac9674765ae793478c50d3

#> salt 'tomcat-dev01' state.highstate


This would lock a minion to a specific revision. The GoCD pipeline could
then archive the commit versions that were used on a per-pipeline basis
allowing me to set a minion to any version of any state. I'm not sure of
the mechanics, especially if there are multiple repositories involved.

Has anyone done something like this with a similar setup
(master-minion+gitfs)? I suspect that I may have to go masterless if I
want to really be able to tie GoCD pipeline revisions to a version of the
salt states). However, I don't want to abandon the master-minion model as
I still want to be able to push critical updates and do monitoring among
other things.

Thoughts?

--
Jeff Vincent
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent

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

  • Colton Myers at May 13, 2015 at 11:27 pm
    Currently, this is not possible*. GitFS only looks up branch refs, you
    can't peg it to a specific commit, nor define a commit to use on a per
    state-run basis. It's an intriguing idea, however!

    *I think you could make it work, though. If you had a tag in your repo for
    each version, those get loaded into gitfs as environments.

    So now you have a "1.0" and "1.2" and "1.0.2" environment. From there it
    gets trickier, because of topfiles. It's easy enough to run a single sls
    from a specific version, just run `salt '*' state.sls myslsfile
    saltenv=1.0`, but gets harder if you want to run a highstate-like structure.

    I would recommend creating a topfile for each environment. The topfile
    doesn't need to be stored in the environment in question, because topfiles
    are treated independent of environments. Each topfile is going to look
    basically the same:

    1.0: # Name of environment, which in this case is your version
       '*': # Target string, just like in a normal topfile
         - firstsls
         - secondsls
         - thirdsls

    Now, assuming this file is called "1-0.sls" (you can't use dots in
    statefile names, because we use them as directory separators), you could
    run it using state.top: `salt '*' state.top 1-0`

    The minions would read that topfile, and correctly only run the specified
    states out of the environment specified in that topfile.

    As you can see, this use case doesn't fit particularly-well into the salt
    paradigm, but it can be made to work.

    Hope that helps!

    --
    Colton Myers
    Platform Engineer, SaltStack
    @basepi on Twitter/Github/IRC

    On Fri, May 8, 2015 at 10:05 PM, Jeff wrote:

    <disclaimer: I'm very new to Salt>

    *Short description:*
    I need some perspective on how to implement a versioned minion state so
    that 'highstate' calls don't deploy new components until told explictly to
    do so.

    *Long Description:*
    We are building a ThoughtWorks GoCD setup to handle continuous deployment.

    In GoCD, every deployment pipeline run is versioned and utilizes versioned
    artifacts or materials (e.g., war, jar, RPM, properties, settings, etc.) as
    part of that version of the pipeline.

    This served as our "rollback" plan at my previous company. If something
    failed when deploying a newer version, we could simply go back and re-run
    the last successful pipeline and it would deploy using the exact same
    artifact versions previously used.

    I was hoping to do something similar at my current job using SaltStack.
    Our initial implementation is currently moving toward the *master-minion*
    model with *GitFS *managing our states/pillars.

    Is it possible to associate a particular revision (or commit) of my salt
    states/pillars with a minion so that until told otherwise, it uses that
    version of pillars/states?

    Let's say I have tomcat server in each of our dev, qa, stage and
    production environments, the version of the WAR file in production might be
    version 1.0, but dev might be up to 1.2.15 and stage may have 1.0.2. I
    would like to make it so that running 'state.highstate' would not change
    anything until told to use different state/pillar versions.

    So if the current version of our application state in 'dev' is based on:

    - github.com/myrepo/salt-states commit
    734713bc047d87bf7eac9674765ae793478c50d3
    - github.com/myrepo/salt-pillars commit
    893802bc047d87bf7eac9674765ae69a47bc7fdc

    It would be interesting if I could somehow set a persistent revision of
    the state I want a given minion to use, such as:

    #> salt 'tomcat-dev01' state.revision
    github.commit=734713bc047d87bf7eac9674765ae793478c50d3

    #> salt 'tomcat-dev01' state.highstate


    This would lock a minion to a specific revision. The GoCD pipeline could
    then archive the commit versions that were used on a per-pipeline basis
    allowing me to set a minion to any version of any state. I'm not sure of
    the mechanics, especially if there are multiple repositories involved.

    Has anyone done something like this with a similar setup
    (master-minion+gitfs)? I suspect that I may have to go masterless if I
    want to really be able to tie GoCD pipeline revisions to a version of the
    salt states). However, I don't want to abandon the master-minion model as
    I still want to be able to push critical updates and do monitoring among
    other things.

    Thoughts?

    --
    Jeff Vincent
    See my LinkedIn profile at:
    http://www.linkedin.com/in/rjeffreyvincent

    --
    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.
  • Jeff at May 13, 2015 at 11:51 pm
    Thanks for the feedback!

    It seems like a bit of a management headache though (square peg, round
    hole).

    Would it be possible to configure minions to connect to a master (allowing
    non-highstate operations), otherwise look locally for it's highstate
    directives?
    On Wed, May 13, 2015 at 5:26 PM, Colton Myers wrote:

    Currently, this is not possible*. GitFS only looks up branch refs, you
    can't peg it to a specific commit, nor define a commit to use on a per
    state-run basis. It's an intriguing idea, however!

    *I think you could make it work, though. If you had a tag in your repo for
    each version, those get loaded into gitfs as environments.

    So now you have a "1.0" and "1.2" and "1.0.2" environment. From there it
    gets trickier, because of topfiles. It's easy enough to run a single sls
    from a specific version, just run `salt '*' state.sls myslsfile
    saltenv=1.0`, but gets harder if you want to run a highstate-like structure.

    I would recommend creating a topfile for each environment. The topfile
    doesn't need to be stored in the environment in question, because topfiles
    are treated independent of environments. Each topfile is going to look
    basically the same:

    1.0: # Name of environment, which in this case is your version
    '*': # Target string, just like in a normal topfile
    - firstsls
    - secondsls
    - thirdsls

    Now, assuming this file is called "1-0.sls" (you can't use dots in
    statefile names, because we use them as directory separators), you could
    run it using state.top: `salt '*' state.top 1-0`

    The minions would read that topfile, and correctly only run the specified
    states out of the environment specified in that topfile.

    As you can see, this use case doesn't fit particularly-well into the salt
    paradigm, but it can be made to work.

    Hope that helps!

    --
    Colton Myers
    Platform Engineer, SaltStack
    @basepi on Twitter/Github/IRC

    On Fri, May 8, 2015 at 10:05 PM, Jeff wrote:

    <disclaimer: I'm very new to Salt>

    *Short description:*
    I need some perspective on how to implement a versioned minion state so
    that 'highstate' calls don't deploy new components until told explictly to
    do so.

    *Long Description:*
    We are building a ThoughtWorks GoCD setup to handle continuous deployment.

    In GoCD, every deployment pipeline run is versioned and utilizes
    versioned artifacts or materials (e.g., war, jar, RPM, properties,
    settings, etc.) as part of that version of the pipeline.

    This served as our "rollback" plan at my previous company. If something
    failed when deploying a newer version, we could simply go back and re-run
    the last successful pipeline and it would deploy using the exact same
    artifact versions previously used.

    I was hoping to do something similar at my current job using SaltStack.
    Our initial implementation is currently moving toward the *master-minion*
    model with *GitFS *managing our states/pillars.

    Is it possible to associate a particular revision (or commit) of my salt
    states/pillars with a minion so that until told otherwise, it uses that
    version of pillars/states?

    Let's say I have tomcat server in each of our dev, qa, stage and
    production environments, the version of the WAR file in production might be
    version 1.0, but dev might be up to 1.2.15 and stage may have 1.0.2. I
    would like to make it so that running 'state.highstate' would not change
    anything until told to use different state/pillar versions.

    So if the current version of our application state in 'dev' is based on:

    - github.com/myrepo/salt-states commit
    734713bc047d87bf7eac9674765ae793478c50d3
    - github.com/myrepo/salt-pillars commit
    893802bc047d87bf7eac9674765ae69a47bc7fdc

    It would be interesting if I could somehow set a persistent revision of
    the state I want a given minion to use, such as:

    #> salt 'tomcat-dev01' state.revision
    github.commit=734713bc047d87bf7eac9674765ae793478c50d3

    #> salt 'tomcat-dev01' state.highstate


    This would lock a minion to a specific revision. The GoCD pipeline could
    then archive the commit versions that were used on a per-pipeline basis
    allowing me to set a minion to any version of any state. I'm not sure of
    the mechanics, especially if there are multiple repositories involved.

    Has anyone done something like this with a similar setup
    (master-minion+gitfs)? I suspect that I may have to go masterless if I
    want to really be able to tie GoCD pipeline revisions to a version of the
    salt states). However, I don't want to abandon the master-minion model as
    I still want to be able to push critical updates and do monitoring among
    other things.

    Thoughts?

    --
    Jeff Vincent
    See my LinkedIn profile at:
    http://www.linkedin.com/in/rjeffreyvincent

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


    --
    Jeff Vincent
    See my LinkedIn profile at:
    http://www.linkedin.com/in/rjeffreyvincent

    --
    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.
  • Florian Ermisch at May 14, 2015 at 6:55 am
    Hi Jeff,

    I think if there's no top.sls (or an empty one) on the master the highstate won't do anything.

    For the local highstate you can look at how the folks running masterless minions are doing this.

    Regards, Florian

    Am 14. Mai 2015 01:51:35 MESZ, schrieb Jeff <predatorvi@gmail.com>:
    Thanks for the feedback!

    It seems like a bit of a management headache though (square peg, round
    hole).

    Would it be possible to configure minions to connect to a master
    (allowing
    non-highstate operations), otherwise look locally for it's highstate
    directives?
    On Wed, May 13, 2015 at 5:26 PM, Colton Myers wrote:

    Currently, this is not possible*. GitFS only looks up branch refs, you
    can't peg it to a specific commit, nor define a commit to use on a per
    state-run basis. It's an intriguing idea, however!

    *I think you could make it work, though. If you had a tag in your repo for
    each version, those get loaded into gitfs as environments.

    So now you have a "1.0" and "1.2" and "1.0.2" environment. From there it
    gets trickier, because of topfiles. It's easy enough to run a single sls
    from a specific version, just run `salt '*' state.sls myslsfile
    saltenv=1.0`, but gets harder if you want to run a highstate-like
    structure.
    I would recommend creating a topfile for each environment. The topfile
    doesn't need to be stored in the environment in question, because topfiles
    are treated independent of environments. Each topfile is going to look
    basically the same:

    1.0: # Name of environment, which in this case is your version
    '*': # Target string, just like in a normal topfile
    - firstsls
    - secondsls
    - thirdsls

    Now, assuming this file is called "1-0.sls" (you can't use dots in
    statefile names, because we use them as directory separators), you could
    run it using state.top: `salt '*' state.top 1-0`

    The minions would read that topfile, and correctly only run the specified
    states out of the environment specified in that topfile.

    As you can see, this use case doesn't fit particularly-well into the salt
    paradigm, but it can be made to work.

    Hope that helps!

    --
    Colton Myers
    Platform Engineer, SaltStack
    @basepi on Twitter/Github/IRC

    On Fri, May 8, 2015 at 10:05 PM, Jeff wrote:

    <disclaimer: I'm very new to Salt>

    *Short description:*
    I need some perspective on how to implement a versioned minion state
    so
    that 'highstate' calls don't deploy new components until told
    explictly to
    do so.

    *Long Description:*
    We are building a ThoughtWorks GoCD setup to handle continuous
    deployment.
    In GoCD, every deployment pipeline run is versioned and utilizes
    versioned artifacts or materials (e.g., war, jar, RPM, properties,
    settings, etc.) as part of that version of the pipeline.

    This served as our "rollback" plan at my previous company. If
    something
    failed when deploying a newer version, we could simply go back and
    re-run
    the last successful pipeline and it would deploy using the exact
    same
    artifact versions previously used.

    I was hoping to do something similar at my current job using
    SaltStack.
    Our initial implementation is currently moving toward the
    *master-minion*
    model with *GitFS *managing our states/pillars.

    Is it possible to associate a particular revision (or commit) of my
    salt
    states/pillars with a minion so that until told otherwise, it uses
    that
    version of pillars/states?

    Let's say I have tomcat server in each of our dev, qa, stage and
    production environments, the version of the WAR file in production
    might be
    version 1.0, but dev might be up to 1.2.15 and stage may have 1.0.2.
    I
    would like to make it so that running 'state.highstate' would not
    change
    anything until told to use different state/pillar versions.

    So if the current version of our application state in 'dev' is based
    on:
    - github.com/myrepo/salt-states commit
    734713bc047d87bf7eac9674765ae793478c50d3
    - github.com/myrepo/salt-pillars commit
    893802bc047d87bf7eac9674765ae69a47bc7fdc

    It would be interesting if I could somehow set a persistent revision
    of
    the state I want a given minion to use, such as:

    #> salt 'tomcat-dev01' state.revision
    github.commit=734713bc047d87bf7eac9674765ae793478c50d3

    #> salt 'tomcat-dev01' state.highstate


    This would lock a minion to a specific revision. The GoCD pipeline
    could
    then archive the commit versions that were used on a per-pipeline
    basis
    allowing me to set a minion to any version of any state. I'm not
    sure of
    the mechanics, especially if there are multiple repositories
    involved.
    Has anyone done something like this with a similar setup
    (master-minion+gitfs)? I suspect that I may have to go masterless
    if I
    want to really be able to tie GoCD pipeline revisions to a version
    of the
    salt states). However, I don't want to abandon the master-minion
    model as
    I still want to be able to push critical updates and do monitoring
    among
    other things.

    Thoughts?

    --
    Jeff Vincent
    See my LinkedIn profile at:
    http://www.linkedin.com/in/rjeffreyvincent

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


    --
    Jeff Vincent
    See my LinkedIn profile at:
    http://www.linkedin.com/in/rjeffreyvincent

    --
    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.
  • Dirk Heinrichs at May 14, 2015 at 7:38 am

    Am 14.05.2015 um 01:26 schrieb Colton Myers:

    I would recommend creating a topfile for each environment.
    As was already said, this is kind of a management headache. Assume
    development of a new formula: It's done on a branch, which automatically
    introduces a new environment. But then one forgets to create a top file
    (entry). This should be automatic, too. In the "Git Pillar" reference
    chapter of the documentation, there's this example configuration (for
    2015.X.Y and above, I think):

    Master config:

    ext_pillar:
        - git: __env__ git://gitserver/git-pillar.git root=pillar


    Pillar top file:

    {{env}}:
        '*':
          - bar

    Something like this should be possible with the states top file, too. It
    can then be put into the repository and only touched when really needed.

    I think the whole gitfs backend thing needs some streamlining accross
    states, pillars, win repos and whatever else may use it.

    Bye...

          Dirk

    --
    Dirk Heinrichs <dirk.heinrichs@altum.de>
    GPG Public Key CB614542 | Jabber: dirk.heinrichs@altum.de
    Tox: heini@toxme.se
    Sichere Internetkommunikation: http://www.retroshare.org
    Privacy Handbuch: https://www.privacy-handbuch.de

    --
    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.
  • Jeff at May 14, 2015 at 9:22 pm
    Thanks for the additional comments. <And sorry for all my questions...I'm
    really trying to learn while trying to define a process that works.>

    I guess what I'm hoping for is a mixed mode and I *think* that maybe it's
    possible. Or maybe a better description is to have a mix of dynamic and
    static states/pillars where the dynamic states come from gitfs and the
    static states are on the file system.

    For example. Let's say I have a cluster of tomcat7 servers. I could
    possibly manage the global states via the salt-master (via gitfs_remotes)
    but have application-specific states 'statically' on the file system and
    updated via the CI/CD process. Could I have the following:

    States from master (top.sls in GitFS):

    base:
       #All Ubuntu VM's

       'G@os:Ubuntu':

         - openssh-server

         - salt-minion

         - open-vm-tools

         - users

         - sudoers

       'G@role:tomcat7':
         #All Nodes with grain 'role:tomcat7'
         - java7 (required by tomcat7)
         - tomcat7

    Some thoughts on handling the "application states" might include:

        - Local file_roots on salt-master:
           - Store application-specific pillar and state files in Git but NOT
           configured as a gitfs_remotes.
           - Then in the continuous deployment process
              - Pull application-specific states/pillars from Git
              - Update app-specific states/pillars with build-specific info (war
              version, properties version, etc.)
              - Commit changes to Git
              - Copy app-specific pillar/state files to salt-master file_root
              - Initiate state.highstate for the affected minions

    This this case, the top.sls could potentially have this defined and the
    states/pillars would come from the file system and updated remotely from
    CI/CD:


       'G@role:mywebapp' #
         #All vm's specifically configured to run MyWebApp
         - mywebapp



        - Local file_roots on salt-minion:
           - Same as above with the following exceptions
              - Copies pillar/state files to each minion
              - Initiates local highstate (e.g., 'salt-call --local
              state.highstate' ) for each minion

    For this case, I don't know if I can use top.sls and grains, but may have
    to target the specific state needed such as 'salt-call --local state.sls
    mywebapp'.

    Are there Any other options?

    Am I thinking about this properly?

    For the local minion state, if the master initiates the 'state.highstate'
    (e.g., to update the version of open-ssh), will the local 'mywebapp' states
    get removed or otherwise affected?

    Thanks!

    On Thu, May 14, 2015 at 1:38 AM, Dirk Heinrichs wrote:

    Am 14.05.2015 um 01:26 schrieb Colton Myers:

    I would recommend creating a topfile for each environment.
    As was already said, this is kind of a management headache. Assume
    development of a new formula: It's done on a branch, which automatically
    introduces a new environment. But then one forgets to create a top file
    (entry). This should be automatic, too. In the "Git Pillar" reference
    chapter of the documentation, there's this example configuration (for
    2015.X.Y and above, I think):

    Master config:

    ext_pillar:
    - git: __env__ git://gitserver/git-pillar.git root=pillar


    Pillar top file:

    {{env}}:
    '*':
    - bar

    Something like this should be possible with the states top file, too. It
    can then be put into the repository and only touched when really needed.

    I think the whole gitfs backend thing needs some streamlining accross
    states, pillars, win repos and whatever else may use it.

    Bye...

    Dirk

    --
    Dirk Heinrichs <dirk.heinrichs@altum.de>
    GPG Public Key CB614542 | Jabber: dirk.heinrichs@altum.de
    Tox: heini@toxme.se
    Sichere Internetkommunikation: http://www.retroshare.org
    Privacy Handbuch: https://www.privacy-handbuch.de


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


    --
    Jeff Vincent
    See my LinkedIn profile at:
    http://www.linkedin.com/in/rjeffreyvincent

    --
    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.
  • Colton Myers at May 20, 2015 at 9:52 pm
    I haven't had time to really think about all the ins and outs of this
    approach, but I think you're on the right track. It's an interesting idea,
    mixing masterless and master setups!

    For the local minion state, if the master initiates the 'state.highstate'
    (e.g., to update the version of open-ssh), will the local 'mywebapp' states
    get removed or otherwise affected?

    It shouldn't.

    --
    Colton Myers
    Platform Engineer, SaltStack
    @basepi on Twitter/Github/IRC
    On Thu, May 14, 2015 at 3:22 PM, Jeff wrote:

    Thanks for the additional comments. <And sorry for all my questions...I'm
    really trying to learn while trying to define a process that works.>

    I guess what I'm hoping for is a mixed mode and I *think* that maybe it's
    possible. Or maybe a better description is to have a mix of dynamic and
    static states/pillars where the dynamic states come from gitfs and the
    static states are on the file system.

    For example. Let's say I have a cluster of tomcat7 servers. I could
    possibly manage the global states via the salt-master (via gitfs_remotes)
    but have application-specific states 'statically' on the file system and
    updated via the CI/CD process. Could I have the following:

    States from master (top.sls in GitFS):

    base:
    #All Ubuntu VM's

    'G@os:Ubuntu':

    - openssh-server

    - salt-minion

    - open-vm-tools

    - users

    - sudoers

    'G@role:tomcat7':
    #All Nodes with grain 'role:tomcat7'
    - java7 (required by tomcat7)
    - tomcat7

    Some thoughts on handling the "application states" might include:

    - Local file_roots on salt-master:
    - Store application-specific pillar and state files in Git but NOT
    configured as a gitfs_remotes.
    - Then in the continuous deployment process
    - Pull application-specific states/pillars from Git
    - Update app-specific states/pillars with build-specific info
    (war version, properties version, etc.)
    - Commit changes to Git
    - Copy app-specific pillar/state files to salt-master file_root
    - Initiate state.highstate for the affected minions

    This this case, the top.sls could potentially have this defined and the
    states/pillars would come from the file system and updated remotely from
    CI/CD:


    'G@role:mywebapp' #
    #All vm's specifically configured to run MyWebApp
    - mywebapp



    - Local file_roots on salt-minion:
    - Same as above with the following exceptions
    - Copies pillar/state files to each minion
    - Initiates local highstate (e.g., 'salt-call --local
    state.highstate' ) for each minion

    For this case, I don't know if I can use top.sls and grains, but may have
    to target the specific state needed such as 'salt-call --local state.sls
    mywebapp'.

    Are there Any other options?

    Am I thinking about this properly?

    For the local minion state, if the master initiates the 'state.highstate'
    (e.g., to update the version of open-ssh), will the local 'mywebapp' states
    get removed or otherwise affected?

    Thanks!

    On Thu, May 14, 2015 at 1:38 AM, Dirk Heinrichs wrote:

    Am 14.05.2015 um 01:26 schrieb Colton Myers:

    I would recommend creating a topfile for each environment.
    As was already said, this is kind of a management headache. Assume
    development of a new formula: It's done on a branch, which automatically
    introduces a new environment. But then one forgets to create a top file
    (entry). This should be automatic, too. In the "Git Pillar" reference
    chapter of the documentation, there's this example configuration (for
    2015.X.Y and above, I think):

    Master config:

    ext_pillar:
    - git: __env__ git://gitserver/git-pillar.git root=pillar


    Pillar top file:

    {{env}}:
    '*':
    - bar

    Something like this should be possible with the states top file, too. It
    can then be put into the repository and only touched when really needed.

    I think the whole gitfs backend thing needs some streamlining accross
    states, pillars, win repos and whatever else may use it.

    Bye...

    Dirk

    --
    Dirk Heinrichs <dirk.heinrichs@altum.de>
    GPG Public Key CB614542 | Jabber: dirk.heinrichs@altum.de
    Tox: heini@toxme.se
    Sichere Internetkommunikation: http://www.retroshare.org
    Privacy Handbuch: https://www.privacy-handbuch.de


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


    --
    Jeff Vincent
    See my LinkedIn profile at:
    http://www.linkedin.com/in/rjeffreyvincent

    --
    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.
  • Les Mikesell at May 20, 2015 at 10:32 pm

    On Wed, May 20, 2015 at 4:52 PM, Colton Myers wrote:
    I haven't had time to really think about all the ins and outs of this
    approach, but I think you're on the right track. It's an interesting idea,
    mixing masterless and master setups!
    I haven't seen anything that quite makes sense yet in terms of version
    management and rollback capability. My vision would be something like
    having a lab master and production master both using the same
    subversion repository for piller and file roots, but with the
    production system rooted at different paths. And, at least by
    convention, the only way things would be moved to the production paths
    would be a tagging type operation. This might make more sense if you
    could target path@revision (as frequently used in subversion) instead
    of needing to create arbitrary tag names or only being able to see the
    HEAD version of branches, though.

    --
        Les Mikesell
          lesmikesell@gmail.com

    --
    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 @
postedMay 9, '15 at 4:06a
activeMay 20, '15 at 10:32p
posts8
users5

People

Translate

site design / logo © 2021 Grokbase