Provide official debian and RPM packages #16867
Comments
codefromthecrypt
added
enhancement
|
cc @phlax I did a recursive grep and basically this is the last thing people can't do properly upstream. |
|
im very +1 to this - and ultimately would like to create a "request to package" with debian - it really feels like envoy would be incredibly useful to end users to just be able to apt-get install (or rh equiv) in the interim i would be very happy to create the packaging for us to host these ourselves ...and the necessary deb repo |
phlax
added
area/build
area/community
area/install
and removed
triage
There seem to be some concerns about getenvoy's distributions, and most of them are moot at this point. As the getenvoy project stops building and publishing envoy, we should make sure users are aware where "official" things are. Right now, there are official and more maintained alternatives for everything except system packages. This removes the website links of getenvoy for everything except system packages. It also removes the section about nightlies as I don't think they are being maintained and certainly won't be moving forward. See: envoyproxy#16867 envoyproxy#16830 (comment) Signed-off-by: Adrian Cole <adrian@tetrate.io>
|
im wondering about using bazel for this - looks like a reasonable approach - although at least for debian its not clear if source packages are supoorted in terms of prior art - tetrate's packaging is here https://github.com/tetratelabs/getenvoy-package/blob/master/envoy_pkg/packages/getenvoy_package.bzl |
|
I think in the past there has been some resistance towards hosting/distributing binaries (c.f. #9006 (comment)), but we could always revisit that decision. @envoyproxy/maintainers for visibility |
i think that because getenvoy are no longer going to host binaries this role is shifting to CNCF |
|
Talked offline, seems like we've got resources allocated for this so no more complaints from me :) |
|
Can we please get an update on this? |
|
weird i thought i commented earlier - seems not we currently publish debs to our release page when i find some time i will add an apt repo to make those available via there are no current plans to publish rpms |
|
as commented previously, these are statically compiled binaries - the same binaries that are available in the docker container and for direct download from the release page, just with deb packaging |
|
Why cant we use these packages from the github releases? |
you can - but you cant install them with dpkg/apt |
|
@phlax maybe this issue can be closed with docs
reason is that this issue will continue to accumulate comments otherwise and I dont see any resolution besides what has been commented. what do you think? |
|
@phlax There are lot of dependency issues rising when we use the releases binary. wrt gnu library for various linux versions |
|
@codefromthecrypt would be happy to review a docs PR this bit is incorrect tho
there is a plan to publish a deb/apt repo, its just not that high priority right now |
|
@sivatarunp you need to use a sufficiently new enough distro that has a compatible glibc |
@phlax so I guess we should keep this open then, as I don't expect much value in creating another issue as "official" sort of means canonical. Thanks for the input! |
|
headsup that apt.envoyproxy.io is now live we dont have rpm support atm, but if that was of interest to anyone i would be happy to assist/review |
please add support to the latest Ubuntu LTS (noble) |
|
the main reason for not adding more distro/versions is that it takes quite a lot of CI time to test that said i have a vague plan to only test the earliest supported version of each distro as this would still test the deb publishing architecture and would catch incompatible glibc versions in the meantime @matihost you can almost certainly just use the latest ubuntu that we do currently support - atm, its the same statically compiled binaries in each |
|
hey @phlax! Which strategy did you have in mind for packages in the repo?
I ask because this makes a difference for people who pin and request to install specific versions via configuration management (e.g. Ansible). |
im not sure im following exactly we dont keep any binaries in the (Envoy) repo - the binaries are produced as part of the release process, the apt repo requests a list of supported versions from Envoy
as part of our normal push/pr CI we build and test the deb packages - atm we do it for all of the supported distros - this suggestion was more about just testing the earliest version of each distro rather than all (atm that would be |
|
When maintaining a package repository for a Debian-like, you can generally use two approaches:
Given these, I was wondering what you had in mind for the envoy repo. |
|
ah - i see - i did ponder this, but didnt come to any firm conclusion atm - there is no cycling of old versions - all are present - see these: relatedly im wondering whether to keep no longer supported branches around - ie whether to delete 1.28 when it goes EOL (in ~4 weeks) open to suggestions on this - even better PRs (repo is here for ref https://github.com/envoyproxy/apt) |
Yes, i can confirm that envoy package from jammy works on Ubuntu noble (24.04). |
|
Hi, maybe use single repo like vector did? Without building for each distro, only for package system. |
not sure tbh firstly i dont want to add a then also i think the debian/ubuntu versions are significant - the currently statically compiled bin doesnt work with pre-bookworm (iirc) - so we do want to make these distro versions explicit |
In this case you already have exactly what's recommended. I would, however, strongly advise against unpublishing packages. With a single exception - the content of the package being so broken that it doesn't start or destroys data - you should not unpublish software releases. In any other cases a SemVer patch-level release or similar should suffice. For example:
I strongly recommend to only ever unpublish if that specific release actively harms its users. If you are pressed for disk space, consider unpublishing things that are older than 3 years, but I hesitate to even suggest that.
|
in general i would agree - however - in this case my concern is that once these minor branches - eg 1.28 - go EOL they are no longer supported with patch updates this usually means there are known/published vulnerabilities with these versions so im not entirely clear whether we want to distribute vulnerable warez
well, that is arguably the case |
|
I see that you're trying to mix your security strategy into your availability here. I'm a bit conflicted about that, but if you insist there's also an already working example of solving that. Debian and Ubuntu do that for their outdated releases by moving them from the regular repository into a dedicated archival one (see example). Both use slightly different terminology, like this: - deb http://deb.debian.org/debian CODENAME main
+ deb http://archive.debian.org/debian CODENAME main
- deb http://archive.ubuntu.com/ubuntu/ CODENAME main
+ deb http://old-releases.ubuntu.com/ubuntu/ CODENAME mainThat repository (likely) has less bandwidth and is not enabled by default anywhere. Users that manually choose to use it know they are getting outdated things and unsupported things but they know the releases stay there for archival reasons. I you'd like to make things very explicit you could use |
|
yeah - i considered adding a it would need to live under apt.envoyproxy.io tho as adding dns and/or maintaining a separate site would be non-trivial im open to PRs to address this - the current setup wont delete anything as it stands |
Glad to hear it! If you don't want to use a subdomain for the archive repo, you could use the If users then want to activate it, they would change: ...
- deb[signed-by=/etc/apt/keyrings/envoy-keyring.gpg] https://apt.envoyproxy.io bookworm main
+ deb[signed-by=/etc/apt/keyrings/envoy-keyring.gpg] https://apt.envoyproxy.io bookworm main unsupported
...It would require some more configuration of your aptly repo. |
|
would it not be possible to just add a directory it might require some path mangling to work - not sure if it would at all trying to think of a setup that requires minimal maintenance/complexity i like the idea that users have to add |
This has the same effect as what I suggested but it's less clean.
If you tell me what you think will bring a maintenance burden, it's easier for me to suggest things. Specifically I think you could:
Is this super clean? No, because you'll also have supported packages in |
|
by low maintenance im meaning
tbh - the complexity issue is probs just as important, if not more not really seeing why using a subdir is "less clean" - mho is that its more explicit - but as said above - open to PRs on that note - we should probably be having conversations like this in the apt repo itself so future selves can see them |
and others
Title: Provide official debian and RPM packages
Description:
Right now, everything on the website mentioning "getenvoy" can be removed without breaking people.. except debian and RPM packages.
Can you please host official debian and RPM packages? Seems they can be built from the same binaries used to make docker images similar to #16830
Once this is done, hopefully there's no need for confusion anymore as getenvoy's build and packaging pipeline can quietly turn off.
Relevant Links:
#16830
The text was updated successfully, but these errors were encountered: