Doesn't entirely play nice with salt-cloud

[andrew-vant]

Ran into an issue today: salt.minion does all of its management in minion.d and doesn't touch the /etc/salt/minion file. salt-cloud does the opposite. Usually the settings in the former override the latter so everything is okay. However, for features that can be configured either from the minion config or the pillar root (such as mine_functions), the cloud-deployed file takes precedence over pillar, and salt.minion has no way of cleaning it up after the fact.

I don't think this is really a bug, but removing those settings after the fact is surprisingly irritating given that salt.minion won't touch that file.

I don't know the correct way to deal with this, but it seems like some option for managing /etc/salt/minion or otherwise neutering it (perhaps off by default) would be a helpful thing to have.

[iggy]

So... the formula used to manage /etc/salt/minion. Then someone (you I believe) changed that. I'd suggest a discussion about whether we should go back to managing /etc/salt/{master,minion} instead of pushing everything into .d dirs.

The original stated intention of that change was to make it easier to add new features to the config without having to edit the template files, but I think just doing the file.recurse gives you that flexibility without having to move the main config file into the .d dirs.

@gravyboat @puneetk @nmadhok Thoughts?

[gravyboat]

To be totally honest I don't care, we've gone back and forth on this about 4 times now. Why not just make a minion_d.sls that handles the content in there, a minion.sls that handles the main minion conf, and then a service state that just turns it on that both inherit? Let's just remember these are templates, it is assumed people will need to modify them for their specific use case.

[puneetk]

Yes, lets make what gets included controlled by the config in defaults or pillar. good call :)

On Jun 5, 2015, at 3:09 PM, Forrest notifications@github.com wrote:

To be totally honest I don't care, we've gone back and forth on this about 4 times now. Why not just make a minion_d.sls that handles the content in there, a minion.sls that handles the main minion conf, and then a service state that just turns it on that both inherit? Let's just remember these are templates, it is assumed people will need to modify them for their specific use case.

—
Reply to this email directly or view it on GitHub #142 (comment).

[andrew-vant]

I think that's the right direction, but I'd be more inclined to use a pillar setting for it -- that is, manage the main minion conf, and have an optional salt:master:minion_d_source: (some_template_source_folder) setting. Same for master.

Disagree on the template bit, by the way -- to me a large part of the benefit of the saltstack formulas is not having to maintain my own states. Most of my formula PRs are in some way motivated by wanting to make them flexible enough to avoid that.