Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide official debian and RPM packages #16867

Open
codefromthecrypt opened this issue Jun 8, 2021 · 14 comments
Open

Provide official debian and RPM packages #16867

codefromthecrypt opened this issue Jun 8, 2021 · 14 comments

Comments

@codefromthecrypt
Copy link
Contributor

@codefromthecrypt codefromthecrypt commented Jun 8, 2021

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

@codefromthecrypt
Copy link
Contributor Author

@codefromthecrypt codefromthecrypt commented Jun 8, 2021

cc @phlax I did a recursive grep and basically this is the last thing people can't do properly upstream.

@phlax
Copy link
Member

@phlax phlax commented Jun 8, 2021

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 phlax self-assigned this Jun 8, 2021
codefromthecrypt added a commit to codefromthecrypt/envoy that referenced this issue Jun 8, 2021
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>
@phlax
Copy link
Member

@phlax phlax commented Jun 8, 2021

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

@snowp
Copy link
Contributor

@snowp snowp commented Jun 9, 2021

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

@phlax
Copy link
Member

@phlax phlax commented Jun 9, 2021

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

@snowp
Copy link
Contributor

@snowp snowp commented Jun 9, 2021

Talked offline, seems like we've got resources allocated for this so no more complaints from me :)

@phlax
Copy link
Member

@phlax phlax commented Jun 15, 2021

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

phlax pushed a commit that referenced this issue Jun 22, 2021
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:

#16867
#16830 (comment)

Signed-off-by: Adrian Cole <adrian@tetrate.io>
@ahmed-adam
Copy link

@ahmed-adam ahmed-adam commented Jul 5, 2021

Hi, are there any updates on this ticket? We have also been affected by #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?

@phlax
Copy link
Member

@phlax phlax commented Jul 5, 2021

cc @lizan

not sure about the cloudsmith.io repo or the cause of #17236

im working on resolving this issue but it will take some time

@phlax
Copy link
Member

@phlax phlax commented Jul 5, 2021

@codefromthecrypt any ideas on this ?

@codefromthecrypt
Copy link
Contributor Author

@codefromthecrypt codefromthecrypt commented Jul 5, 2021

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?

@dmitri-d
Copy link
Contributor

@dmitri-d dmitri-d commented Jul 6, 2021

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/).

@codefromthecrypt
Copy link
Contributor Author

@codefromthecrypt codefromthecrypt commented Jul 6, 2021

looks like there is a draft PR out there on this topic, I had no idea.. maybe we are closer! #16899

codefromthecrypt added a commit to codefromthecrypt/envoy that referenced this issue Jul 7, 2021
Bintray no longer works at all and envoyproxy#16867 isn't finished. This fixes the
instructions until packages are available, after which the "Get Envoy"
parts should be deleted.

Thanks very much to @carlossg for finding these instructions and @arkodg
for verifying them.

Signed-off-by: Adrian Cole <adrian@tetrate.io>
chrisxrepo added a commit to chrisxrepo/envoy that referenced this issue Jul 8, 2021
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>
Signed-off-by: chris.xin <xinchuantao@qq.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants