Into the brine...mine.

[J C Lawrence]

Okay, digging into salt mine now.

pillar/top.sls:

base:
"*":
...
- saltmine

pillar/saltmine.sls:

mine_functions:
network.interfaces: []
network.ip_addrs: []

$ salt \* saltutil.refresh_pillar
...nothing reported.

...wait 30 minutes because good rum deserves respect.

$ salt dev-bastion pillar.items | fgrep -A 3 mine_functions
mine_functions:
----------
network.interfaces:
network.ip_addrs:

$ ls -l /var/cache/salt/master/minions/dev-bastion/mine.p
-rw-r--r-- 1 root root 363 Jan 10 03:13
/var/cache/salt/master/minions/dev-bastion/mine.p

$ file /var/cache/salt/master/minions/dev-bastion/mine.p
/var/cache/salt/master/minions/dev-bastion/mine.p: Non-ISO
extended-ASCII text, with very long lines, with no line terminators

$ strings /var/cache/salt/master/minions/dev-bastion/mine.p
network.interfaces
hwaddr
00:00:00:00:00:00
inet
broadcast
netmask
255.0.0.0
address
127.0.0.1
label
inet6
prefixlen
address
eth0
hwaddr
22:00:0a:b6:be:a9
inet
broadcast
10.182.190.191
netmask
255.255.255.192
address
10.182.190.169
label
eth0
inet6
prefixlen
address
fe80::2000:aff:feb6:bea9
network.ip_addrs
10.182.190.169

Okay, what am I missing here? Why are there no values for the
mine_functions?

-- JCL

[David Anderson]

I'm confused - what do you mean there are no values for the
mine_functions? Everything is working as expected, which is to say you
are telling all of your minions to run the network.interfaces and
network.ip_addrs modules from the mine scheduler with no arguments. This
is equivalent to running:

salt '*' mine.send network.ip_addrs
and
salt '*' mine.send network.interfaces

Instead of running strings on your mine file, you can use the 'mine.get'
function on a minion to check the mine data. We should also add a
cache.mine runner to make retrieving mine data on a master easier.
--
Dave

[JC Lawrence]

On 10 Jan 2014, at 08:22, David Anderson <da...@dubkat.com> wrote:

> I'm confused - what do you mean there are no values for the mine_functions?

I don't see any values in the pillar via `salt \* pillar.items` I'd (naively?) expected to.

> Everything is working as expected, which is to say you are telling all of your minions to run the network.interfaces and network.ip_addrs modules from the mine scheduler with no arguments. This is equivalent to running:
>
> salt '*' mine.send network.ip_addrs
> and
> salt '*' mine.send network.interfaces
>
> Instead of running strings on your mine file, you can use the 'mine.get' function on a minion to check the mine data. We should also add a cache.mine runner to make retrieving mine data on a master easier.

Okay, let me start from the other end. Clearly I'm missing something basic and obvious-to-everyone-but-me and thus can't see the nose on my face.

I want MinionA to find out what MinionB's IP address is. Even more specifically, I want to write a state which creates a configfile on MinionA which contains MinionB's IP address when all I know is the tag for MinionB..

A) How would I do that?

B) Is the above useful to that end?

-- JCL is failing to join the dots

[David Anderson]

On 1/10/14 9:22 AM, David Anderson wrote:
> Instead of running strings on your mine file, you can use the
> 'mine.get' function on a minion to check the mine data. We should also
> add a cache.mine runner to make retrieving mine data on a master easier.
> --
> Dave
>

Adds cache.mine function in cache.py runner:
https://github.com/saltstack/salt/pull/9679
--
Dave

[David Anderson]

On 1/10/14 9:59 AM, JC Lawrence wrote:
> On 10 Jan 2014, at 08:22, David Anderson <da...@dubkat.com> wrote:
>
>> I'm confused - what do you mean there are no values for the mine_functions?
> I don't see any values in the pillar via `salt \* pillar.items` I'd (naively?) expected to.

You posted in your previous email that you are seeing the proper
mine_functions set in the pillar as applied by your top.sls:

$ salt dev-bastion pillar.items | fgrep -A 3 mine_functions
mine_functions:
----------
network.interfaces:
network.ip_addrs:

>

>> Everything is working as expected, which is to say you are telling all of your minions to run the network.interfaces and network.ip_addrs modules from the mine scheduler with no arguments. This is equivalent to running:
>>
>> salt '*' mine.send network.ip_addrs
>> and
>> salt '*' mine.send network.interfaces
>>
>> Instead of running strings on your mine file, you can use the 'mine.get' function on a minion to check the mine data. We should also add a cache.mine runner to make retrieving mine data on a master easier.
> Okay, let me start from the other end. Clearly I'm missing something basic and obvious-to-everyone-but-me and thus can't see the nose on my face.
>
> I want MinionA to find out what MinionB's IP address is. Even more specifically, I want to write a state which creates a configfile on MinionA which contains MinionB's IP address when all I know is the tag for MinionB..
>
> A) How would I do that?

From MinionA CLI:

salt-call mine.get 'MinionB' network.ip_addrs

This shows you the entire contents of network.ip_addrs that MinionB
sends to the mine on the master.

In a state, assuming you're using yaml|jinja:

your_minion_a_state_id:
file.managed:
- name: /tmp/minion_b_first_ip
- contents: {{ salt['mine.get']('MinionB',
'network.ip_addrs').get('MinionB')[0] }}

or use {%- set minionb_ip0 = salt['mine.get']... -%} to set a variable
for re-use in multiple places.
--
Dave