OpenIndiana not recognized by service.status

[ksalman]

I have some OpenIndiana (Solaris) and it looks like they aren't recognized by the service module - probably the smf module. I think this is because the os_family returns OpenIndianaDevelopment instead of Solaris

OpenIndiana host:

root@ranger:~# salt-call grains.get os_family
[INFO    ] Executing command '/usr/sbin/zfs help || :' in directory '/root'
local:
    OpenIndianaDevelopment

root@ranger:~# salt-call service.status network/ntp
[INFO    ] Executing command '/usr/sbin/zfs help || :' in directory '/root'
Function service.status is not available

OmniOS host:

root@brigade:~# salt-call grains.get os_family
[INFO    ] Executing command '/usr/sbin/zfs help || :' in directory '/root'
local:
    Solaris

root@brigade:~# salt-call service.status network/ntp
[INFO    ] Executing command '/usr/sbin/zfs help || :' in directory '/root'
[INFO    ] Executing command '/usr/bin/svcs -H -o STATE network/ntp' in directory '/root'
[INFO    ] output: online
local:
    True

[ksalman]

I wrote a custom grain module to return {"os_family": "Solaris"} to override this as a work around. It works well but patching the smf module would still help.

[rallytime]

@ksalman - Thanks for the report! I'm glad you got a patch working for the time being. Could you post a salt --versions-report please?

I know @terminalmage did some work with the OS detection for Solaris in #10601, and it was cherry-picked into the 2014.1.1 release, so this may already be fixed.

[terminalmage]

@ksalman please post the contents of /etc/release.

[ksalman]

Here you go, /etc/release and salt --versions-report

root@ranger:~# cat /etc/release
             OpenIndiana Development oi_151.1.7 X86 (powered by illumos)
        Copyright 2011 Oracle and/or its affiliates. All rights reserved.
                        Use is subject to license terms.
                           Assembled 03 October 2012

root@ranger:~# salt --versions-report
           Salt: 2014.1.1
         Python: 2.7.6 (default, Feb 19 2014, 13:37:36)
         Jinja2: 2.7.1
       M2Crypto: 0.21.1
 msgpack-python: 0.1.13
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
         PyYAML: 3.10
          PyZMQ: 13.1.0
            ZMQ: 3.2.4

[terminalmage]

Thanks, I'll take a look today.

[terminalmage]

Oh, and when you get a chance, can you run salt minion-id grains.item saltversion for one of the OpenIndiana minions (replacing minion-id of course), and salt-call --versions-report on that same minion? salt --versions-report just gives you the version of the master, so it'll help to have a fuller picture.

[ksalman]

root@overseer:~# salt ranger grains.item saltversion
ranger:
  saltversion: 2014.1.1

server versions

root@overseer:~# salt --versions-report
           Salt: 2014.1.1
         Python: 2.7.3 (default, Jan  2 2013, 16:53:07)
         Jinja2: 2.6
       M2Crypto: 0.21.1
 msgpack-python: 0.1.10
   msgpack-pure: Not Installed
       pycrypto: 2.6
         PyYAML: 3.10
          PyZMQ: 13.1.0
            ZMQ: 3.2.3

minion versions

root@ranger:~# salt-call --versions-report
           Salt: 2014.1.1
         Python: 2.7.6 (default, Feb 19 2014, 13:37:36)
         Jinja2: 2.7.1
       M2Crypto: 0.21.1
 msgpack-python: 0.1.13
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
         PyYAML: 3.10
          PyZMQ: 13.1.0
            ZMQ: 3.2.4

[terminalmage]

Great, thanks! Just wanted to rule out the minion having been updated and the service not being restarted, so I know for certain that what came up in salt-call --versions-report matches what is actually running in memory.

[terminalmage]

@ksalman Is the os grain the same (OpenIndianaDevelopment)?

[ksalman]

@terminalmage Yes. os os_family, and osfullname are all OpenIndianaDevelopment

[terminalmage]

@ksalman Found and fixed: #12019

Unfortunately, this fix missed making it into 2014.1.2 by an hour or two, so you'll need to continue to use your workaround until the next release.

Thanks very much for bringing this to our attention.

[ksalman]

thanks for the fix!

[terminalmage]

No prob!

[terminalmage]

@ksalman Oh, just one other tip. Another way of manually setting a grain without making custom grains module is to use grains.setval to set the grain. It gets written to a YAML file (/etc/salt/grains) so it persists salt-minion service restarts. When you're done with this grain, you can use grains.delval (with destructive=True) to remove the grain and delete it from /etc/salt/grains.

[ksalman]

Oh that is a good point. I have used grains.setval before but it didn't occur to me to use it on existing grains, thanks :)

On Wed, Apr 16, 2014 at 6:58 AM, Erik Johnson notifications@github.com
wrote:

@ksalman Oh, just one other tip. Another way of manually setting a grain without making custom grains module is to use grains.setval to set the grain. It gets written to a YAML file (/etc/salt/grains) so it persists salt-minion service restarts. When you're done with this grain, you can use grains.delval (with destructive=True) to remove the grain and delete it from /etc/salt/grains.

Reply to this email directly or view it on GitHub:
#11907 (comment)

[terminalmage]

Yep, there is an order of precedence where grains are evaluated, this order can be found here in the docs.