FAQ
Hi all,

I'm trying to further my understanding of the Orchestrate runner, and the
way salt can use dependencies and ordering across boxes. For an example,
imagine a legacy .NET MVC based web app, with multiple IIS nodes up front,
some batch processing nodes and a monolithic SQL Server DB. I might create
build artifacts for each of these out of a pipeline:

* bin folder for the web app (wrapped in a chocolatey package or MSI etc)
* bin folder for some back end windows services (wrapped in a chocolatey
package or MSI etc)
* xml config and sql scripts for the database (checks for changes or
explicitly versioned)

The nature of the dependencies might be:

* If the database requires an upgrade, we want to stop processing new batch
processing tasks, and wait until the current ones are done
* When we're ready to go, redirect to a maintenance message at the front end
* Kick off the upgrade of all 3 layers in parallel

Importantly, in this example if no DB upgrade is required, there's no need
to pause the batch tasks. It might be a simple upgrade of the web nodes, or
one of the batch processing services.

Reading through the doco
<http://docs.saltstack.com/en/latest/topics/tutorials/states_pt5.html#function> on
the orchestrate runner, it looks like there's 2 tools available, functions
and state. I'm trying to understand how the type of scenario I've described
here fits into these 2 approaches. It seems like I need a combination of
the 2. For example:

* Use state to find out if component x is out of date/requires an upgrade
* If so, use a function to send a message to another node

That seems like an awkward combination? Are there any examples around that
cover this in more detail? Obviously the monolithic architecture is the
major problem here, and everything would be easier without so many
dependencies between the nodes, but that's not a realistic change right now.

I've found this post, which mentions inter minion messaging, but that seems
like it might get messy to manage:

https://groups.google.com/forum/#!searchin/salt-users/orchestrate/salt-users/q3A_Kx6gZCg/BqEFZCVKniMJ

Any thoughts or suggestions would be really appreciated.

Cheers,

Eddie

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

  • Florian Ermisch at Aug 8, 2015 at 8:04 am
    Hi Eddie,

    I would rather have a function checking if the DB-upgrade is necessary and then a bunch of states depending on each other:


    - - stop accepting be batches
       is requisite for
         - redirect to maintenance page
           is requisite for
             - stopping frontend
             - stopping workers
               is requisite for
                 - updating DB
                   is requisite for
                   - deploying new pkgs
                      is requisite for
                        - starting services

    You could also define a state that fails when the DB isn't up-to-date and only if this fails the other states are run.

    I haven't really tried tying my states together using the orchestrator yet so this is based on my theoretical understanding how Salt works in general ;)

    Regards, Florian

    Am 8. August 2015 09:13:34 MESZ, schrieb Eddie Sholl <eddie.sholl@gmail.com>:
    Hi all,

    I'm trying to further my understanding of the Orchestrate runner, and
    the
    way salt can use dependencies and ordering across boxes. For an
    example,
    imagine a legacy .NET MVC based web app, with multiple IIS nodes up
    front,
    some batch processing nodes and a monolithic SQL Server DB. I might
    create
    build artifacts for each of these out of a pipeline:

    * bin folder for the web app (wrapped in a chocolatey package or MSI
    etc)
    * bin folder for some back end windows services (wrapped in a
    chocolatey
    package or MSI etc)
    * xml config and sql scripts for the database (checks for changes or
    explicitly versioned)

    The nature of the dependencies might be:

    * If the database requires an upgrade, we want to stop processing new
    batch
    processing tasks, and wait until the current ones are done
    * When we're ready to go, redirect to a maintenance message at the
    front end
    * Kick off the upgrade of all 3 layers in parallel

    Importantly, in this example if no DB upgrade is required, there's no
    need
    to pause the batch tasks. It might be a simple upgrade of the web
    nodes, or
    one of the batch processing services.

    Reading through the doco
    <http://docs.saltstack.com/en/latest/topics/tutorials/states_pt5.html#function>
    on
    the orchestrate runner, it looks like there's 2 tools available,
    functions
    and state. I'm trying to understand how the type of scenario I've
    described
    here fits into these 2 approaches. It seems like I need a combination
    of
    the 2. For example:

    * Use state to find out if component x is out of date/requires an
    upgrade
    * If so, use a function to send a message to another node

    That seems like an awkward combination? Are there any examples around
    that
    cover this in more detail? Obviously the monolithic architecture is the

    major problem here, and everything would be easier without so many
    dependencies between the nodes, but that's not a realistic change right
    now.

    I've found this post, which mentions inter minion messaging, but that
    seems
    like it might get messy to manage:

    https://groups.google.com/forum/#!searchin/salt-users/orchestrate/salt-users/q3A_Kx6gZCg/BqEFZCVKniMJ

    Any thoughts or suggestions would be really appreciated.

    Cheers,

    Eddie

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedAug 8, '15 at 7:13a
activeAug 8, '15 at 8:04a
posts2
users2

2 users in discussion

Eddie Sholl: 1 post Florian Ermisch: 1 post

People

Translate

site design / logo © 2022 Grokbase