introducing `jhack list-endpoints`

charm
, ,
1

Hi folks!

Jhack just released on edge with a shiny new command: list-endpoints.

Get it from the Snap Store

This command will show, for a given charm, what relation integration endpoints it supports.

image
image1061×280 85.3 KB

It divides them by role, so you can see at a glance what a charm provides and requires, and what it talks about with its peers.

Compare it with juju status loki --relations:

image
image773×319 130 KB

we see

  • less information: it only shows the integrations, nothing else about loki.
  • more information: it attempts to show the version of the charm library implementing the integration. For details about how this is done and caveats, see the readme docs.
  • different presentation. Tables are cool. And splitting the endpoints by role felt more intuitive to me.

TODO

cross-model!

4 Likes
2

This is amazing Pietro!!! :partying_face: :partying_face:

1 Like
3

Awesome!

How do you infer the “version”? Implicitly assume the lib name matches the iface name?

Would it be possible to mark the libs that the charm owns?

4

precisely! So if for some reason they don’t match, I can’t guess the version. but I reckon the somewhat universal standard (as mentioned in the style guide) is to name lib files after the interfaces they implement, and I have to say so far it works in ~95% of the cases.

And yes, we can consider marking the libraries owned by this charm, or show the owner like in jhack vinfo

image
image1089×533 52.4 KB

what is the ‘use case’, or why would you like that?

5

Currently, to figure out where I need to go to submit issue/fix for a lib, I need to:

  1. juju status to narrow down the search to two charms.
  2. Go to the one charm’s page on charmhub and see if the lib is in the “libraries” tab. If it’s not, then it must be the other charm.
6

good point, but jhack charm vinfo has you covered then. I don’t mind adding the owner here too though:

image
image1260×182 40.4 KB

WDYT?

7

Seems a bit verbose. I was thinking something like a * to denote ownership:

+----------+--------------+--------------------+---------------+----------------+
| Role     | Endpoint     | Interface          | Local version | Remote version |
+----------+--------------+--------------------+---------------+----------------+
| Requires | certificates |   tls_certificates | 2.0           | 2.1            |
+----------+--------------+--------------------+---------------+----------------+
| Provides | logging      | * loki_push_api    | 0.5           | 0.6            |
+----------+--------------+--------------------+---------------+----------------+
8

but what if the bug is in tls_certificates, then you still have no clue where you have to file the bug/fix