sls validation?

[Oivvio Polite]

I'm starting to get my more complicated state files to work the way I
intend. I realised one thing I was doing wrong was putting my
requirements at the wrong indentation level. They were valid yaml but
they didn't actually make sense in salt terms.

Is there any way to run validation on sls files to make sure that all
everything you're feeding into salt actually make sense to salt.

oivvio

--
Oivvio Polite - http://liberationtech.net

[Markus Törnqvist]

On Mon, Jun 17, 2013 at 03:14:41PM +0200, Oivvio Polite wrote:

>
>Is there any way to run validation on sls files to make sure that all
>everything you're feeding into salt actually make sense to salt.

One thing I've done is

$ salt \* state.highstate test=True

Where both \* and the state can be exchanged for something more
specific.

Unfortunately for gitfs use (as in my case) this means pushing
and syncing every test, which may lead to profanity in commit
messages while learning new things ;)

I don't think you can validate much on the master because
so much of the context is dependent on the minion.

It would be nice to have a mechanism to pass fake context in,
but I don't even know what that would look like. Maybe if
you hooked it in through python?

--
mjt

[Oivvio Polite]

On Mon, Jun 17, 2013 at 04:31:06PM +0300, Markus Törnqvist wrote:
> One thing I've done is
>
> $ salt \* state.highstate test=True

Yeah, I've been fooling around with that.

>
> I don't think you can validate much on the master because
> so much of the context is dependent on the minion.

I was thinking that you could at least validate all static stuff.

Look at this snippet for instance.

/some/path:

file.exists:
- require: /some/other/path


Looks fine right? Well it's not, because 'require' isn't a valid argument
for the state file.exists. When writing my sls files getting that kind
of feedback automated would be real handy.

[Markus Törnqvist]

On Mon, Jun 17, 2013 at 03:54:41PM +0200, Oivvio Polite wrote:
>
>I was thinking that you could at least validate all static stuff.
>
>Look at this snippet for instance.
>
>/some/path:
>
> file.exists:
> - require: /some/other/path
>
>
>Looks fine right? Well it's not, because 'require' isn't a valid argument
>for the state file.exists. When writing my sls files getting that kind
>of feedback automated would be real handy.

If I've got this correct, salt runs everything through the render engine.

In case that's true, you'd need to validate the input template and
the rendered output being equal and only then look at the contents. Otherwise
you may have caused an error through the context that can't be caught.

Or catch an error because context data was missing.

Now that I wrote the above it feels sort of hacky...

Anyone else, say the devs, got ideas? Because validation would be
extremely extremely nice! :)

--
mjt

[Luminous Salt]

Someone more knowledgeable is surely welcome to correct me on this, but
I believe the requisite statements (require/watch/etc) are available to
all state functions - your issue is that this isn't correct salt'd
yaml.. it ought to be in the form:

/some/path:
file.exists:
- require:
- file: /some/other/path

note that you are not telling salt's file.exists() to check for
/some/other/path.. you are telling salt's state processing that THIS
file.exists state, with the name "/some/path" requires another _state_,
the file state with the _name_ /some/other/path - note that salt's state
module does not really see this as a _path_, but a name.

my general recommendation, if even more verbose (I care more for
consistency), is to use 'better' names for things, then put in a "name",
eg:

canonical_name:
file.exists:
- name: /some/path
- require:
- file: some_other_canonical_name

overall, (imho) you end up with more readable states that are less
prone to breakage - you can change the actual path to either of these
without doing more than updating one line, rather than having to run
through all the places where you have a requisite.

:)

[Mrten]

On 17/6/2013 22:34 , Luminous Salt wrote:

> canonical_name:
> file.exists:
> - name: /some/path
> - require:
> - file: some_other_canonical_name
>
> overall, (imho) you end up with more readable states that are less prone
> to breakage - you can change the actual path to either of these without
> doing more than updating one line, rather than having to run through all
> the places where you have a requisite.

+1

and i seem to recall that if you want to use the stateconf renderer you
*need* to use canonical names so better start with them to begin with.

From the manual:

[This module provides a custom renderer that processes a salt file with
a specified templating engine (e.g., Jinja) and a chosen data renderer
(e.g., YAML), extracts arguments for any stateconf.set state, and
provides the extracted arguments (including Salt-specific args, such as
require, etc) as template context. The goal is to make writing
reusable/configurable/parameterized salt files easier and cleaner.]

M.

[Luminous Salt]

On 2013-06-17 09:31, Markus Törnqvist wrote:
> On Mon, Jun 17, 2013 at 03:14:41PM +0200, Oivvio Polite wrote:
>
>>
>> Is there any way to run validation on sls files to make sure that all
>> everything you're feeding into salt actually make sense to salt.
>
> One thing I've done is
>
> $ salt \* state.highstate test=True
>
> Where both \* and the state can be exchanged for something more
> specific.
>
> Unfortunately for gitfs use (as in my case) this means pushing
> and syncing every test, which may lead to profanity in commit
> messages while learning new things ;)
>

OT: this is what ``git rebase -i HEAD~X`` is for (where X is the number
of commits to include in the rebase). you can then squash commits
together, reword commit messages and do all sorts of fun stuff. It's
really handy, but the flow can take a little while to get used to.. note
that you don't want to do this on commits that have been merged with
other branches - you are creating new commits.

cheers

[Markus Törnqvist]

On Mon, Jun 17, 2013 at 02:44:14PM -0400, Luminous Salt wrote:

>
>OT: this is what ``git rebase -i HEAD~X`` is for (where X is the
>number of commits to include in the rebase). you can then squash
>commits together, reword commit messages and do all sorts of fun
>stuff. It's really handy, but the flow can take a little while to get
>used to.. note that you don't want to do this on commits that have
>been merged with other branches - you are creating new commits.

I know about rebase, sure, and also amending commits is nice.

Fortunately in this case it's only been me accessing the repo
so I could do that, but OTOH for the same reason no one cares
about the commit messages.

Which brings up another topic. Having big binary files for
eg. bootstrapping virtualenvs (compilation sux time-wise) in
git is no fun.

Is S3 the recommended way to go or do you guys on the list
have other ideas?

I might re-do the git repo, disregarding the commit history,
and just have private buckets or whatever for the files, but
I haven't got to use S3 yet and I'm not sure if that's the
optimal solution.

--
mjt