3.8 tracks for maas and maas-test-db

store-requests
1

Hi there,

Could you please create the following tracks:

3.8 track with a guard-rail regex of 3\.8\..* for the maas snap.
3.8 track (with no guard-rail regexp) for the maas-test-db snap.

Store URLs:

https://snapcraft.io/maas and https://dashboard.snapcraft.io/snaps/maas/, snap id shY22YTZ3RhJJDOj0MfmShTNZTEb1Jiq
https://snapcraft.io/maas-test-db and https://dashboard.snapcraft.io/snaps/maas-test-db/, snap id idVMgkvkiKaOC8BjKlJRPUH50fvibpp8

Thanks

2

This request has not been added to the review queue. It should be placed in the appropriate store-requests subcategory using the subcategory template for classic-confinement, privileged-interfaces and aliases requests.

3

Hi there,

Could you confirm that you actually want a guardrail for the track, and not a version pattern? The regex you’ve asked for doesn’t match previous track patterns and seems to hint at a version pattern instead….

Melvin

4

Hi, mlathara!

I believe so. It is the same request we’ve done in previous MAAS versions: 3.7 tracks for maas and maas-test-db , 3.6 tracks for maas and maas-test-db

5

I think there’s a bit of misunderstanding here. I looked back a bit further and it seems like version pattern is what was previously (originally?) intended.

To clarify: version pattern ensures only appropriate versions are released to a particular track. Guardrails allow self service track creation based on a particular regex. Given that all your tracks are of the pattern <major>.<minor> and the regex above is <major>.<minor>.<patch/something else> I’m inclined to think this is probably version pattern and not guardrail.

Happy to be corrected though.

Melvin

6

Hi @mlathara

I also have a question on the above. Can we get access to the existing guardrails to understand what has been applied historically for the snap? If not, could you share them with us? Indeed, the MAAS snap tracks (both for maas and maas-test-db) are intended to be major.minor, apart from latest. I was under the impression that such guardrails already exist, but it seems not(?)

In addition, having such guardrails in the maas-region charm, allows us to create ourselves new tracks that comply to guardrails, from the charm store UI. Doing the same for the maas snap, is leading to an error in the UI. Can you help me understand why?

In theory we need one of the following guardrails: \d\.\d+ or \d+\.\d+

Thanks, Stamatis

7

@skatsaounis There’s no user facing way to access the guardrails, but I can get you that information.

For maasit’s a bit of a confusing mix - it looks like prior to 3.5 we were indeed setting the regex as version patterns (I think that would be appropriate for that particular regex). For 3.6 and 3.7 we actually set the pattern as guardrail. So the maas package has the following guardrails:

[
        {
            "pattern": "3\\.6\\..*",
            "created_at": "2024-12-12T13:16:30.632098"
        },
        {
            "pattern": "3\\.7\\..*",
            "created_at": "2025-07-02T04:33:57.240890"
        }
    ]

Not sure this is intended, because per your suggestion above you don’t intend on creating tracks fitting this pattern.

maas-test-dbhas no version patterns or guardrails.

I have created a guardrail for the maas snap to allow self service track creation of the \d+\.\d+ pattern. Please give it a try and let me know if that solves your issue.

edit: Just realized that you mentioned wanting to self service tracks for maas-test-db as well so added a similar guardrail there.

8

Hi, mlathara!

Based on the definition I see in the docs (documentation.ubuntu.com/snapcraft/8.14/reference/commands/tracks/) of version pattern, and the definition you mentioned of guardrails, I believe you are correct in your understanding:

We indeed want the

  • Guardrail of \d+\.\d+ (for all tracks) and then we can self-select the version patterns when creating the track, it seems.

I just tested, and I was now able to create the 3.8 track myself. So I think the changes you made are in alignment with what we want : ).

Thanks for the clarifications!