Control from pillar if the service is running and enabled

[dnABic]

Making it possible to control from pillars if service is running and / or enabled. The idea is identical to the one in rabbitmq formula: https://github.com/saltstack-formulas/rabbitmq-formula

In my use case, I create an AWS image where I use this saltstack formula to install elasticsearch. Still, at this point I don't know final configuration and therefore I don't want that elasticsearch runs.

In latter steps, I create aws ec2 instance of previously created image. Then salt stack will do the final configuration of elasticsearch and finally start the service.

[myoung34]

@dnABic can you rebase against master to see if that changes the tests pass/fail?

[dnABic]

@myoung34 the changes made test to pass.

[blbradley]

I recommend using elasticsearch.pkg state during your AMI creation step and elasticsearch state on your running instances.

[myoung34]

@blbradley Im torn on that, because I can actually see the value if he doesnt run salt post-AMI (as I do not). I use it purely to build, not to manage, so on AMI creation my last steps are to remove salt to save some memory.

@dnABic fwiw Im using this formula as is with a very very generic placeholder /etc/elasticsearch/elasticsearch.yml to get it through, then in packer after salt has run i use:

sudo service elasticsearch stop && sudo rm -rf /var/log/elasticsearch/* /var/lib/elasticsearch/*

To clean up node data so that when I spin it up elasticsearch is fresh.

[blbradley]

@myoung34 If you used just elasticsearch.pkg during your Packer build, your extra steps would not be required (sans SaltStack removal).

rabbitmq-formula seems to have used this pattern because their pkg.installed and service.running states are in the same file. So, you can't do what I've described with that formula without refactoring.

I'm not against this change. Just providing an alternative. I see lots of feature flags popping up in formulas in situations where a subset of the formula's states can be used instead. This feature flag creep comes from users that want to edit their pillar not under source control vs editing states under version control: ✋ (hand raise as one of those users).

[myoung34]

It definitely is a smell, the workaround I have would be more viable. I agree, importing a service state should have a consistent behavior, and should both enable and start a service. Not sure Id merge this but instead use my workaround