Request `dns` track for `httprequest-lego-provider`

charmhub requests
1

Hello, we would like to create the track dns for the httprequest-lego-provider charm. The goal is to provide an alternative implementation compatible with the upcoming DNS charms.

2

After trying to add it myself, I understand that I need to request guardrails first. Can someone please add \.* as a guardrail ?

3

Hello,

Thank you for thinking to make this into a guardrail request instead, however, \.* is far too permissive a guardrail for policy, generally we allow semantic versioning aligned guardrails such as \d+\.\d+, \d±lts, or simply \d+

As for looking at this as a one off track request, Per Process for aliases, auto-connections and tracks, we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days. I have a few questions before casting my vote.

  • What’s the package’s release cadence, how often is a new major version (potentially requiring a new track) released? Is this documented somewhere by upstream?

  • Is there some commitment from upstream on maintenance of old versions? e.g. is the “0.1” release still supported with security updates? Will it continue to be supported now that e.g. “0.2” is out, and for how long?

  • Are new versions backwards-incompatible?

  • Since DNS is a feature branch in upstream is it intended to be a long lived branch or will it eventually be merged back into main. since users clients tracking “dns” cant just switch to latest and would require continual releases to both tracks

Thanks, Barrett

4

Hello Barrett,

Thank you for responding.

httprequest-lego-provider is a charm that uses a workload written by us in the same repository: there’s no difference in versioning between the workload and the charm. The charm started to be used in production about one year ago I would say and the whole workflow around it is still evolving. We therefore need to keep the current tracks to sustain the production services while we want to experiment with the new workflow (with the new dns charms) separately. This new track will not be backwards-compatible with the current stable/edge tracks. For now, it more resembles a long lived branch that may replace the other in the future.

Ideally, I was imagining this track as the counterpart dns branch that we maintain in the repository.

What do you think would be the best guardrails knowing that?

On behalf of the platform-engineering team,
Niels

5

given that there is not a consistent or predictable sequence of future tracks like a 1.x to a 2.x, for what tracks would come after “dns” I would not recommend a guardrail in this case. (unless you plan to tie a semantic version to it like 1.x-dns, 2.x-dns etc.

If we intend for “dns” to be a long lived branch, and does not fit the existing tracks, then I would vote to just create a “dns” track as is, and file explicit track requests later for new tracks.

Thanks,

Barrett

6

Just creating a dns track as is and filing explicit requests for the future ones is exactly what we need. So let’s wait for the voting/discussion period to end then

7

Thank you for waiting, we have discussed on our side, and I see no dissenting votes here either; so I have gone ahead and created the “dns” track as requested.

Please let us know if you need anything else for require more help, Barrett

1 Like