Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dashboard support to {export,import}_configuration #211

Open
pederhan opened this issue Sep 16, 2024 · 1 comment
Open

Add dashboard support to {export,import}_configuration #211

pederhan opened this issue Sep 16, 2024 · 1 comment

Comments

@pederhan
Copy link
Member

pederhan commented Sep 16, 2024

Zabbix-cli should have the ability to export and import dashboards. In cases where we want to import a dashboard containing hosts that don't exist in the system, we should prompt the user for replacement hosts and/or give them the ability to provide a mapping of old to new hosts.

A key pain point in importing dashboards is that widgets are identified by ID, and each widget has a different ID for every Zabbix instance. This can lead to broken dashboards when exporting a dashboard in one instance and importing in another. By default, we should strip all widgets and optionally provide users with the ability to specify replacement widgets.

Technical challenges

Dashboard exporting/importing is not supported by configuration.{export,import}. We will have to use dashboard.{get,create,update} in order to support this. That begs the question of: should this really be added to {export,import}_configuration?

On the one hand, the interface makes sense for the user; everything is located in {export,import}_configuration. However, adding this functionality to the existing export/import code has the potential for making it very messy. The code has been written in a way that it is open to refactoring for additional configuration.export types, but not necessarily for adding such hacks that use other endpoints.

I do think we should try to add this to {export,import}_configuration, but it needs to be done without making things too messy.

Interface

Another challenge of incorporating this into {export,import}_configuration is how to handle user inputs, whether to prompt for replacements etc. I can see an interface like this:

zabbix-cli export_configuration --type dashboards --prompt
zabbix-cli export_configuration --type dashboards --host-mapping hosts_mapping.yaml
zabbix-cli export_configuration --type dashboards --strip-widgets/--no-strip-widgets

I'm not a huge fan of options that only have an effect given certain arguments, but we could "namespace" them by prefixing them with dashboard

zabbix-cli export_configuration --type dashboards --dashboard-prompt
zabbix-cli export_configuration --type dashboards --dashboard-host-mapping hosts_mapping.yaml
zabbix-cli export_configuration --type dashboards --dashboard-strip-widgets/--no-dashboard-strip-widgets

This is very verbose, but avoids any ambiguity as to what these options are related to. However, in the future perhaps we want to prompt for other object types, then we could end up with --dashboard-prompt, --script-prompt, etc. which is not ideal.

A happy medium is maybe something like this:

zabbix-cli export_configuration --type dashboards --prompt
zabbix-cli export_configuration --type dashboards --dashboard-host-mapping hosts_mapping.yaml
zabbix-cli export_configuration --type dashboards --dashboard-strip-widgets/--no-dashboard-strip-widgets
@rysavy-tech
Copy link

rysavy-tech commented Sep 16, 2024

There's no need to deal with widget IDs so complicatedly. Simply:

  1. Remove all IDs (widget ID, page ID, UUID) from the YAML file during export. These IDs aren't necessary for import.
  2. Use widget names for proper linking during import.

Code to remove IDs could look like this:

for page in dash["pages"]:
    if "uuid" in page:
        del page["uuid"]
    for widget in page["widgets"]:
        del widget["widgetid"]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants