Grouping requisites

[piotr...@10clouds.com]

I'm trying to get salt to configure a working instance of the project I'm working on. So far so good, but managing state dependencies is slowly becoming a horror. Seems like require/watch[_in] are incapable of abstracting things the way I initially expected them to. For example, to get some part of the project running as supervisor service, I need to require:

- supervisor package

- files with project code (and I need to know how they are created, eg. by cloning git, I cannot just say: require project code, I don't care if it's svn or git)

- python virtualenv

- pip-installed packages

- node virtualenv

- system packages

- Django settings generated from template

- directories for storing log files and databases

- some other helper scripts generated from Jinja templates

Some of those could require others, making the list shorter, but much less readable and maintainable.

This leads me to believe I'm somehow misusing the tool, or I just missed some functionality it has. I hoped I could just define "project environment" as a bunch of states, and later on just reference it by a single name. Is there any way to achieve similar effect? Perhaps some state is suitable to be a no-op with lots of requires and watches, serving as a grouping state?

[Colton Myers]

I *think* what you're looking for is the overstate system:  http://docs.saltstack.com/ref/states/overstate.html

This will allow you to much more carefully orchestrate the order in which different states execute, allowing you to make sure certain states execute first, which means they're required for the subsequent states.  If there's a failure in any of the overstate states, it aborts without running the remaining states.

Keep me posted if that doesn't serve your needs.

--

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.
 
 

[Piotr Kufel]

Thanks! It looks like it handles dependencies the way I need. Few
problems though:

1. I'm in a masterless setup (one of the use cases is to setup a
private development virtual machine), so I do not have salt-run. There
is publish.runner function, but it needs master_uri configured, so I
assume it won't really work without salt master installed.

2. The overstate.sls file is not modular. One of the things I wanted
was the ability to easily pick components to use (do not install nginx
on development server, Django's built in one will suffice). With just
highstate each available configuration had a separate top-like file,
listing/including components to use, and I'd choose which one to use
when deploying. I do not want to copy dependency logic into each
configuration set, and it seems there is no option to either include
other overstate files or pull only particular item from overstate.sls
(including its dependencies).

I ended up writing a simple dummy lowstate in python, just to group
require/watch statements, and so far it works quite well. I wonder f
you could call it a hack..


Cheers

[Colton Myers]

Heh, I can't comment on whether it's a hack without seeing the code!  ;-)  But I'm glad you figured out a fix.

I haven't used salt much in a masterless situation, so I can't help much there.  =\

I'm not quite following your "modularity" issue.  You can define certain sls files for certain server sets -- what is the additional functionality you're looking for?

--

Colton Myers

