`glaredb upgrade`

[greyscaled]

Description

Title says it all --> I want to use a simple upgrade command instead of the curl install/upgrade.

[greyscaled]

Alternatively, I wonder if we can:

• install with cargo
• what would it take to distribute on well-known linux repositories to unlock flows like apt etc ?

[tychoish]

I guess I'm interested in why? Lots of things get installed by shell scripts in our manner, and it's a decent model for tools like ours in most cases. Do you dislike the ergonomics or the security implications? Is it unreliable? Do people struggle with it? Are you specifically concerned with upgrades?

Thoughts on Alternatives.

I think installing with cargo (should) be possible today with minimal work: we can get this into one line. This only works for people who are using rust (which probably means that we'll miss some users, and people might not have rust around.) and who are comfortable using a version of rust that's compatible with our code-base (I suspect we'll often be sort of middle-of-the-pack with regards to toolchain upgrades, but who knows?). Anyway, I think documenting the cargo method is worthwhile.

It is possible, I think, to install the binary into the path with pip (right? I haven't double checked this.) This might be a bit more common for people who are glaredb users, and python toolchains are default on most systems in a way that rust toolchains are not.)

Making packages installable via apt/yum/dnf/zypper is deeply annoying, though I haven't re-explored it recently: there might be some services that make it easier: I think we can/should make it possible to install glaredb via homebrew (and maybe put a PKGBUILD in the AUR), and call "native" packaging done, unless there's a really compelling specific user.

While the UX of having glaredb upgrade is really delightful, the implementation is complicated: you have to have write-permission to the current binary, which is complicated, potentially would require some amount of time in the weeds of process management, and there are so many edge cases.

Packaging Options:

Here are a bunch of small and medium things that we could do to help people upgrade, some of these are just theories/conjectures.

• [ ] Make glaredb binary installable via pip
• [ ] Document using cargo to install and upgrade glaredb
• [ ] Make glaredb print an warning message that it's out of date if it connects to a cloud instance that is newer than its version.
• [ ] Have glaredb check an endpoint on cloud (could be a file in S3 that we upload during releases) on startup (sometimes?) to see if it's out of date and report this to users.
• [ ] We could accompany the "your glaredb is out of date" message with instructions tailored to the runtime of the current system. (This could be very simple or could just capture a lot of logic
• [ ] create AUR packages for glaredb (simple, limited ongoing maintenance,) maybe eventually they'd get moved to the real repo.
• [ ] is there a reason/way that we could publish a docker build (with devtools and a decent python?) and a wrapper script so people's updates could just be "docker pull"

[greyscaled]

I guess I'm interested in why?

Nothing tells me my version is out of date or how to update it. If I want to update it, I find myself having to go re-copy the command from the readme.

That story is all I care about. My fault here is making the issue title seem like I want that specific implementation.

The issue title could just be "reduce friction to upgrade" or something. Orthogonal to reducing friction is how I'm reminded that I'm out of date.

[tychoish]

Ah! I think I understand this better now. I think that we should probably think about doing some of this packaging work at some point, but I don't think we should do packaging work to solve this problem (as all solutions will be a bit incomplete.)

I think:

• [ ] cloud should know the current version of glaredb it's running, and provide a public (no authentication) API that reports/exposes this.
• [ ] glaredb and cloud should understand glaredb's version using the same identifiers and that these identifiers be easily sorted. (e.g. we should be able tell which is newer/older if they're different.)
• [ ] we should expect that eventually there will be some (constrained) flexibility, eventually, and so glaredb+cloud might have some min/max version setting for protocols (protobufs helps to some extent, but aren't a full solution), so we shouldn't have the api return just one number, but we don't need to implement this right now.

Cloud should know what the current version of glaredb it is connected to

[greyscaled]

Cloud should know what the current version of glaredb it is connected to

select version();

Is implemented and works

[greyscaled]

cloud should know the current version of glaredb it's running

Are you thinking per-deployment here or globally? Currently, compute engines don't get version updates on rollout, and instead require a manual restart. Therefore there isn't a single version running.

The default compute engine is always the latest version whereas each compute engine is theoretically on its own version. This is just due to the early state of implementation but it's a problem we need to tackle in the near term.

[greyscaled]

closing - we have improvements on version displays etc!