Help with ini_manage state

[David Kilcy]

Hi Everybody,
I am trying to use the ini_manage state.
salt 2014.7.0rc3 (Helium)

My sls file contains the following entry:

/etc/keystone/keystone.conf:
  ini_manage:
    - options_present
    - sections:
        database:
          connection: mysql://keystone:{{ keystone_dbpass }}@{{ mysql_host }}/keystone
        DEFAULT:
          admin_token: {{ admin_token }}


Whenever I run a highstate I get the following:

----------
          ID: /etc/keystone/keystone.conf
    Function: ini_manage.options_present
      Result: False
     Comment: State 'ini_manage.options_present' found in SLS 'openstack.keystone' is unavailable
     Started:
    Duration:
     Changes:  

I've tried running with debug and checking the logs, but to no avail.
Can anyone help me debug this issue/check my syntax.  Am I doing something wrong?

Contents of the file I am trying to change:

[root@controller-01 ~]$ cat /etc/keystone/keystone.conf | grep -v ^$ | grep -v ^#
[DEFAULT]
[assignment]
[auth]
[cache]
[catalog]
[credential]
[database]
[ec2]
[endpoint_filter]
[federation]
[identity]
[kvs]
[ldap]
[matchmaker_ring]
[memcache]
[oauth1]
[os_inherit]
[paste_deploy]
[policy]
[revoke]
[signing]
[ssl]
[stats]
[token]
[trust]


Thanks
David

[David Kilcy]

EDIT: tried single and double quotes around the connection key, no change

[David Kilcy]

I attempted to try a 'hello world' example based on the entry from the 'salt.state.ini_manage' state like so:

/tmp/foo.ini:

  ini_manage:
    - options_present
    - sections:

        test:
          testkey: 'testval'

and created a /tmp/foo.ini file.   I tried with an empty file, with test section present and testkey present.
No luck. Continue to get

State 'ini_manage.options_present' found in SLS 'scratch' is unavailable

This feature does not appear to work at all. 
Thanks

[David Boucha]

the state renames itself to just 'ini', but the docs incorrectly say to use ini_manage.

/tmp/foo.ini:

  ini:

    - options_present

Once I got past that, I'm getting another error saying the the file '/tmp/foo.ini' doesn't exist. Even if I create the file by hand. I'm not sure what's going on there, yet.

--
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.

[Akilesh K]

Hi All,

I am the author of ini_manage. As dave pointed out you have to use 'ini' to call the module. I will look into this right away. meanwhile is there a place where users can report bugs directly on a module and the authors would get a notification? That would be so nice to track the issue.

[David Boucha]

Akilesh,

I just opened a bug here:  https://github.com/saltstack/salt/issues/16379

[David Kilcy]

Thanks guys.
I was able to work around the problem by using the openstack-config state (since I just happen to be working with OpenStack)
I'll watch the bug and would be glad to do additional testing once fix its pushed.

[Onno]

I'm using salt 2014.1.7 and I can't figure out why this state is not
behaving as expected:

test-me:
file.managed:
- name: /root/foobar.txt
- source:
- salt://test/foobar.txt
- unless: test -f /root/no-foobar.lock

What I expect to happen:
- Create /root/foobar.txt if /root/no-foobar.lock is not there. _OR_
- Do not create /root/foobar.txt if /root/no-foobar.lock is there.

What I see:
- /root/foobar.txt is created regardless if /root/no-foobar.lock is
there or not

Did I read the doc's incorrectly? Typos? Can somebody give me a hint?

Thanks,
Onno

[Onno]

Onno schreef op 2014-10-04 14:24:

Oh... "New in version 2014.7.0."... that would explain it...

Can I simulate the "unless" in 2014.1.7 ???

Thanks,
Onno

[Akilesh K]

Hi guys,

Just pushed to changes to develop branch(https://github.com/saltstack/salt/pull/16385). I am attaching the files too. Please add them as custom modules to your system, sync them and let me know if the problem persists.

@David Boucha

I can not see why the module would fail even if you manually created a file (other than lacking read/write permission) . Can you check with the new files and let me know if problem persists.

[Onno]

Onno schreef op 2014-10-04 14:33:

For reference, I settled on:

{% if salt['cmd.retcode']('test test -f /root/no-foobar.lock') != 0 %}

test-me:
file.managed:
- name: /root/foobar.txt
- source:
- salt://test/foobar.txt

{% endif %}

Kind regards,
Onno

[Onno]

Hi all,

My sls file:

--
cassandra-init-d:
file.managed:
- name: /etc/rc.d/init.d/cassandra
- source:
- salt://init-d/_etc_rc.d_init.d_cassandra.{{grains['id']}}
- salt://init-d/_etc_rc.d_init.d_cassandra
- mode: 755
- require:
- sls: daemonize

cassandra-log:
file.absent:
- name: /var/log/cassandra/cassandra.log
- watch:
- file: cassandra-init-d

cassandra-service:
service.running:
- name: cassandra
- watch:
- file: cassandra-log
--

In the first run, the id's "cassandra-init-d", "cassandra-log" and
"cassandra-service" are run. In the second run, the id's "cassandra-log"
and "cassandra-service" are run. I didn't expect to run anything at all
in the second run due to the "watch" in "cassandra-log"... What am I
doing wrong?

Regards,
Onno

[Colton Myers]

The `watch` requisite actually behaves exactly like the `require` requisite, but adds *additional* behavior when there are changes. What you're looking for is the `onchanges` requisite, which is new in 2014.7.0, the release that was cut today.

Hope that helps!

--
Colton Myers (basepi)

Platform Engineer, SaltStack