Management of Kibana Dashboards

Ronny Trommer <[email protected]> Fri, 23 Mar 2018 10:28:36 +0100
Newsgroups	gmane.network.opennms.general
Message-ID	<[email protected]>
Hello World,

during with the Kibana Dashboards for Drift, I spent some time to think through the release management of those deliverables and how they depend on each other, see screenshot attached.

Disclaimer: The thoughts expressed here is just my point of view and might not be correct or complete. I’m very happy for any constructive input to improve our workflows and make our live easier :D

What do we have right now?

The Dashboards live in their own Git Repository which gives us the following possibilities:

- Bug/Issue handling against the dashboards
- Independent release of fixes and enhancements from Horizon/Meridian

This gives us the possibility to release improvements and fixes to Kibana Dashboards quick and does not rely on the whole release process of OpenNMS.

Where should we do Issue Handling and Release Management?

I personally would vote for JIRA, it drives all releases for all components in the OpenNMS world. I would disable the issue tracking on GitHub and use the README in the GitHub project define some Contribution Guidelines[1].

JIRA Component vs. JIRA Project

As I know, we have two options in JIRA where to track issues for Kibana Dashboards:

- Component in the OpenNMS Project (NMS)
- Own project which does not exist yet

Pro JIRA Component

- Less overhead
- Changes to the Dashboards are tracked in the Release Notes of Horizon
- Kibana Dashboards use the same version number as Horizon, makes it easy for users to figure out what to install

Contra JIRA Component

- Use the version number from Horizon and makes it complicated to deliver fixes between Horizon Releases, we loose velocity.
- We are forced to release new Dashboard versions with a new Horizon release even when nothing has changed.

Pro JIRA Project

- It is more transparent to users, where to open issues
- Kibana Dashboards would have its own Release Notes with Changelogs
- We can have a higher release velocity and deliver fixes/enhancements quicker

Contra Project

- Overhead is bigger, we need a dedicated release notes place
- Add more complexity, version numbers differ and it is harder to make transparent what version of the Dashboards work with which version of Horizon

A mixture of both, there is a JIRA add-on[3] which allows to version JIRA Components separately from the JIRA Project. I don’t know if this is worth dealing with.

How do we make the dependency relationships transparent?

Nevertheless with providing predefined dashboards in Kibana we introduce dependencies between the tools which need to be made transparent. We provide in the Installation/Upgrade section a Compatibility Matrix[2]. We could use this matrix for Kibana Dashboards as well.

I would personally prefer an approach, like "start simple as possible" and make it complicated when we really need it :)

Would be thankful to get some of your thoughts to drive a direction.

Greetings Ronny

[1] https://help.github.com/articles/setting-guidelines-for-repository-contributors/
[2] https://wiki.opennms.org/wiki/Installation_and_Upgrades
[3] https://marketplace.atlassian.com/plugins/com.deniz.jira.versioning/server/overview

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
signature.asc (application/pgp-signature, 529 B)