FAQ
I'm not sure how to best organise configuration within states. The YAML
data has a certain hierarchy imposed on it by the fact that every key must
be unique. So it seems natural to do this:

haproxy:
   pkg:
     - installed
     - provider: pkgng
     - name: haproxy
   service:
     - name: haproxy
     - running
     - enable: True
     - reload: True
   file:
     - managed
     - name: /usr/local/etc/haproxy.conf
     - source: salt://haproxy/templates/haproxy.conf
     - template: jinja
     - require:
       - pkg: haproxy
     - watch_in:
       - service: haproxy


However, this breaks as soon as I want to add a second file, which cannot
also have a key of "file". So then I end up with:

haproxy-pkg:
   - pkg:
     - installed
     - provider: pkgng
     - name: haproxy

haproxy-service:
   service:
     - name: haproxy
     - running
     - enable: True
     - reload: True

/usr/local/etc/haproxy.conf:
     - file.managed
     - source: salt://haproxy/templates/haproxy.conf
     - template: jinja
     - require:
       - pkg: haproxy-pkg
     - watch_in:
       - service: haproxy-service


But now I've lost all namespace ( the hierarchy of the YAML) and just end
up with using hyphens in the key as a way to group my states and services.

I'm confused by the two completely different approaches to configuration.
What is the best way to arrange states so that they don't get confusing as
my configuration grows?


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

  • Ryan Lane at Jan 16, 2015 at 5:40 pm

    On Thu, Jan 15, 2015 at 8:28 PM, Ari Maniatis wrote:

    I'm not sure how to best organise configuration within states. The YAML
    data has a certain hierarchy imposed on it by the fact that every key must
    be unique. So it seems natural to do this:

    haproxy:
    pkg:
    - installed
    - provider: pkgng
    - name: haproxy
    service:
    - name: haproxy
    - running
    - enable: True
    - reload: True
    file:
    - managed
    - name: /usr/local/etc/haproxy.conf
    - source: salt://haproxy/templates/haproxy.conf
    - template: jinja
    - require:
    - pkg: haproxy
    - watch_in:
    - service: haproxy


    However, this breaks as soon as I want to add a second file, which cannot
    also have a key of "file". So then I end up with:
    Indeed. Though the docs show this style as an example pretty often, it's
    not a great way to organize your sls.

    haproxy-pkg:
    - pkg:
    - installed
    - provider: pkgng
    - name: haproxy

    haproxy-service:
    service:
    - name: haproxy
    - running
    - enable: True
    - reload: True

    /usr/local/etc/haproxy.conf:
    - file.managed
    - source: salt://haproxy/templates/haproxy.conf
    - template: jinja
    - require:
    - pkg: haproxy-pkg
    - watch_in:
    - service: haproxy-service


    But now I've lost all namespace ( the hierarchy of the YAML) and just end
    up with using hyphens in the key as a way to group my states and services.

    I'm confused by the two completely different approaches to configuration.
    What is the best way to arrange states so that they don't get confusing as
    my configuration grows?
    You organize your sls as modules. Your haproxy config goes into a file
    named haproxy.sls (or a directory/state combo: haproxy/init.sls), then you
    include the haproxy module:

    include:
       - haproxy

    While I'm discussing style, I also like to treat the ID as documentation:

    Ensure haproxy is configured:
       file.managed:
         - name: /usr/local/etc/haproxy.conf
         - source: salt://haproxy/templates/haproxy.conf
         - template: jinja
         - require:
           - pkg: haproxy-pkg
         - watch_in:
           - service: haproxy-service

    Doing so lets you self-document your sls files.

    - 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.
  • Charles Baker at Jan 16, 2015 at 7:40 pm
    Ryan, is there an example of the emerging best practices such as you
    outline? Perhaps there is a formula or such that you feel is particularly
    representative?
    On Fri, Jan 16, 2015 at 12:40 PM, Ryan Lane wrote:

    On Thu, Jan 15, 2015 at 8:28 PM, Ari Maniatis <
    aristedes.maniatis@gmail.com> wrote:
    I'm not sure how to best organise configuration within states. The YAML
    data has a certain hierarchy imposed on it by the fact that every key must
    be unique. So it seems natural to do this:

    haproxy:
    pkg:
    - installed
    - provider: pkgng
    - name: haproxy
    service:
    - name: haproxy
    - running
    - enable: True
    - reload: True
    file:
    - managed
    - name: /usr/local/etc/haproxy.conf
    - source: salt://haproxy/templates/haproxy.conf
    - template: jinja
    - require:
    - pkg: haproxy
    - watch_in:
    - service: haproxy


    However, this breaks as soon as I want to add a second file, which cannot
    also have a key of "file". So then I end up with:
    Indeed. Though the docs show this style as an example pretty often, it's
    not a great way to organize your sls.

    haproxy-pkg:
    - pkg:
    - installed
    - provider: pkgng
    - name: haproxy

    haproxy-service:
    service:
    - name: haproxy
    - running
    - enable: True
    - reload: True

    /usr/local/etc/haproxy.conf:
    - file.managed
    - source: salt://haproxy/templates/haproxy.conf
    - template: jinja
    - require:
    - pkg: haproxy-pkg
    - watch_in:
    - service: haproxy-service


    But now I've lost all namespace ( the hierarchy of the YAML) and just end
    up with using hyphens in the key as a way to group my states and services.

    I'm confused by the two completely different approaches to configuration.
    What is the best way to arrange states so that they don't get confusing as
    my configuration grows?
    You organize your sls as modules. Your haproxy config goes into a file
    named haproxy.sls (or a directory/state combo: haproxy/init.sls), then you
    include the haproxy module:

    include:
    - haproxy

    While I'm discussing style, I also like to treat the ID as documentation:

    Ensure haproxy is configured:
    file.managed:
    - name: /usr/local/etc/haproxy.conf
    - source: salt://haproxy/templates/haproxy.conf
    - template: jinja
    - require:
    - pkg: haproxy-pkg
    - watch_in:
    - service: haproxy-service

    Doing so lets you self-document your sls files.

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


    --
    Charles H. Baker
    864.990.1297
    Knowing is not enough; we must apply. Willing is not enough; we must do.
    Bruce Lee

    --
    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 Jan 16, 2015 at 9:19 pm
    There's a best practices doc[1], but I think best practices depend on how
    you use salt. Best practices for masterless are going to be different, for
    instance. Best practices for using sequential ordering will be different
    too.

    [1]: http://docs.saltstack.com/en/latest/topics/best_practices.html

    - Ryan
    On Fri, Jan 16, 2015 at 11:40 AM, Charles Baker wrote:

    Ryan, is there an example of the emerging best practices such as you
    outline? Perhaps there is a formula or such that you feel is particularly
    representative?
    On Fri, Jan 16, 2015 at 12:40 PM, Ryan Lane wrote:

    On Thu, Jan 15, 2015 at 8:28 PM, Ari Maniatis <
    aristedes.maniatis@gmail.com> wrote:
    I'm not sure how to best organise configuration within states. The YAML
    data has a certain hierarchy imposed on it by the fact that every key must
    be unique. So it seems natural to do this:

    haproxy:
    pkg:
    - installed
    - provider: pkgng
    - name: haproxy
    service:
    - name: haproxy
    - running
    - enable: True
    - reload: True
    file:
    - managed
    - name: /usr/local/etc/haproxy.conf
    - source: salt://haproxy/templates/haproxy.conf
    - template: jinja
    - require:
    - pkg: haproxy
    - watch_in:
    - service: haproxy


    However, this breaks as soon as I want to add a second file, which
    cannot also have a key of "file". So then I end up with:
    Indeed. Though the docs show this style as an example pretty often, it's
    not a great way to organize your sls.

    haproxy-pkg:
    - pkg:
    - installed
    - provider: pkgng
    - name: haproxy

    haproxy-service:
    service:
    - name: haproxy
    - running
    - enable: True
    - reload: True

    /usr/local/etc/haproxy.conf:
    - file.managed
    - source: salt://haproxy/templates/haproxy.conf
    - template: jinja
    - require:
    - pkg: haproxy-pkg
    - watch_in:
    - service: haproxy-service


    But now I've lost all namespace ( the hierarchy of the YAML) and just
    end up with using hyphens in the key as a way to group my states and
    services.

    I'm confused by the two completely different approaches to
    configuration. What is the best way to arrange states so that they don't
    get confusing as my configuration grows?
    You organize your sls as modules. Your haproxy config goes into a file
    named haproxy.sls (or a directory/state combo: haproxy/init.sls), then you
    include the haproxy module:

    include:
    - haproxy

    While I'm discussing style, I also like to treat the ID as documentation:

    Ensure haproxy is configured:
    file.managed:
    - name: /usr/local/etc/haproxy.conf
    - source: salt://haproxy/templates/haproxy.conf
    - template: jinja
    - require:
    - pkg: haproxy-pkg
    - watch_in:
    - service: haproxy-service

    Doing so lets you self-document your sls files.

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


    --
    Charles H. Baker
    864.990.1297
    Knowing is not enough; we must apply. Willing is not enough; we must do.
    Bruce Lee

    --
    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.
  • Ari Maniatis at Jan 16, 2015 at 10:38 pm

    On Saturday, 17 January 2015 04:40:27 UTC+11, Ryan Lane wrote:

    Indeed. Though the docs show this style as an example pretty often, it's
    not a great way to organize your sls.
    This is one of the things that most confused me when starting with salt.
    Copying documentation examples is the best way to get quickly stuck and
    unable to proceed further. (That and the fact that the documentation for
    "file" is misleading and unhelpful.)

    You organize your sls as modules. Your haproxy config goes into a file
    named haproxy.sls (or a directory/state combo: haproxy/init.sls), then you
    include the haproxy module:

    include:
    - haproxy
    Sorry, but that doesn't help me. Modules (which is what I'm doing) are a
    great way to arrange files within the states and group things on disk. But
    they don't change the YAML namespace. Just because I use separate files
    doesn't mean I can have two entries called "main-config-file:"


    While I'm discussing style, I also like to treat the ID as documentation:

    Ensure haproxy is configured:
    file.managed:
    - name: /usr/local/etc/haproxy.conf
    - source: salt://haproxy/templates/haproxy.conf
    - template: jinja
    - require:
    - pkg: haproxy-pkg
    - watch_in:
    - service: haproxy-service
    Interesting. But I'm also not sure it helps. Your documentation is now the
    key and changing your documentation breaks all dependencies (like 'require'
    or 'watch'). You can't write "Ensure service is configured." because that
    will collide.

    Even your best practices documentation FAQ you pointed to is a little
    rough. They suggest a structure like:

    apache:
       pkg.installed:
         - name: {{ apache.server }}
       service.running:
         - name: {{ apache.service }}
         - enable: True

    include:
       - apache

    apache_conf:
       file.managed:


    So they are suggesting an approach that every state module can only have one pkg and one service running.
    But then they namespace the configuration files by using the "apache_" syntax as a prefix.
    Some services (like IPSec needing both ipsec and racoon on FreeBSD) require more than one service and package.


    So far I only have about a dozen state modules and I'm running into issues.
    How do people cope with hundreds?

    --
    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.
  • Dmitry Golubenko at Jan 19, 2015 at 5:17 am

    В Птн, 16/01/2015 в 14:38 -0800, Ari Maniatis пишет:

    So they are suggesting an approach that every state module can only have one pkg and one service running.
    But then they namespace the configuration files by using the "apache_" syntax as a prefix.
    Some services (like IPSec needing both ipsec and racoon on FreeBSD) require more than one service and package.

    So far I only have about a dozen state modules and I'm running into
    issues. How do people cope with hundreds?
    you can use 'dummy' echo -e 'changed\n' stateful cmd.wait to aggregate
    dependencies for use in other state 'modules', somthing like this:

    #ipsec.sls
    ...
    ipsec_done:
       cmd.wait:
         - name: /bin/echo -e 'changed: yes\n'
         - stateful: True
         - watch:
           - service: ipsec
           - service: racoon
             .....

    #some_other_sls_that_needs_ipsec_configured_and_running:

    myservice:
       pkg:
    ....
       service:
         - running:
         - watch:
           - cmd: ipsec_done


    --
    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 16, '15 at 4:28a
activeJan 19, '15 at 5:17a
posts6
users4

People

Translate

site design / logo © 2022 Grokbase