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

Policy for updating libmsquic #1171

Closed
richlander opened this issue Aug 12, 2024 · 10 comments · Fixed by #1193
Closed

Policy for updating libmsquic #1171

richlander opened this issue Aug 12, 2024 · 10 comments · Fixed by #1193

Comments

@richlander
Copy link
Member

When should we update our source-build usage? Notice we are already behind. Ideally we keep up, right?

@wfurt @ami-GS @jkoritzinsky

Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

1 similar comment
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@liveans
Copy link
Member

liveans commented Aug 13, 2024

I agree that this is a pain-point for us, we can forget this easily, but I'm not sure if there is any better solution to this for now.

Notice we are already behind. Ideally we keep up, right?

Yes, we should keep up.

@richlander
Copy link
Member Author

I wanted to zoom out on the Alpine Dockerfiles. Why are we building libmsquic? If it's not available in PMC, then where do users get it? I want to validate that we're testing something that users can actually use. Is there an msquic doc for Alpine users?

@liveans
Copy link
Member

liveans commented Aug 16, 2024

I wanted to zoom out on the Alpine Dockerfiles. Why are we building libmsquic? If it's not available in PMC, then where do users get it? I want to validate that we're testing something that users can actually use. Is there an msquic doc for Alpine users?

I don't have the full context for this, but AFAIK there were some discussions about working on packaging for Alpine, not sure tho.

/cc @ManickaP @wfurt

@wfurt
Copy link
Member

wfurt commented Aug 16, 2024

We are not producing Alpine packages for runtime either AFAIK. As far as the updates, in practice, our user base will be on various versions as well e.g. not anyways on latest. In general we update our test images when there is important fix or new feature we try to consume.

@richlander
Copy link
Member Author

Where are the binary drops for msquic? That isn't obvious to me.

@ManickaP
Copy link
Member

I'll try to answer all the questions here:

  • Ideally we keep up, right?

see: #1156 (comment) @liveans could you make this into an issue? It shouldn't be that hard to query the latest msquic released version from GH and build that instead of fixed version. Disadvantages: the image still needs to rebuild manually to get the newest package; and it'd automatically consume the latest release which might be broken (e.g. what happened lately with 2.4 release). But we can discuss this in that particular issue, not here.

  • If it's not available in PMC, then where do users get it?

AFAICT https://packages.microsoft.com/ does not have a way to publish packages for Alpine. The users are expected to build msquic themselves, same way we do. Note that we're aware of this and have dotnet/runtime#83789, but this has had rather low priority so we don't have a fixed date when it'll be solved, if ever.

  • Why are we building libmsquic?

Because there's no official musl binary of libmsquic we could use.

  • Is there an msquic doc for Alpine users?

No, no specific alpine docs. What would you expect there? How to build it, we have https://github.com/microsoft/msquic/blob/main/docs/BUILD.md, that's distro agnostic.

  • we're testing something that users can actually use

The Alpine set up we have here corresponds exactly to what we expect users to do if they want QUIC to light up. So I think we're testing the right thing here.

@richlander
Copy link
Member Author

Thanks. That's helpful.

It shouldn't be that hard to query the latest msquic released version from GH and build that instead of fixed version.

That's a bad practice for containers. You should be able to go back and re-build an old version that either passed or succeeded and replicate that behavior. Naturally, packages don't do that but then you've opted into packages. For everything else, pinning provides the best experience.

Because there's no official musl binary of libmsquic we could use.

My main point is that this significantly increases the burden for users. Building the code is certainly a pain. It would be nice if the upstream project provided binaries. However, it would be good to hear more requests on that form users.

@wfurt
Copy link
Member

wfurt commented Aug 19, 2024

certainly with user feedback it would be easier to put more pressure on msquic. Some distributions do that independently - like Arch Linux https://aur.archlinux.org/packages/msquic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants