This simply takes any json files present and loads them into Grafana
directly. The idea is that you can edit the dashboards using the
inbuilt editor, then copy the dashboard JSON and keep it externally
version controlled. No parsing or validation is done on the JSON
files; we are assuming they have not been hand-modified from what
Grafana generates.
Change-Id: I38695aed2404f8b7fc350d949b7a9212498c35cb
- retro-compatibility with default folder 'General' == 0
- add to config file with folderid key in grafana section
- add to cmd with --grafana-folderid
Change-Id: Iebfc5613f4c622d3d49d2f34df77ad3695f6b046
Help messages mention support for multiple config paths separated by colons.
Yet this feature is not implemented. This change implements it.
Change-Id: Ieb99cba98c9cf775765eacd4ebadfbccfa815a65
We now support the ability to create a datasource using yaml files.
Change-Id: I1db38ac25bc309398924c15635ea5dee4eaf264c
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Sadly, our unit tests missed this. Since we didn't actually test the
contents of the values. We have now fixed that with some unit tests.
Change-Id: Ida72768b51cb579fedb740f54d6f764e14f9d3d0
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Rather then hacking up our cache object while using a file backend, we
can simply ask dogpile.cache to use a null backend. This way we keep
things simple.
Change-Id: Ibf34c4e26652629c3ee589fdcdd65188792aafef
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Here we are creating a simple wrapper object to ConfigParser for the
purpose of simplifying our configuration. Now, we have a single
location to control our configuration defaults.
Change-Id: Ie49938b1eec183055bb8d462d70bcdfb733b360b
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Add the ability to delete dashboards based on the provided yaml file.
We also removed the assert_dashboard_exists function, as it didn't
really save us code.
Change-Id: I417a72fcc5252b36cadfe8881b4f5ca6acb7c753
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Currently we only support dashboards for Grafana, this is about to
change. For example, we also need to add the ability to create
datasources and even users. Here we are breaking out the logic into
more specific functions.
Additionaly, this helps when we eventually break out this code into
python-grafana.
Change-Id: I10a618adbf9052c8dccda38fefb7abf3a148d3b6
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
This is for the same reasoning as oslo_log. We don't want to depending
on OpenStack libraries.
Change-Id: I34e66af578d3f4b5ac5e710554aad91524285816
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
When I first started grafyaml, I wanted to better understand how
existing OpenStack libraries worked. So, with that in mind, I choose
oslo_log as the logging class for this program. However, now that we
have imported it under openstack-infra, we don't really want to depend
on OpenStack libraries, incase there is a breakage. The main reason
for this, if OpenStack libraries break, we still want the
infrastructure to work so we can fix the problem.
Change-Id: Iee9b1d9d9abb4da4d285531b64a7e2505240be12
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
When you run grafana-dashboards, it currently lacks some basic
information what it is actually doing. So, start building out some
logging to help others who decide to run the command.
Change-Id: I27b0c444139c5772b29ae3bd2c9550c6567dd4d6
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
The long term goal here is to eventually create python-grafana from
our embedded grafana.py file. So, most of this code just makes the
Grafana object more user friendly.
However, we've also added some validation around create_dashboard, we
added some checks before we create and after. To ensure we actually
created our new dashboards.
Finally, add some sphinx docs since everybody loves documentation.
Change-Id: Icbba403afe5208fbef1855118d4c3f4293461e00
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Like JJB, Zuul and Nodepool, we need to have a CLI command to validate
our configuration files.
Change-Id: I4ccac21a2d77917667e1e844ab9ee1f1f281ea9f
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Like we do with JJB, we create a md5sum of the dashboard then cache
it. This is a simple way to determine if a yaml file has changed.
Change-Id: If7b80b84c5bbcb0d30b0325bae6b8e726bb2f41b
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Currently grafana will generate a slug based on the title name. For
now, we can use an existing python library to do this. Ideally, we'll
need to make sure the slugs generated between both are kept in sync.
How hard can that be?
Also move our validation logic into parser.py, since they are closely
related.
Change-Id: Id43f51d3f9db9131c25a8130f957572344a7d8f1
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Grafana 2.1.0 added basic auth support. With that in mind, the api key
is now optional.
Change-Id: Ie186fa9ce48ca4ae222f75345e9b660f5ffa2909
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
This will centeralize our overlapping yaml code paths.
Change-Id: Ib8bc0fc93b49363cb511d9891a24ea48fdee136d
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
This is the first attempt at the CLI client. Right now, we just support the
update function, which will blindly create a dashboard in grafana with ZERO
validation. Additionally, we blindly override any existing dashboard that has
been created.
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Ian Wienand