How does grafanactl relate to Grafana Grizzly?

[radiohead]

Hey folks!

We've seen some questions around, asking how does grafanactl relate to Grafana Grizzly, so we'd like to clarify this.

Grafana Grizzly has been the de-facto CLI tool for Grafana (and various other Grafana Labs products) for a while and we will continue supporting it at our best effort, fixing bugs and any potential security vulnerabilities.

That said, we will be phasing it out over time, absorbing its functionality into grafanactl over time and eventually Grizzly will be discontinued and no longer supported.

This is going to be a long process, so if you are using Grizzly today – worry not, we are not going to drop its support tomorrow. However, if you are just starting to use a CLI tool in your development or CI / CD workflows, it's a good idea to pick up grafanactl – it will only get bigger and better from now on!

For more information, feel free to check out our official docs.

If you have any questions, feel free to ask them here!

[mikaello]

I'm curious about the motivation behind creating a new CLI tool to replace Grizzly. Could you share a bit about the reasoning or goals that led to this decision?

[radiohead]

Sure! There are a few factors, but most importantly it was the fact that Grizzly was our first iteration of a CLI tool and it was built on top of completely different APIs and with different approaches.

Back then our APIs (especially in Grafana) were not very tooling-friendly and we had to bake a lot of workarounds into the tool itself.

While the existing APIs haven't changed too much, the new APIs (https://grafana.com/docs/grafana/latest/developers/http_api/apis/) have been built with tooling in mind and we've agreed that we'd like to migrate all of our tooling to use those.

When we evaluated our options, it netted to a complete re-write of Grizzly (sorta Grizzly 2.0) but since the new APIs are added incrementally, it meant that that re-write would end up losing features, compared to what it currently has.

With that in mind, we've instead decided to start something else, taking into account the new vision for the APIs & observability-as-code and the lessons learned from Grizzly.

[malcolmholmes]

FWIW, as the original creator of Grizzly (but no longer working on it), this seems totally fair. The purpose of Grizzly was to give something of a similar experience working with Grafana to that of working with Kubernetes. But it was an essentially impossible task, given the APIs Grafana presented were hand-crafted and all different. Grizzly's role therefore pretty much became to work around those issues and inconsistencies, which it managed with some, but certainly not complete, success.

grafanactl on the other hand is working with a new set of APIs that have been thought out from a consistency perspective. So it (hopefully!) becomes possible to have a much more generic tool without the workarounds. A resource is just a resource - it is delivered to the API server in the same way, regardless of its type/kind.

These APIs are definitely the APIs I wish we had had when I first started on Grizzly!

[mikaello]

In addition to features that interact directly with Grafana resources, Grizzly also supports development and review workflows with commands like serve and snapshot. Do you plan to continue supporting these workflows in grafanactl?

Also, are there any other Grizzly subcommands that won't be carried over to grafanactl, or that you expect to handle differently?

[radiohead]

Do you plan to continue supporting these workflows in grafanactl?

Yes, we definitely plan to support development workflows in grafanactl. In fact, we've already implemented some of it, e.g. grafanactl resources serve works almost the same as in Grizzly.

Also, are there any other Grizzly subcommands that won't be carried over to grafanactl, or that you expect to handle differently?

Most likely all commands will function at least slightly differently. As to what functionality won't be carried over – I don't have a specific answer right now, but we've so far agreed to not bake first-class support for Jsonnet – it's something that we'd rather let other tools like jsonnet-bundler and jsonnet itself take care of and instead have workflows which rely on using the right tool for the right job, sort of following the UNIX tools philosophy.

[xinity]

thanks all for the feedback, one concern here, the grafana 12 apis are fairly new so to speak and so grafanactl.
For someone who runs couple of observability stack grafana based, I'm wondering if I can migrate safely to grafanactl AND grafana 12 or if I should stick with grizzly and grafana 11 for couple of months ....

[malcolmholmes]

@xinity I would base that on features. If grafanactl has the features you want, then use it. If not, stick with Grizzly for the time being. If your usage is broad, then you may need to wait a little for grafanactl features.

[abh]

The last commit was in middle of May. Is development of this tool happening in a private repository or is it stalled / paused?

[konsalex]

@abh you could take a look here 🙏:
#123 (comment)