Add real support for plugin-specific INI settings

[kitsuta]

Right now we add variables to a big uber.development.ini.erb; however, there are variables in plugins we want to set through puppet. It'd be better if we separated these out somehow (or even just put a check for that plugin in the template) so other events can safely use this puppet repo without using the exact same plugins that MAGFest does.

[binary1230]

I think I have a detailed ticket for this open somewhere

[binary1230]

I totally can't find it.

Essentially the task here is: do what the barcode manifest is doing, except, do it in a generic way.

Only I'm not sure that's possible.

The only thing is how ti works is for each plugin's .ini file, we will need an .erb template, because the .erb template tells it what to put in.

The easiest way to do this is to create a bunch of plugin-specific manifests with .erbs, (like plugin_barcode) but not have them required to be included by default as plugin_barcode is now. This is actually easy and we can have them be included from the YAML file on a per-environment basis

[kitsuta]

That's a bit of a pain, but I suppose that's what you get for having functionality spread around in plugins. :)

At any rate, once we implement this we should take out the hacky "if variable exists" solution I put in the main uber-development.ini.erb template I have now for hotel-req-hours and hide-schedule.

[EliAndrewC]

If there's some way to do a variant of "The Final Puppetization" then it would totally work here. An ini file is really just a dictionary. Like, the configobj library literally just parses the ini files into a literal dictionary object. And our yaml files are also literally just dictionaries, so there's no reason why we couldn't have a YAML file that looks like

config:
    foo: 5
    bar:
        baz: 6
        spam:
            hello: "world"

that would render the following to the plugin's development.ini file:

foo = 5
[bar]
baz = 6
[[spam]
hello = "world"

Perhaps some plugins would want/need to replace this with their own custom puppet, but honestly I think this would work for literally every plugin that MAGFest is likely to ever write. In that case we could just have a single plugin-development-ini.erb template which iterates over the config dictionary from the yaml data and renders the template with it as shown above.

"There, that was easy to describe, so I'm sure it's easy to do!" :P

All joking aside, I have no idea whether that would be easy or hard, since I'm still just a puppet novice, but that does seem like it should be possible.

[binary1230]

Eli, the more we get deeper into the rabbit hole the more that solution looks appealing. It should be easy to implement, the templates are full-blown ruby so should have good support for that sort of thing.

The only hangup is merely that having the .erb template pull data directly out of hiera is specifically recommended against as a best practice. The idea is that the data is supposed to go hiera-->>manifest-->>ini .erb template, so that the manifest can validate config data and/or do other stuff with it.

But..... it really might just be a good solution for us to break that and do the hiera->template directly.

[EliAndrewC]

The idea is that the data is supposed to go hiera-->>manifest-->>ini .erb template, so that the manifest can validate config data and/or do other stuff with it.

In our case, configobj already does validation on the data, and even allows us to provide default values. So like if someone tries to set hide_schedule to 'not a boolean' or set supporter_level to 'not an integer' then we'll get an error message when Sideboard starts and the plugin tries to parse the file, and the error message will specifically call out which config option had what problem.

So while it might generally be bad practice for people who are just using ConfigParser or some other random ``ini` tool, in our case I think it's fine.

[binary1230]

yea, alright let's try it. there might be some non-obvious puppet stuff that comes up later but we'll deal with it. it'll work for us for now anyway.

[binary1230]

related to (and potentially the same thing as) #28