New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make minion ID caching configurable #8488

Merged
merged 1 commit into from Nov 13, 2013

Conversation

Projects
None yet
4 participants
@basepi
Collaborator

basepi commented Nov 13, 2013

Hopefully this will prevent @kylegato from sending me dog crap.

Set minion_id_caching: False in your minion config, and you're good.

thatch45 added a commit that referenced this pull request Nov 13, 2013

Merge pull request #8488 from basepi/minion_id_config
Make minion ID caching configurable

@thatch45 thatch45 merged commit a98f701 into saltstack:develop Nov 13, 2013

@kylegato

This comment has been minimized.

Show comment
Hide comment
@kylegato

kylegato Nov 13, 2013

Contributor

Hah. Thanks @basepi 👍

Contributor

kylegato commented Nov 13, 2013

Hah. Thanks @basepi 👍

@steverweber

This comment has been minimized.

Show comment
Hide comment
@steverweber

steverweber Jan 23, 2014

Contributor

I'm new to salt and don't understand why this cached value was added and why its the default.

I'm not sure this is the case... however having an extra minion_id file by default for an edge case most users can ignore seems silly.

Perhaps I just don't understand the problem this cache value solves..?
Does this cached id ever expire and get rebuilt without manual removal?

Contributor

steverweber commented on 20f44a9 Jan 23, 2014

I'm new to salt and don't understand why this cached value was added and why its the default.

I'm not sure this is the case... however having an extra minion_id file by default for an edge case most users can ignore seems silly.

Perhaps I just don't understand the problem this cache value solves..?
Does this cached id ever expire and get rebuilt without manual removal?

This comment has been minimized.

Show comment
Hide comment
@steverweber

steverweber Jan 23, 2014

Contributor

Ah nm, I see that the minion_id cache only happens when the id is not statically defined in the minion config.

This cache would resolve issues when:

  • ip / dns migrations, perhaps after a rebooted system
  • if the get_id code is improved and returns better fqdn
Contributor

steverweber replied Jan 23, 2014

Ah nm, I see that the minion_id cache only happens when the id is not statically defined in the minion config.

This cache would resolve issues when:

  • ip / dns migrations, perhaps after a rebooted system
  • if the get_id code is improved and returns better fqdn

This comment has been minimized.

Show comment
Hide comment
@basepi

basepi Jan 27, 2014

Collaborator

Exactly. We had a regression where the way minion IDs were being resolved was changed, and whole infrastructures lost connection with their master as a result (new minion ID means the master needs to accept the key again).

This cache means that even if the way we "guess" the minion ID changes, existing minion IDs will survive.

Collaborator

basepi replied Jan 27, 2014

Exactly. We had a regression where the way minion IDs were being resolved was changed, and whole infrastructures lost connection with their master as a result (new minion ID means the master needs to accept the key again).

This cache means that even if the way we "guess" the minion ID changes, existing minion IDs will survive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment