[elasticsearch/sysconfig] use ini_manage

[arthurzenika]

instead of file.managed, so we can keep documentation
comments and the other variables one can tweak

solves #21

[blbradley]

/etc/default/elasticsearch is not an ini file. So, this is not semantically correct.

Have a look at file.managed's contents_pillar. It may do what you want.

[arthurzenika]

I beg to differ "Keys may (but need not) be grouped into arbitrarily named sections. " https://en.wikipedia.org/wiki/INI_file#Sections

(and it seems that travis is failing on something different)

[blbradley]

I fixed the failing test in master.

Comments in INI format start with ;. Comments in scripts and environments files start with #. I'm afraid the shoe just does not fit.

[arthurzenika]

Are we being picky about names or you prefer the file.managed approach ? I think it serves the user to keep the documentation in the /etc/default/elasticsearch file

The ini_manage module user # by default https://github.com/saltstack/salt/blob/develop/salt/modules/ini_manage.py#L198

I guess it was primarily developed to manage openstack ini files http://docs.openstack.org/icehouse/config-reference/content/config_format.html which uses # too.

[blbradley]

Are we being picky about names or you prefer the file.managed approach ?

Neither. I'm weary of breaking the formula for other users.

I think it serves the user to keep the documentation in the /etc/default/elasticsearch file

Do you keep your pillar data in a git repository? This would be a great place for people to look for specific documentation vs a file on a server.

The ini_manage module uses # by default

This is true, but it doesn't follow the INI spec. From https://en.wikipedia.org/wiki/INI_file#Varying_features:

Some software supports the use of the number sign (#) as an alternative to the semicolon for indicating comments.

[cmclaughlin]

As a compromise, perhaps simply add the backup option on file.managed... that way the user has the original file with all the comments intact.