FAQ
Hello,

I follow this group for some time already and was planning to use salt
for my small little project at home, where I only need a form of two-way
communication between a master server and 3 or 4 clients. What I liked
is the simple way of adding new minions (to a salt setup) and the used
protocol & security. All I need in the end would be a set (API) of my
own well known commands between the master and the clients and I do not
need many extra features, nor state management and configurations. I
would love to deactivate most of the modules for security reasons and
only allow a whitelist of certain modules.

Implementing the basic communication and security would be possible but
I'd like to save me this time. Now I also read about a lot of bugs (as
well as today the thread about the readiness of salt matching my own
impression from this group). Now I'm really doubting if I should
continue with salt or find another solution without such many obviously
not reliably working ballast. So ...

- Is there a better project for me?
- Is salt enough for my wishes and I should simply ignore the bugs in
features I won't need?

Any tips and opinions welcome. Thx!

BTW: I also would love to see Python 3 support :-)

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

  • Wolodja Wentland at Aug 6, 2014 at 12:42 pm
    Hello Thomas,
    On Wed, Aug 06, 2014 at 13:17 +0300, Thomas Wanderer wrote:

    All I need in the end would be a set (API) of my own well known commands
    between the master and the clients and I do not need many extra features, nor
    state management and configurations. I would love to deactivate most of the
    modules for security reasons and only allow a whitelist of certain modules.
    I am sure that salt will more than satisfy your needs regarding this. If writing
    states with the built-in functionality it is also quite easy to develop your own
    modules and states in Python and distribute those to your minions. We use that
    frequently to implement states that are specific to our setup or to allow us to
    call certain functionality in our own software.
    Now I also read about a lot of bugs (as well as today the thread about the
    readiness of salt matching my own impression from this group). Now I'm really
    doubting if I should continue with salt or find another solution without such
    many obviously not reliably working ballast. So ...
    We have been using salt for more than eight months now and ran into very few
    bugs that actually caused us actual problems.

    As a person used to the way releases are tested and made available to users in
    Debian I would rather argue that salt has problems to properly test and cut their
    releases. There were some bugs that should have never made it into a stable
    branch, but it is sometimes hard to catch these problems without the additional
    testing you get from making it available to a larger user base.

    There are probably a couple of things that can be done about this:

    1. Packages for salt in production should not be installed from a single
        repository to which packages of new releases are uploaded

        This is already done for some distributions with -testing, but is
        unfortunately not the case for Debian packages (and a few other I would
        belive). In the case of Debian I really don't understand why salt packagers
        are maintaining their own repository (without suites and controlled
        transitions) rather than rely on established Debian infrastructure such as
        unstable/testing and wheezy-backports.

        People should *only* install packages from wheezy or wheezy-backports and the
        safeguards that are already in place to control what transitions from
        unstable to testing don't have to be replicated needlessly.

    2. Salt should probably have more tests that are based on actual setups found in
        the wild.

        I am not entirely sure how one could test this (and would like to implement
        it myself), but a bit of black-box testing "run these states so that you are
        able to fetch webpage $FOO from http://..." would probably be enough to catch
        a lot of problems here.

    3. I think salt needs to be more rigorous in testing code that is being merged
        and there should, probably, be always be more than one person involved when
        contributions are accepted (also internal changes)

        This might sound horribly familiar and I am indeed thinking of a development
        model like that used for the Linux kernel in which *only* people who know
        a particular piece of code will merge changes to that piece.

        Yes, this makes things slower. Yes, this isn't nearly as hip as clicking
        "merge PR". But in the end it might allow for higher quality releases.

    I realise that I have probably taken over your thread and apologise for that, so
    to come back to your actual question: I would say that salt is mature enough to
    be used in production (we wouldn't have used it otherwise), but there is always
    room for improvement
    --
    Wolodja <babilen@gmail.com>

    4096R/CAF14EFC
    081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
  • Thomas Wanderer at Aug 6, 2014 at 2:31 pm

    Am 06.08.2014 um 15:42 schrieb Wolodja Wentland:
    I am sure that salt will more than satisfy your needs regarding this. If writing
    states with the built-in functionality it is also quite easy to develop your own
    modules and states in Python and distribute those to your minions. We use that
    frequently to implement states that are specific to our setup or to allow us to
    call certain functionality in our own software.
    I was thinking of this or using the cmd module. I'm more or less only
    interested in my own lets say stable "event" or "messaging" API between
    masters and minions and am/was afraid that the overhead of too many
    modules might cause keeping blacklist of modules constantly up to date
    to avoid too many interaction and remote execution possibilities.

    I would really love to see a separation into a "SALT LIGHT" (which would
    ship the communication layer together with secure handshake and
    subsequent encryption + the opportunity to add my own modules) and a
    "SALT MODULES" package.

    1. Packages for salt in production should not be installed from a single
    repository to which packages of new releases are uploaded

    This is already done for some distributions with -testing, but is
    unfortunately not the case for Debian packages (and a few other I would
    belive). In the case of Debian I really don't understand why salt packagers
    are maintaining their own repository (without suites and controlled
    transitions) rather than rely on established Debian infrastructure such as
    unstable/testing and wheezy-backports.

    People should *only* install packages from wheezy or wheezy-backports and the
    safeguards that are already in place to control what transitions from
    unstable to testing don't have to be replicated needlessly.
    Thx for that hint. I'm working with Debian Stable and was planning to
    use the "http://debian.saltstack.com/debian
    {debian}-saltstack{saltversion} main" repository. So you would advice to
    use only the backport one?



    --
    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.
  • Wolodja Wentland at Aug 6, 2014 at 4:39 pm

    On Wed, Aug 06, 2014 at 17:29 +0300, Thomas Wanderer wrote:
    Am 06.08.2014 um 15:42 schrieb Wolodja Wentland:
    I would really love to see a separation into a "SALT LIGHT" (which would
    ship the communication layer together with secure handshake and
    subsequent encryption + the opportunity to add my own modules) and a
    "SALT MODULES" package.
    I understand your wish and agree that it might fill a different niche.
    People should *only* install packages from wheezy or wheezy-backports and the
    safeguards that are already in place to control what transitions from
    unstable to testing don't have to be replicated needlessly.
    Thx for that hint. I'm working with Debian Stable and was planning to
    use the "http://debian.saltstack.com/debian
    {debian}-saltstack{saltversion} main" repository. So you would advice to
    use only the backport one?
    No, I am not currently advising you to do that. It would be good if doing so was
    a suitable option, but for now you will have to use the saltstack repository.
    --
    Wolodja <babilen@gmail.com>

    4096R/CAF14EFC
    081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
  • Joe Healy at Aug 6, 2014 at 3:21 pm
    Hello babilen,

    At the risk of hijacking further, I'm going to add to the packaging
    discussion you've opened up.

    To the original poster, salt is very useable in production - some care is
    required around new releases, but the benefits definitely outway the risks.
    On Wed, Aug 6, 2014 at 10:42 PM, Wolodja Wentland wrote:


    As a person used to the way releases are tested and made available to
    users in
    Debian I would rather argue that salt has problems to properly test and
    cut their
    releases. There were some bugs that should have never made it into a stable
    branch, but it is sometimes hard to catch these problems without the
    additional
    testing you get from making it available to a larger user base.
    I completely agree.

    There are probably a couple of things that can be done about this:

    1. Packages for salt in production should not be installed from a single
    repository to which packages of new releases are uploaded

    This is already done for some distributions with -testing, but is
    unfortunately not the case for Debian packages (and a few other I would
    belive). In the case of Debian I really don't understand why salt
    packagers
    are maintaining their own repository (without suites and controlled
    transitions) rather than rely on established Debian infrastructure such
    as
    unstable/testing and wheezy-backports.

    People should *only* install packages from wheezy or wheezy-backports
    and the
    safeguards that are already in place to control what transitions from
    unstable to testing don't have to be replicated needlessly.

    I mostly agree.
    I believe that for any sizeable deployment, the owners should strictly
    control which salt packages are used and available in the deployment. If
    any errors are going to be difficult to recover from, they should test any
    new packages/releases in a small environment before pushing them out
    everywhere.

    The debian.saltstack.com site dates back to a time when we (the salt
    community) were not able to get packages into debian releases reliably. It
    also fills the need of providing packages for previous releases. It will
    also provide space when rc packages for the next release that are
    definitely going to be to raw even for debian unstable - maybe they could
    go to experimental though.

    I'm not sure that only installing from wheezy or wheezy-backports covers
    everyones needs. As the packager I roughly control/decide when packages go
    into these locations. However I imagine this causes difficulties for people
    when a major release goes through. Maybe people can use archive.debian.org
    which I believe can be "pinned" to a particular date.

    On the other hand, the other aspect "protecting" wheezy-backports is I
    never upload a backport to there till I'm happy to run it in production. Ie
    I waited until 0.17.5 before uploading a backport for 0.17.x to the
    official location. I haven't yet uploaded a 2014.1 backport, though am
    expecting to do so once 2014.1.10 goes into testing. I could legitimately
    be criticised for this approach, but feel that I want to maintain a level
    of conservatism for the official backports.

    From my (dayjob) perspective, we use debian.saltstack.com, but I definitely
    warn our admins when I am about to upload a new package to there. I also
    make sure they wait a few days or take care with any deployments shortly
    following a new release. I do some limited testing before uploading, but
    this is really just checking the real basics.

    I think that the delay process might be useful for the debian.saltstack
    site - though doing so may increase my workload a little. It is worth
    thinking about anyway. Having a -stable set of repositories that packages
    only enter after a delay may be worthwhile.
    Whether that would "split" the user base and mean that not enough testing
    occurred on the new releases, I don't know? Maybe worth a trial or survey.

    Anyway, just some rambling thoughts - main take away is I don't think
    wheezy and wheezy-backports covers everyones needs.

    I'm interested in getting feedback on the testing/delay idea on
    debian.saltstack.com. Would people use that? Is it worth doing?

    cheers,

    Joe



    aken over your thread and apologise for that, so
    to come back to your actual question: I would say that salt is mature
    enough to
    be used in production (we wouldn't have used it otherwise), but there is
    always
    room for improvement
    --
    Wolodja <babilen@gmail.com>

    4096R/CAF14EFC
    081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
    --
    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.
  • Ryan Lane at Aug 6, 2014 at 6:02 pm

    On Wed, Aug 6, 2014 at 3:17 AM, Thomas Wanderer wrote:

    Hello,

    I follow this group for some time already and was planning to use salt
    for my small little project at home, where I only need a form of two-way
    communication between a master server and 3 or 4 clients. What I liked
    is the simple way of adding new minions (to a salt setup) and the used
    protocol & security. All I need in the end would be a set (API) of my
    own well known commands between the master and the clients and I do not
    need many extra features, nor state management and configurations. I
    would love to deactivate most of the modules for security reasons and
    only allow a whitelist of certain modules.

    Implementing the basic communication and security would be possible but
    I'd like to save me this time. Now I also read about a lot of bugs (as
    well as today the thread about the readiness of salt matching my own
    impression from this group). Now I'm really doubting if I should
    continue with salt or find another solution without such many obviously
    not reliably working ballast. So ...

    - Is there a better project for me?
    - Is salt enough for my wishes and I should simply ignore the bugs in
    features I won't need?
    I used Salt at Wikimedia since before 0.17 just using remote execution and
    ran into very few bugs, across many, many upgrades.

    You can restrict access to only the cmd (and any other) module, if that's
    what you really want:


    http://docs.saltstack.com/en/latest/ref/configuration/master.html#client-acl

    You can also blacklist specific ones:


    http://docs.saltstack.com/en/latest/ref/configuration/master.html#client-acl-blacklist

    - Ryan

    --
    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 Aug 6, 2014 at 6:28 pm

    On Wed, Aug 6, 2014 at 5:17 AM, Thomas Wanderer wrote:
    I follow this group for some time already and was planning to use salt
    for my small little project at home, where I only need a form of two-way
    communication between a master server and 3 or 4 clients. What I liked
    is the simple way of adding new minions (to a salt setup) and the used
    protocol & security. All I need in the end would be a set (API) of my
    own well known commands between the master and the clients and I do not
    need many extra features, nor state management and configurations. I
    would love to deactivate most of the modules for security reasons and
    only allow a whitelist of certain modules.
    - Is there a better project for me?
    That depends very much on what you want the clients to do and what
    would trigger it. If it maps into running 'jobs' with the master
    collating the results or acting as transfer point, 'jenkins' might be
    a good fit even though you usually think of it just as a build system.
    It is nicely cross-platform and can run over ssh if you like. Or if
    your work is simple enough, ssh can drive about anything remotely by
    itself,

    --
        Les Mikesell
          lesmiksell@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.
  • John Spray at Aug 7, 2014 at 11:15 am

    On Wed, Aug 6, 2014 at 11:17 AM, Thomas Wanderer wrote:
    - Is there a better project for me?
    Not that I know of.
    - Is salt enough for my wishes and I should simply ignore the bugs in
    features I won't need?
    Yep! We used salt this way in a tool called Calamari for managing
    Ceph storage clusters, essentially for the same reasons you're
    mentioning. Along the way we already fixed some bugs for you :-)
    Grep our source for salt to see how we interact with it:
    https://github.com/ceph/calamari

    John

    --
    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.
  • Thomas Wanderer at Aug 7, 2014 at 12:40 pm
    I'm aware that there are many solutions and even Jenkins might fit my
    needs in a way, btw. thx hor the tips from all the pre-posters. But so
    far I like salts protocol :-) I guess I will just whitelist a few
    modules then and try to block all the other features. Still the idea of
    salt-light sounds really charming for me.
    Yep! We used salt this way in a tool called Calamari for managing
    Ceph storage clusters, essentially for the same reasons you're
    mentioning. Along the way we already fixed some bugs for you :-)
    Grep our source for salt to see how we interact with it:
    https://github.com/ceph/calamari
    Thx a lot for the link! I will have a look!


    --
    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 Aug 7, 2014 at 2:39 pm

    On Thu, Aug 7, 2014 at 7:39 AM, Thomas Wanderer wrote:
    I'm aware that there are many solutions and even Jenkins might fit my
    needs in a way, btw. thx hor the tips from all the pre-posters. But so
    far I like salts protocol :-) I guess I will just whitelist a few
    modules then and try to block all the other features. Still the idea of
    salt-light sounds really charming for me.
    Yep! We used salt this way in a tool called Calamari for managing
    Ceph storage clusters, essentially for the same reasons you're
    mentioning. Along the way we already fixed some bugs for you :-)
    Grep our source for salt to see how we interact with it:
    https://github.com/ceph/calamari
    Thx a lot for the link! I will have a look!
    One thing I consider a big win for jenkins for the cases where it fits
    at all is the generic central web user/rest interface to control it
    and access the state and history. If you already use jenkins for one
    kind of job it is trivial to learn how to make it do something wildly
    different with the same automation framework and version control
    infrastructure. At first glance, it looks like that calamari tool is
    the sort of special-case framework that you need to build for salt
    interaction - with the tradeoffs/advnatages you get with special case
    tools.

    --
         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.
  • John Spray at Aug 7, 2014 at 4:27 pm

    On Thu, Aug 7, 2014 at 3:39 PM, Les Mikesell wrote:
    At first glance, it looks like that calamari tool is
    the sort of special-case framework that you need to build for salt
    interaction - with the tradeoffs/advnatages you get with special case
    tools.
    That's correct, - as I said, Calamari is a tool for managing Ceph
    storage clusters - it's not a general purpose thing. I was posting it
    as an example of the kind of (special purpose) thing that can be built
    on top of (general purpose) salt.

    Cheers,
    John

    --
    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 6, '14 at 10:25a
activeAug 7, '14 at 4:27p
posts11
users6

People

Translate

site design / logo © 2022 Grokbase