Zabbix Proxy SQLite database has to be deleted as "version_repo" changes - Need help

[xenadmin]

Note that with SQLite database on proxies, history data from proxies before the upgrade will be lost, because SQLite database upgrade is not supported and the SQLite database file has to be manually removed. When proxy is started for the first time and the SQLite database file is missing, proxy creates it automatically.

Source: https://www.zabbix.com/documentation/4.2/manual/installation/upgrade/packages/debian_ubuntu

All the effort I've done for this formula in the last months, was for one large project: I would like to use Saltstack. to help me lift my 30+ Zabbix Proxies from 4.0 to 4.2 and later on to 4.4.

One point I've missed during my planing, was that I have to drop/delete the Zabbix Proxy SQLite database file. I'm not fit enough with Saltstack yet, and would like to ask for help. Right now, I have no idea where to start. I would guess I have to add some lines in "https://github.com/saltstack-formulas/zabbix-formula/blob/master/zabbix/proxy/init.sls" after line 57.

Maybe something like: "onchanges_in pillar.version.repo execute sls.zabbix_proxy_del_sqlite -> cmd.run rm pillar.dbname + watch_in service: zabbix-proxy"

The process would have to be like this:

1. The value of the pillar version_repo changes (onchanges?)
2. Zabbix Proxy has to be stopped (watch?)
3. SQLite has to be dropped (cmd.run?)
4. New Zabbix repo has to be installed (that's already the case I guess)
5. New Zabbix Proxy daemon has to be installed (that's already the case I guess)
6. Zabbix Proxy daemon gets started (that's already the case I guess)
   1. New Zabbix Proxy SQLite database gets created by the daemon

May I ask for your help @hatifnatt and @aboe76 ?

[hatifnatt]

I can suggest write separate state for upgrade only. And this state will do all steps you described. You can't catch pillar changes with onchanges but in this particular case onchanges can be applied to state which update repo file, but this will work only on first run (not counting test runs), after changing the pillars. There some draft how proxy/upgrade.sls can look like, code below is not tested in any way, but I hope you can get the idea.

{% from "zabbix/map.jinja" import zabbix with context %}
{% set settings = salt['pillar.get']('zabbix-proxy', {}) -%}
{% set defaults = zabbix.get('proxy', {}) -%}

# We have a common template for the official Zabbix repo
{% include "zabbix/repo.sls" %}

# Here we just add a requisite declaration to ensure correct order
extend:
  zabbix_proxy_repo:
    {% if salt['grains.get']('os_family') == 'Debian' -%}
    pkgrepo:
      - require_in:
        - pkg: zabbix-proxy-upgrade
        - service: zabbix-proxy-stop
    {% elif salt['grains.get']('os_family') == 'RedHat' -%}
    pkgrepo:
      - require_in:
        - pkg: zabbix-proxy-upgrade
        - service: zabbix-proxy-stop
  zabbix_proxy_non_supported_repo:
    pkgrepo:
      - require_in:
        - pkg: zabbix-proxy-upgrade
        - service: zabbix-proxy-stop
    {%- else %} {}
    {%- endif %}

zabbix-proxy-stop:
  service.dead:
    - name: {{ zabbix.proxy.service }}
    - onchanges_any:
      # after repo version will be changed `zabbix_proxy_repo` state will have changes,
      # but only on first run
      - pkgrepo: zabbix_proxy_repo
      - pkgrepo: zabbix_proxy_non_supported_repo

# basic check does 'dbname' looks like a file path
{% if zabbix.proxy.dbname.startswith('/') -%}
zabbix-proxy-dropdb:
  file.absent:
     - name: {{ zabbix.proxy.dbname }}
{%- endif %}

# upgrade package, `zabbix.proxy.version` is really important,
# otherwise package most likely will not be upgraded
zabbix-proxy-upgrade:
  pkg.installed:
    - pkgs:
      {%- for name in zabbix.proxy.pkgs %}
      - {{ name }}{% if zabbix.proxy.version is defined and 'zabbix' in name %}: '{{ zabbix.proxy.version }}'{% endif %}
      {%- endfor %}

# make sure that service is running
zabbix-proxy-start:
  service.running:
    - name: {{ zabbix.proxy.service }}
    - enable: True

[xenadmin]

@hatifnatt Thank you very much for your suggestion. But I'm not happy with it (no offense). This looks much to complicated for such a simple problem, so I thought a second time about it.

There could be a much simpler, pragmatic and dirty solution: Let's write the repo version into the SQLite DB path!

Took me one hour to research the fu*!#g syntax for it, but it seems to work very well. The only downside is, that the old SQLite files will idle in the filesystem, but I couldn't care less.

I define my version currently like this -> /srv/pillar/zabbix/init.sls

zabbix:
  lookup:
    version_repo: 4.0

Then I define my proxy like this (excerpt) and add an import! which is then used to alter the SQLite path, so each and every time I use salt to switch to a new major version (4.0->4.2), the path gets changed and due to our mutual changes in #115 the patch will get created accordingly and the watch_in statement in zabbix-formula/zabbix/proxy/conf.sls will restart the service -> /srv/pillar/zabbix/proxy.sls

{% import_yaml '/srv/pillar/zabbix/init.sls' as repo %}

zabbix-proxy:
  proxymode: "0"
  dbname: /var/lib/zabbix{{ repo.zabbix.lookup.version_repo }}/zabbix.sqlite.db
  proxyofflinebuffer: "80"
  historycachesize: 512M
....

root@salt:/etc/salt/master.d# salt 'zabprox.*' state.apply test=true

----------
          ID: /etc/zabbix/zabbix_proxy.conf
    Function: file.managed
      Result: None
     Comment: The file /etc/zabbix/zabbix_proxy.conf is set to be changed
     Started: 18:24:36.643999
    Duration: 315.034 ms
     Changes:   
              ----------
              diff:
                  --- 
                  +++ 
                  @@ -180,7 +180,7 @@
                   # Mandatory: yes
                   # Default:
                   # DBName=
                  -DBName=/var/lib/zabbix/zabbix.sqlite.db
                  +DBName=/var/lib/zabbix4.0/zabbix.sqlite.db

                   ### Option: DBSchema
                   #    Schema name. Used for IBM DB2 and PostgreSQL.

What do you think? We could add this as an example in pillar.example.