ini_file feature for populating an INI file from a variable

Archives Ansible Developer
1

Hi all,

I’ve put together a feature for ini_file and am not sure whether I should submit a PR for it or not. The problem I had was that there’s no way to fully manage an INI file: You can add/remove individual options, but you can’t for instance, have ini_file remove any option that doesn’t appear in some list of options that should be present: Instead, you have to explicitly state and maintain a list of what should not be there. So, I added a new contents param to ini_file that takes a dict of dicts, so you could do something like this:

2

Can you just template the INI file in your use case?

(i…e not rely on the ini_file module?)

3

Can you just template the INI file in your use case?

(i…e not rely on the ini_file module?)

That’s where I started, but it doesn’t work so well because in the case of the application I’m writing this for, arbitrary sections can be added to the ini. For example, the default version of the ini comes with a [server:main] section to start the application under Paste, but you can start multiple processes by defining an arbitrary number of additional [server;] sections, or start with uWSGI by adding a [uwsgi] section, etc.

Since the goal is to provide a redistributable role in Galaxy, I don’t know beforehand what config people will use.

4

Got it.

The other question is can the application support a “conf.d/” style configuration scheme, though that’s likely a no.

Supporting a state=absent with a “with_items” seems largely sufficient to me.

If we say “these contents are in the file”, and someone adds something, and it doesn’t just say things are in and out, but clobbers the entire file, that doesn’t seem too different from the template module?

I’m still not entirely understanding, perhaps though…

5

Got it.

The other question is can the application support a “conf.d/” style configuration scheme, though that’s likely a no.

Supporting a state=absent with a “with_items” seems largely sufficient to me.

If we say “these contents are in the file”, and someone adds something, and it doesn’t just say things are in and out, but clobbers the entire file, that doesn’t seem too different from the template module?

I’m still not entirely understanding, perhaps though…

Hmm… might be able to support conf.d/, I’ll have to play around with the various application stacks we support to see if they can all do it.

In the case of Paste, for example, you can name your servers anything, so it would be up to each individual deployer to know they at some point created a server with a certain name and they explicitly want to remove it. This makes it a lot harder to know exactly what the file will look like after running the play, and means you have to pay very close attention to its contents (probably what one should be doing anyway, but it’s not the most automation-friendly process). The state=absent list of items would either grow over time but do nothing after the first run or else be used for a single run and then removed.

The other limitation I ran into with doing it using template is that you have to template all the possible options, which I can provide defaults for, but there’s no way to leave an option out of the resulting ini entirely once it’s templated. For the most part, setting everything to a default is okay, although a few options exist where there is no way to set the option to a default in a way that it is treated the same as if the option was not set at all. That said, this is part of an application I develop on, so I can probably fix those cases.

Actually, something like this for every templated option deals with that problem, if not a bit ugly:

{{ "foo = " ~ ini_contents.section_foo.foo if ini_contents.section_foo.foo is defined else “” }}
{{ "baz = " ~ ini_contents.section_foo.baz if ini_contents.section_foo.baz is defined else “” }}

I think you’re right that the functionality ends up being roughly the same as the template module in the end. And thinking about it a bit more, I might be able to do the arbitrary sections using the looping constructs in J2.

Thanks,
–nate