FAQ
We (LinkedIn) use the 3rd option. However, we do encourage people to setup
the dev environment (virtualenv) on their dekstops (and/or laptops). Our
current VM env is 10 total "hosts" all RHEL 6. (We are adding a couple of
Solaris installs to balance with what we have in production.)

We have several environments for our files roots: dev, vm, test, stage,
prod. (Prod is, more or less, 'base'.)

All of those files are checked in to svn. When someone wants to update a
module or state file, they progress it thru the various envs.

Personally, I do a fair amount of testing on my own and I use several
virtualbox VMs. I have a script that (almost) creates them completely
unattended. I am planning on getting that checked in to salt-contrib very
soon.


On Sun, Jun 22, 2014 at 10:28 AM, Alex Leonhardt wrote:

I think I personally would prefer the 3rd option, but, I've been thinking
about the same earlier and was hence sending a different question to this
list re syntax checking sls and jinja templates - then I found this :

https://gist.github.com/alecthomas/4497119

it does some checking and walks the entire tree - one could re-use that
and make a vim checker or something ... not sure ..

anyway, in regards to developing (anything|states), I usually have a local
master and minion and destroy my minion after every development and start
from scratch (also for testing) ...

you probably want to use gitfs though ? :) ... for my testing/developing
I just use plain old local files until it's good enough to go anywhere ..


Alex


On 22 June 2014 18:03, Michael Slattery wrote:

How do people develop and debug states (.sls)? I haven't been able to
find tutorials that discuss best practices.

I've come up with 3 ways

1. The most obvious way is to make changes to /srv/salt on the master and
run state.highstate. Perhaps use svnfs and svn_pillar for deployment. But
this way goes against everything I've ever learned about how best to
develop scripts in any language.

2. Test locally. This is the way I do it:
- Use svnfs and svn_pillar on the master
- SVN checkout into some sort of sandbox (e.g. VM, chroot, or sandboxie)
- test locally: salt_call --config-dir=myconf state.highstate

And here is part of my conf/minion config file:
file_client: local
root_dir: '.'
file_roots:
base:
- states
pillar_roots:
base:
- pillar
extension_modules: modules
id: devhost

Layout of my development directory:
bin/ (convenience scripts)
conf/ (minion file)
states/
pillar/
var/ (ignored by SVN)

I do it this way because it's very lightweight.

3. A heavyweight way that's a bit closer to a production setup:
- Create VM running salt-master
- Create VM running salt-minion (id=devhost)
- On salt-master, SVN checkout in /srv/salt and /srv/pillar
- On salt-master run: salt 'devhost' state.highstate


How do you do it?

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

Search Discussions

  • Alex Graham at Jun 30, 2014 at 5:09 pm
    We use something closer to option 3.

    We have a production master and a dev master. All files on both are kept in
    git. The dev master has a few minions of various distros for testing.
    Development and testing of states is done in local clones of the git repo,
    pushed to the dev master and tested on dev minions. Once it's verified,
    it's pushed to the salt master, where it's tested again, but not yet
    implemented. Once it's been tested against production minions and passed
    code-review, it's merged into the master git branch and implemented for
    production minions.

    Yes, it's got a few extra steps, but doing it this way ensures that our
    production salt master and our production master git branch are
    consistently working and that anyone can run highstate on a minion whenever
    they want and get a valid config.

    The only difficulty we've found is that only one person can be testing on
    the dev master at a time. Using vagrant (or something else) to spin up a
    few test VMs would get around that, but minions in our environment are
    dozens of different distros and versions, so that's a little more difficult.



    On Sunday, June 22, 2014 10:03:16 AM UTC-7, Michael Slattery wrote:

    How do people develop and debug states (.sls)? I haven't been able to
    find tutorials that discuss best practices.

    I've come up with 3 ways

    1. The most obvious way is to make changes to /srv/salt on the master and
    run state.highstate. Perhaps use svnfs and svn_pillar for deployment. But
    this way goes against everything I've ever learned about how best to
    develop scripts in any language.

    2. Test locally. This is the way I do it:
    - Use svnfs and svn_pillar on the master
    - SVN checkout into some sort of sandbox (e.g. VM, chroot, or sandboxie)
    - test locally: salt_call --config-dir=myconf state.highstate

    And here is part of my conf/minion config file:
    file_client: local
    root_dir: '.'
    file_roots:
    base:
    - states
    pillar_roots:
    base:
    - pillar
    extension_modules: modules
    id: devhost

    Layout of my development directory:
    bin/ (convenience scripts)
    conf/ (minion file)
    states/
    pillar/
    var/ (ignored by SVN)

    I do it this way because it's very lightweight.

    3. A heavyweight way that's a bit closer to a production setup:
    - Create VM running salt-master
    - Create VM running salt-minion (id=devhost)
    - On salt-master, SVN checkout in /srv/salt and /srv/pillar
    - On salt-master run: salt 'devhost' state.highstate


    How do you do it?
    --
    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 @
postedJun 30, '14 at 2:10a
activeJun 30, '14 at 5:09p
posts2
users2

2 users in discussion

Craig Sebenik: 1 post Alex Graham: 1 post

People

Translate

site design / logo © 2022 Grokbase