[Dmitry Golubenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I use "noop" states like this:
app-service-start:
cmd.wait:
- name: "echo -e \nchanged: yes"
- statefull: True
- watch:
- cmd: database-finish
- pkg: core

then require "app-service-start" in all app states that require db setup.

database-finish:
cmd.wait:
- name: "echo -e \nchanged: yes"
- stateful: true
- watch:
.... all my db stuff ....

not very elegant way but it works and readable/understandable

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRmtmeAAoJEABrawzOrWpF9kwIAJ2d7vRcg2rUxNMnmpodZi79
PGnWgkSfXheKlXwAnO5fIfSwBF9spBSbgC/VC7rTTBS1QKWOUCxoIjdsBk6E7/qB
ZXOAXdp++iAX2FMUAQ7VrIIY3UhBxB3zpLS4QboKPbebtZv/fZCEO+xoGBnAfEA0
q5YeGeDrj2KsM207JQqF8Mr3tSb8RG0LX5uiIo6ylpFPyBS4DMGgc09bNByAZgB9
l0P5KLQLp9jWKQalpVtsWiFGSjFOkn1i/pDyAihc2296x7gG7m+VCGHOJMBg9NF+
RRBMlTwXZh+XQATAP3wkvNkYF2jEq9f54Nal+f1OT9D+w7GNPzwCMrBNDCREoYE=
=xCIQ
-----END PGP SIGNATURE-----

[Mrten]

On 21/5/2013 04:19 , Dmitry Golubenko wrote:

> I use "noop" states like this:
> app-service-start:
> cmd.wait:
> - name: "echo -e \nchanged: yes"
> - statefull: True

I think it's "stateful" (1 L, not two) so this one doesn't do anything.

> - watch:
> - cmd: database-finish
> - pkg: core
>
> then require "app-service-start" in all app states that require db setup.
>
> database-finish:
> cmd.wait:
> - name: "echo -e \nchanged: yes"
> - stateful: true
> - watch:
> .... all my db stuff ....
>

M.

[Thomas S Hatch]

I think that you should take a look at the order option, also in 0.16.0 we have added the ability to require everything in an sls file, making this a lot easier as well:
http://docs.saltstack.com/ref/states/ordering.html#the-order-option

Using order you can set common items to just be evaluated first, making tracking everything much easier

Thomas S. Hatch  |  Founder, CTO

5272 South College Drive, Suite 301 | Murray, UT 84123

tha...@saltstack.com | www.saltstack.com

[Dmitry Golubenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/21/2013 03:26 PM, Mrten wrote:
> On 21/5/2013 04:19 , Dmitry Golubenko wrote:
>
>> I use "noop" states like this: app-service-start: cmd.wait: -
>> name: "echo -e \nchanged: yes" - statefull: True
>
> I think it's "stateful" (1 L, not two) so this one doesn't do
> anything.

sorry, typo during edit :(

>
>> - watch: - cmd: database-finish - pkg: core
>>
>> then require "app-service-start" in all app states that require
>> db setup.
>>
>> database-finish: cmd.wait: - name: "echo -e \nchanged: yes" -
>> stateful: true - watch: .... all my db stuff ....
>>
>
> M.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRmznkAAoJEABrawzOrWpFuzYH/2UoGm4RlaYOK+n9ItY4i5sq
HcoYFsusE6X5C0HPaljyYvHEPFhTcH2rR18A2Yp1YV6XswkeULm/xwHMoXHV83aH
2hIR8aN7+FRE09zcNWq1JO32dqfuGo3AZ89d5cv8DO4DWxt7yZFxfeVuJxFC+3Dw
t6u7ahTP3G0QO9v5eIk405sjfAuze0l3oN8GjuVyb9kREhn2F1foKtLEHFgBAMQs
0ryA7iV2w5ePL0u1qJSMamheJON2ye8Tqi5sEMpvWo/3jnBaziL1ZNGM5XIljqxr
QSkVzIXyA8AegZI2JzqYatVmUBCKA3b1J4pQVRN3DRFVG1UavMTjTT8g2ZR2PO8=
=gbul
-----END PGP SIGNATURE-----

[Dmitry Golubenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/21/2013 03:33 PM, Thomas S Hatch wrote:
> I think that you should take a look at the order option, also in
> 0.16.0 we have added the ability to require everything in an sls
> file, making this a lot easier as well:
> http://docs.saltstack.com/ref/states/ordering.html#the-order-option

awesome!

>
> Using order you can set common items to just be evaluated first,
> making tracking everything much easier

thanks, will try it. currently I use only "order: last" for cleanup
and things like etckeeper

>
> Thomas S. Hatch | Founder, CTO
>
>

> 5272 South College Drive, Suite 301 | Murray, UT 84123

> tha...@saltstack.com | www.saltstack.com <http://saltstack.com/>

>
>
> On Tue, May 21, 2013 at 2:26 AM, Mrten <mrten+s...@ii.nl>
> wrote:
>
>> On 21/5/2013 04:19 , Dmitry Golubenko wrote:
>>
>>> I use "noop" states like this: app-service-start: cmd.wait: -
>>> name: "echo -e \nchanged: yes" - statefull: True
>>
>> I think it's "stateful" (1 L, not two) so this one doesn't do
>> anything.
>>
>>> - watch: - cmd: database-finish - pkg: core
>>>
>>> then require "app-service-start" in all app states that require
>>> db setup.
>>>
>>> database-finish: cmd.wait: - name: "echo -e \nchanged: yes" -
>>> stateful: true - watch: .... all my db stuff ....
>>>
>>
>> M.
>>
>>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRmzuZAAoJEABrawzOrWpFgO8H/RIyGwkOCQ8lIGWxOAhafotp
EQMCFDdRB6cGPPTXsghj2/O0mHWGD29w2PsmxZHkOR+PstJ1ieFEfmQPUs5LyI8d
TikOQHUP3N4WiM7dmGYv0Ergp2PgALA7DlWNudawMS0XGjcyupqopHBQJ28EL2y1
HZnfR4CjvvB6w8eJHt6nM7WUk7BEGnadL9rdZeqkOP4e+l0qjWKSHX3fcFXj41Ma
vm5VwMX8/ALiXR7giB/PaniWfxXt20b3fSIvFcJ1pcXM1rEUSsY6Q1Uvq/Dmhrdz
CUH5zXn2xSa/ElZsHe0GztS64g2W/uFafeUG+DUcHVDMXn1SktIT6QOj8VH7cdw=
=AU7d
-----END PGP SIGNATURE-----

[Piotr Kufel]

Colton: Sharing parts of configuration. When defining two overstate files, seems there is no way to factor out some parts to other files. Maybe you can use template-level include to emulate it like in C preprocessor. In "regular" master+minions setup that might not hurt (you just match minions in those state groups, assuming each minion has fixed role, and one big file works for all). In my case, since I want to choose which role to deploy to target machine, I'd need to keep separate overstate file for each role.

Thomas: I'm aware of the order option. Great to know there'll be SLS-level require in 0.16.

2013/5/21 Thomas S Hatch <that...@gmail.com>

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/1avsakB9HGE/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

[Colton Myers]

Ah, I see.  Hopefully all your problems will go away with 0.16.  ;)

--

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.