SLS naming convention - am I thinking about this wrong?

[Terence Kent]

Hello all!

We've been using salt for a few years now and love it. We're going through the process of updating our formulas and we're looking to improve how we've been using salt now that we have a bit of experience with it.

One thing that we've decided to do is use more granular SLS files, and that's where I'm seeing salt naming conventions that don't match my understanding of how it all works. From my understanding:

• Execution modules: Run something on a minion
• State modules: Ensures a specific thing is in a given state, only making changes if necessray, and uses execution modules to do this.
• SLS files: A set of states to call with a specific configuration, which ensures a meaningful state for some higher level context (e.g. my service is running).

From that understanding, I would expect SLS files to be named as adjectives. For example:

apache2/

    installed.sls

    configured.sls

    running.sls

    stopped.sls

    removed.sls

    moduleX/enabled.sls

    moduleX/disabled.sls

SLS names like these would match the individual state module names I see. Instead, in all the examples I'm seeing names that are verbs or nouns like "install.sls", "remove.sls", or "moduleX.sls". This makes me think I'm missing something fundamental.

The state system in salt, from my current understanding, "ensures a programtic description of something is true". However, from the naming, I would think the correct way think about it is that the state system "executes a series action, where some may be opportunitistically skipped".

The later description matches ansible playbooks, but isn't what I thought the state system was all about. Before we go down the path of possibly mis-using the state system, I wanted to check with the community. What's the "right way" to look at this? Or, is there no "right way"?

Thanks alot,

Terence

[Thomas Phipps]

there really is no naming scheme walk though. honestly i kind of like the adjectives method. however there are some things that might change that. in my case my states are run from orchestration and highstate.

my work flow being use orchestration to install and use highstate as an always running maintenance. for the states that orchestration calls the adj. name still makes sense, but the orchestration names should defiantly be descriptive verb. 

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/73202a53-8198-4d51-bdff-0d145e9c4fe1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Thomas Phipps

Linux/Openstack/Logstash

(702) 518-0131

[Terence Kent]

 Thanks Thomas - I appreciate your input!

Orchestrate runner sls's are a tricky one, because I can see them written both ways. For example, we could have orchestrate runners along the lines of: xyz-service-env.release-version-current or we could have: xyz-service-env.perform-rolling-release. I'm going to have to put some thought into what makes the most sense for us. The heart of it, IMO, is wether or not these SLS's should be re-enterant. As in, if I call it over and over again, should I expect it do nothing if the service is already in the right state?

I think we're going to use adjectives unless somebody points us in another direction. It may sound like a small thing, but it shapes how the developers think of sls's when writing them.

Thanks,

Terence

[John Hicks]

We use a past-tense naming convention for our state files (e.g. apache/installed.sls, apache/ssl_enabled.sls, apache/default_vhost_installed.sls) as they are used to enforce that a minion is in a given state after execution. Most of them are context-aware so that running a state twice will result in the second run just reporting that it had nothing to do. We use granular state files where possible to make re-using state operations easier but you do have to pay attention to requisites and the ordering of state instructions.

We have not really got into orchestration yet as we run our minions in a test=True mode by default and (unless it's changed recently) the test mode override is not passed correctly down to the minion during an orchestrate run.

[Terence Kent]

Thanks for the input John! It's nice to hear another user is naming their SLS's with adjectives. It seems to fall inline with my understanding of the re-entrant and idemptence focus for states. And thanks for the tip on the orchestrate runner's test mode behavior!

[Matthew X. Economou]

Terence Kent writes:

> From that understanding, I would expect SLS files to be named as

> adjectives. For example...

>
> The later description matches ansible playbooks, but isn't what I
> thought the state system was all about. Before we go down the path of
> possibly mis-using the state system, I wanted to check with the
> community. What's the "right way" to look at this? Or, is there no
> "right way"?

You described a really well thought out naming convention here. If it makes sense to your colleagues, then it's "right".

I'm not going to claim that I am an expert, but my approach is probably best characterized as a deconstruction of ITIL service level packages. My top-level SLS IDs are very narrowly scoped as a result and get named after the services or resources they manage, with an emphasis on reuse across service offerings. The different Salt file server environments (== Git branches) represent the development/testing/acceptance/production (DTAP) phases of our enterprise life cycle. Together these Salt states plus the file server environments and the accompanying service-specific customization in Pillar implement large-scale service level packages, e.g., a production Shibboleth identity provider, a development mail relay, or a testing Minecraft server. All of this is influenced by my thinking on things like how to apply object oriented programming techniques to system administration and how to use a GitHub flow-like change model in a configuration management system.

You can find examples here:

https://github.com/irtnog/salt-states

https://github.com/irtnog/salt-pillar-example

I've written a bunch of my own formulas, too:

https://github.com/irtnog/openssh-formula

https://github.com/irtnog/shibboleth-formula

https://github.com/irtnog/tomcat-formula

Note SLS IDs like `sshd`, `aws.lambda`, or `tomcat.shibboleth-idp`, or Pillar SLS IDs like `login.example.com`.

Best wishes,
Matthew

--
"The lyf so short, the craft so longe to lerne."

[Terence Kent]

Matthew,

Thanks for the input! 

Reading your note and looking through your formula's, I think they would all be equivelant to a <service_name>.running or <service_name>.<module>.enabled state in the pattern we're looking to use. If the only state you ever need your services to be in is "running" or "enabled", then I can see naming everything X.running, Y.enabled, etc, would be tedious.

The think the heart of the matter with regards to naming may come down to how much you are controlling with salt. In our world, we orchestrate events and manage services in a fairly granular way with our states. As a result, we sometimes need a service in the "configured" state, but not the running state. Or, we may need to put a service across a batch of systems into the "stopped" state.

Separately, I should have been more clear that the SLS files I'm focused on here are only state SLS files. Pillar SLS files are another thing entirely. I really wish they didn't use the SLS extension for pillar files since it's so confusing!

In any event, I really appreciate you sharing! It's nice to see how others are managing this.

Best,

Terence