dynamic master ip on minion?

[Volker]

Hi all,

im looking for a way to have a minion dynamically figure out its
salt-master ip upon startup. The idea is, to have several thousand
minions spread over several salt-masters and have certain ranges of
minions on certain salt-msters. It should look sort of like this:

server0000 - server2499 -> salt-master01
server2500 - server4999 -> salt-master02
server5000 - serverxxxx -> salt-master03
etc.

The current settings do not allow this kind of mapping. They only have a
fallback if the first ip cant be reached (multimaster setup).

I was thinking to use grains for this, but they seem to be loaded too
late in the startup process.

The wheel module seems able to do this, but its also loaded to late.

What would be a good entry point to add for example:

master: 'grains:master_ip'

or

master: 'module.get_master_ip'

to the code to have the minion lookup its the master-ip from a modules
function or a grains value?

Or maybe even another approach?

- felskrone

[Colton Myers]

If you are providing a grain with the correct master, then you're still providing custom data on that minion, so why not just provide it in the minion config?  If you didn't want to edit the actual minion config, you could just throw a file in `/etc/salt/minion.d/` with the master IP in it, and it will be picked up when the minion starts.

Or am I missing something?

--

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/d/optout.

[Volker]

On 5/23/14 10:10 PM, Colton Myers wrote:
> If you are providing a grain with the correct master, then you're still
> providing custom data on that minion, so why not just provide it in the
> minion config? If you didn't want to edit the actual minion config, you
> could just throw a file in `/etc/salt/minion.d/` with the master IP in
> it, and it will be picked up when the minion starts.
>
> Or am I missing something?

I'm afraid so :-)

My goal is, to have something on the minions with which i can manage the
masters ip dynamically. I think an example makes it more clear.

I want a minion to calculate its master-ip upon start. If i would do it
with a module, that would be something like

minion_funcs.get_master_ip()

the function get_master_ip() takes for example the minions hostname and
does (all pseudo-code):

###
hostname = socket.gethostname()

if hostname.startswith('web'):
return '10.10.10.10'
elif hostname.startswith('db'):
return '10.10.10.11'
####

or the function takes only the digits of the hostname and does:

###
digits = int(re.search('\d+', socket.gethostname()))

if digits > 1000:
return '10.10.10.10'
elif digits > 2000:
return '10.10.10.11'
elif digits > 3000':
return '10.10.10.12'
###

If i would ever want to change the distribution of minions to the
different masters, i would change it in the module, do a sync_modules
and restart the minions.

What i do not want is to have
- config A on minions server0000 - server0999
- config B on minions server1000 - server1999
- config C on minions server2000 - server2999
etc.

that would of course work, but its too static and needs too much
attention if i ever want to change the distribution of minions to the
master.

I hope that makes it more clear.

- felskrone

[Elias Probst]

What about Round-Robin DNS instead, so you could have them all just
point to salt.your-domain.tld and the DNS lookup would pick a random
Master IP from your RRDNS pool on startup.

As long as the Minion is running, it will keep the cached result of the
initial DNS lookup and get a new IP from the RRDNS pool on the next startup.

If needed, the masters itself could add/drop themselves from the RRDNS
pool based on their load - but if they're all sized more or less equal
the load should be distributed good enough by the random distribution
across the RRDNS pool.

This way you wouldn't have to care about socket.gethostname() hacks or
any number-range schemes etc which you'd have to map your masters to
certain minions etc.

- Elias

[Volker]

On 5/24/14 8:52 PM, Elias Probst wrote:
> What about Round-Robin DNS instead, so you could have them all just
> point to salt.your-domain.tld and the DNS lookup would pick a random
> Master IP from your RRDNS pool on startup.

Good idea, but i need a static set of minions on a master. Distributing
them randomly makes key management hard with roundabout 15.000 minions.
I also need to know, which minions i should expect to answer on which
master.

I also dont control my dns-services, only the zones :-/

>
> This way you wouldn't have to care about socket.gethostname() hacks or
> any number-range schemes etc which you'd have to map your masters to
> certain minions etc.
>

As long as its nicely implemented, i dont consider this a hack. Thats
why im asking for a good entry point. I want to send my changes upstream
so everyone can profit from it :-)

-felskrone

[Vitold S]

This idea calling Sharding and require salt-sharding new component with current statistic of node when connection:

For example:

SaltMasterA: 10000 client

SaltMasterB: 20000 client

SaltMsterC: 8 client

SaltSyndicat was intersect all SaltMasters ;)

SaltMinion Connection Flow:

1. Connect to SaltMasterA and connection reject by (who close connection?) limiitation to node minion count for example 5000 client limit

2. Connect to SaltMasterB and connection reject by (who close connection?) limiitation to node minion count for example 5000 client limit

3. Connect to SaltMasterC and connection holding and using that node

And you just create you idea without any your code. Anoter condition you may insert about platform or variable of this node.

понедельник, 19 мая 2014 г., 15:54:09 UTC+4 пользователь Volker S. написал:

[Volker]

Hi,
just fyi, i looked a little deeper into this and its actually rather
simple to add.

https://github.com/saltstack/salt/pull/13039/files

But:

> As long as its nicely implemented, i dont consider this a hack. Thats
> why im asking for a good entry point. I want to send my changes upstream
> so everyone can profit from it :-)

I dont consider this nicely implemented and hope for a comment from
Thomas on how to improve it.

-felskrone

[Elias Probst]

On 05/24/2014 09:27 PM, Volker wrote:
> Good idea, but i need a static set of minions on a master. Distributing
> them randomly makes key management hard with roundabout 15.000 minions.

a) Frequently running rsync to keep the different PKI dirs in sync
b) Distributed/shared file system between all masters

[Mansi Seth]

In reference to the solution provided for a master to dynamically figure out it's master...where would this function minion_funcs.get_master_ip() be defined? is it a script, a state or something else?

[brad.v...@gmail.com]

Not sure if this is the same thing, but we wanted a way to get the correct salt master when kickstarting a new server.  So, we created a python script and ran it as a service, then in the post section of the kickstart, we do a curl to the service and retrieve the salt master name.  The file is just:

salt-master1.name:

  - fqdn.server2

  - fqdn.server3

salt-master2.name:

  - fqdn.server4

  - fqdn.server5

We just set the output of the curl command to a variable and then use that to put into the salt minion file for it's master.

Hopefully this helps.