Keeping modules up to date

I feel like this is a simple and dumb question - how is best to keep modules up to date? I’ve noticed most of my modules are woefully out of date. I’ve been using the following as the method to install the modules.

git clone ${REPO} "${MODULES_PATH}/${MODULE_NAME}" --branch "${MODULE_VERSION}"
icingacli module enable "${MODULE_NAME}"

Thank you in advance for the pointers!

1 Like

I would be interested to see if someone has an automated way;

currently because many modules need to be on specific version for the Director module, we just have a manual maintenance routine to go through and update everything every so often :confused:

That’s where package management comes in handy :slight_smile: It can even handle dependencies! I’d imagine most setups only have one or two web servers, so building packages for yourself may be overkill.

I have considered using Salt to manage the updates. If you had a list of modules and versions/tags it wouldn’t be very difficult to translate that shell script to states and iterate over those variables. Since they’re only on one server and don’t change too often, I just haven’t gotten around to automating it.

If Director, for example, requires schema changes - are those applied automatically? Or do you still need to go into the Web UI and click a button?

1 Like

If Director, for example, requires schema changes - are those applied automatically? Or do you still need to go into the Web UI and click a button?

You might be able to import the sql file that director gives you to automate depending on the verbage of the file (ie update or ignore into or something), but not sure if that’ll keep everything safe and sound. Last time I did a director update (last month) I still had to click a button in the UI.

Salt isn’t a bad idea – for director and supporting modules, you could use gitfs and keep a copy of the repo(s) that are the current version you want, and then update the repos when something new comes out.

1 Like

I found some inspiration, need to sort through them since some use master currently and I’m not sure where the last tag was. Use caution since it includes a force reset:

{% for (module_name, module_branch) in [
    ('incubator', 'v0.6.0'),
    ('ipl', 'v0.5.0'),
    ('reactbundle', 'v0.9.0'),
] %}

icingaweb2_module_{{ module_name }}:
    - name:{{ module_name }}
    - remote: upstream
    - target: /usr/share/icingaweb2/modules/{{ module_name }}
    - rev: {{ module_branch }}
    - branch: salt-{{ module_branch }}
    - force_reset: True

{% endfor %}

Oh man, I’m gonna hold onto this – we have a plan to move from puppet to salt in the short term

1 Like

The director provides some automation for kickstart and schema migration, so no button pressing needed:

Automating the git workflow is an option, but it requires some git skill to do it good and is still error prone compared to packaging. The official puppet module is doing it ok at least, not sure about the other configuration management solutions.

Regarding packaging I hope Icinga will reach this state or we finish our discussions, so this will be the solution.


I appreciate all the feedback and suggestions here! I’m glad I’m not missing something obvious and it is indeed a manual process right now.

1 Like