envoy
envoy copied to clipboard
envoyproxy
Provide official debian and RPM packages
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: https://github.com/envoyproxy/envoy/issues/16830
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
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. https://github.com/envoyproxy/envoy/issues/9006#issuecomment-553546959), but we could always revisit that decision.
@envoyproxy/maintainers for visibility
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.
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 :)
A quick update on this
I have a ~working prototype that builds debs/rpms for arm and x86 architectures, and tests them installed in a distro containers (#16899 )
It still needs to be figured out how this can best/most efficiently fit into the CI but it seems to mostly work so far
One issue i have is that building with rbe - there isnt an rpmbuild binary for rpms - but its possible that we could work around that with https://github.com/google/rpmpack
Hi, are there any updates on this ticket? We have also been affected by https://github.com/envoyproxy/envoy/issues/17236 except we are using RPMs.
Until this issue is resolved, does anyone have a workaround as all our builds are currently broken? I found https://cloudsmith.io/~tetrate/repos/getenvoy-rpm-stable/packages/ - would you recommend that repo be used as a workaround?
cc @lizan
not sure about the cloudsmith.io repo or the cause of https://github.com/envoyproxy/envoy/issues/17236
im working on resolving this issue but it will take some time
I'll summarize: the reason for opening the issue here is "getenvoy" is going away (eg no longer maintained and we aren't supposed to use the name). bintray is down also as the service went away.
The thing I raised last month #16868 was an interim step reduce confusion for reasons like this. Probably we should remove all references at this point. I had hoped the packages here would have landed by now and obviate the whole thing.
Folks in a pinch can use the same tarballs our tools use https://archive.tetratelabs.io/envoy/envoy-versions.json until this issue or #16830 closes.
Is there something on the packaging here that others could help complete? What's working so far? What's left to do?
FWIW, it's possible to build rpms via fedora copr (https://copr.fedorainfracloud.org/coprs). Online builds are possible, bazel's already there (https://copr.fedorainfracloud.org/coprs/vbatts/bazel/packages/).
looks like there is a draft PR out there on this topic, I had no idea.. maybe we are closer! https://github.com/envoyproxy/envoy/pull/16899
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
should be noted that centos 7 based distributions are still widely in use, so packages should accommodate this, or some sort of clear support matrix be included to say it isn't.
See https://github.com/envoyproxy/envoy-build-tools/pull/154 , @adaoud-ims .
Has there been any recent updates on this? I'd love to have this as well.
Crud. Consul 1.12 just got released and dropped support for envoy 1.18. That leaves CentOS 7 without a viable envoy package on up-to-date Consul.
yikes... we have a bunch of centos 7 customers who could benefit from native installers... many run in sensitive data centers and don't want to install docker... would love to see this move forward. Is there anything potential contributers can do to help this along?
cc @phlax can you potentially update this issue with current status? I know this is being worked on.
some progress on this - we have just landed code to auto push assets on release - only envoy binaries initially - but it will establish the pipeline
the debs are pretty much ready to publish and we can follow up fairly quickly to add - the main reason i didnt include is that they are slightly larger than expected so wanted to check out the reason before adding
there is an #envoy-release channel on slack now which i would encourage anyone interested in this to join
can you describe what you mean by "auto push assets on release"? do you mean attach to GitHub release or somewhere else?
cool. can you try to get Mac x64 and aarch64 builds up there as well as windows x64? there's been a lot of problems sourcing binaries particularly on Darwin, and we can change the sourcing accordingly.
could you jump on the slack channel ?
it has discussion about these and why they have not been included initially
probably best to cite the permalink to here as it is the better record. I have had some difficulty getting into the envoy slack due to it restricting which domains can join. I doubt I'm the only one.
maybe you can restate if there is any plan to expand beyond that or why there won't be? regardless, this is improvement even if partially implemented, so welcome progress.