best practices for running mkfs.xfs?

[defmi...@gmail.com]

I want to create an xfs filesystem on an lvm logical volume with something like:

mkfs.xfs /dev/vg0/data

This only needs to happen once ever.

It looks like there is no corresponding salt.states that do what I want.

It looks like salt.modules.parted or salt.modules.extfs might do what I want (unclear whether xfs is supported), and I see the example at http://docs.saltstack.com/topics/tutorials/starting_states.html#understanding-the-render-system to call a salt module in an .sls, so it looks like I may be able to use those salt.modules.  And then I would use some kind of "unless" condition to only make it happen once, in which case I feel like I may be better off just using cmd.run in the first place.

Is there a better way to do what I'm trying to do? Seems like cmd.run is the way to go.

[Colton Myers]

I was going to recommend cmd.run until you said it yourself halfway through.  ;)

--

Colton Myers

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Jesusaurus]

The problem with one-off commands like formatting a partition is that they make it really hard to write idempotent configurations. Personally, I think that this kind of action belongs in a deployment phase, not a configuration phase; but the line between the two phases is getting pretty blurry.

[Matt Black]

I still haven't really made up my mind about this either.

On one hand, I want my salt state tree to be clean and idempotent - and on the other I don't want to have to manage another set of configuration code which only runs once.

Currently I work around this with the judicious application of unless and onlyif, but it doesn't really feel right :)

[Clint Dilks]

Hi

One option we are playing with in relation to this is writing states that we can execute manually as lets say an install state and then having our install system ( in this case KickStart ) execute the state as part of its post install process.  As much as possible the the install state and top.sls share the same states and files

Seems to work well.

[Renoir Boulanger]

I also have the same ideal.

The only solution I come across when it come to destructive action such as formatting a partition would be to create somewhere else in the system a file specific to your configuration set, or a grain, that says the install step has been run.

My other proposal would be to have a Reactor [0]. Something that I wasn't aware a few seconds ago that could be ideal for this use case.

If somebody has a proposal, I'd like to see. In the meantime, I might work on that and get back to you.

  [0]: http://docs.saltstack.com/topics/reactor/index.html

Regards,

Renoir Boulanger  |  Developer operations engineer
W3C  |  Web Platform Project

http://w3.org/people/#renoirb  ✪  https://renoirboulanger.com/  ✪  @renoirb
~