You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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 usedashboard.{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 additionalconfiguration.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: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
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:
The text was updated successfully, but these errors were encountered: