Improvements on ROCKs snap tracks

store-requests
1

Hi,

As you may know, we, the maintainers of Ubuntu ROCKs, have been

maintaining a few images based on snaps that are shipped through the snap store. We do so to leverage the transparency and traceability provided by the snapcraft tooling.

Up until now, we had been requesting new tracks for the snaps we use to build those ROCKs in every Ubuntu cycle to provide stable ROCK releases for our Ubuntu based ROCKs. These tracks are named after Ubuntu release numbers (e.g., 20.04, 21.10, etc.).

We understand this approach is not best aligned with the snap store design and we want to move forward with changing the way we handle these ROCK-specific tracks.

Some of our snaps are co-maintained with teams whose focus may be the productization of such snaps; in this case, we prefer to keep our ROCK-specific snap in a separate track. For consistency, we decided to use ROCK-specific tracks for all our snaps, even those that are maintained solely by us.

This new approach will simplify things for us and will also mean that we will no longer bind the track names to Ubuntu release numbers. . Instead, as a first step, we would like to have a separate rock track created for each of these snaps. Once all the snap-based ROCKs get released (with the Jammy release), we will move to the second step of this effort, which should be requesting the removal of all tracks named after Ubuntu release numbers (e.g., grafana 20.04, 21.04, and 21.10).

When the effort is complete, we will only need to request new tracks if and when we have to create a new snap to serve as the base for a new ROCK, instead of requesting a new track for every snap based ROCK being shipped every time Ubuntu does a new release.

These are the snaps we would like to have the rock track created for:

  • grafana
  • prometheus
  • prometheus-alert-manager
  • cassandra
  • loki
  • kafka

Thank you!

1 Like
2

In short, we need new tracks named rock for the following snaps:

3

Hello!

For referential integrity reasons we cannot remove tracks. You can close all channels under a track, it should achieve the same practical effect.

What would these new tracks be named? (just as an example).

I can create these, not a problem. Just wanted to confirm that you have run this by the teams that own those charms, as a new rocks track sprouting without their knowledge would be confusing :slight_smile:

Also could you please double-check the charm names and verify they are what you expect? e.g. https://charmhub.io/grafana is a legacy charm maintained by the llama-charmers team, not sure that’s the one you want. Also, the loki charm does not exist (https://charmhub.io/loki), and there’s both a machine- and a k8s- version of kafka (see Charmhub | Deploy Kafka K8s using Charmhub - The Open Operator Collection). For kafka, there’s unambiguously one kafka charm (Charmhub | Deploy Kafka using Charmhub - The Open Operator Collection), but I wonder if you meant the kafka-k8s one.

Please help me validate those two things, give me an updated list and I’ll gladly create the rock track as you requested.

  • Daniel
4

Hi Daniel,

Thanks for taking a look on this one :slight_smile:

Great. We will deal with those on our own when the time comes then.

They will always be named rock from now on.

Not sure if I fully understand this one. We want the tracks created for the snaps in the list, not for charms. Am I missing something?

So, we need a new rock track created for the following snaps:

We (@sergiodj and I) either co-maintain or own the snaps in the list above.

Does this answer your question? Are there any other information I need to gather regarding charms for some reason I missed?

5

Wow, no, you’re not missing anything, I’m just dumb.

I’ll create the tracks in a moment :slight_smile:

6

The rock track is created for all these snaps now.

  • Daniel
1 Like
7

Thank you very much, @roadmr.

8

Thank you, Daniel!!!