Shuttle compatibility about kitsune HOT 14 OPEN

Hmm.. that's a really interesting suggestion. I recently remodelled some of the internals to use dynamic dispatch instead of monomorphisation for state, etc, so that should make things like this easier (the goal was better testability, but if it gives us shuttle compatibility, the better)

We could definitely throw in a no-op cache to get rid of Redis in that department.

As for the coming up event messaging, we are also using an abstraction using Arc<dyn>s (heh.. yeah, I know. A lot of dynamic dispatch), so that could be replaced with Tokio broadcast channels to keep all the messaging inside the application.

The biggest problem would be the search service. It's basically built around being an external service.
But we could also throw in a no-op service there and tell users that search isn't supported on shuttle installs.

I have only skimmed the docs, but they also seem to provision a database. I will dig into the docs some more later, but it seems like it's very possible to get Kitsune to run on shuttle.

We will probably keep this experiment out of tree for now, though (since I'm not too sure how we could set something like the CLI up)

from kitsune.

The branch with the modifications needed to get it to run on Shuttle is here and the Shuttle project itself is here.
Both of these aren't the best looking code, but they work.

from kitsune.

Oh that's actually not a problem. The internal architecture is actually quite flexible when it comes to the services (this was actually thought for testability, but if it can be used to make it compatible with shuttle, that's just another great use!).
What I did for now, was to replace the actual search service with our test mock service that always delivers empty results.

Probably not the best longterm solution, but good enough to get a MVP going.

This required some code modifications but nothing too big. Most of the changes was just commenting out and adding a separate crate for UUIDv7 generation.

from kitsune.

Investigating why Mastodon won't accept Kitsune's objects. But for now, it looks like it works!
I was able to log in with Pinafore and post this status.

from kitsune.

Shuttle discord: https://discord.gg/H33rRDTm3p

from kitsune.

Small update on the Shuttle front:

Logging in via Elk works, posting works, home timelines somewhat work (they rely on streaming APIs unfortunately, so deletions don't get properly propagated until the tab gets refreshed).
The static assets are broken because I didn't mount them properly yet.

But that deploy is running from the main branch (admittedly a little outdated, but still main)

from kitsune.

(As a somewhat unrelated comment, if I get this to run on shuttle this will make testing against Mastodon so much easier. So thank you again for the suggestion)

from kitsune.

Hey there, I'm a DevRel contributor from shuttle and I've spoken with the engineering team.

Shuttle currently works by sending the user's code to shuttle's server, which then deploys the code to a container on shuttle's container network. The current findings are that due to requiring an nginx config file, running kitsune is basically impossible due to the fact that nginx config files are not currently shipped with builds and starting the nginx server in the container would be quite tricky. It's technically possible to do this with a build script, but users in the past who've attempted this have reported difficulties doing so and the team hasn't managed to find the source of those issues yet.

Hopefully this helps

from kitsune.

@joshua-mo-143 Thank your for your answer, the requirements in the Readme are a little outdated.
Nginx isn't really required, any reverse proxy will work. I actually hacked around a bit and feel like I'm close to getting something running.

The two biggest issues I'm facing are:

1. protoc is missing, so I had to completely remove the dependency on the crate that generates the protobuf definitions in Rust via tonic-build
2. cargo shuttle deploy doesn't seem to send the .cargo directory containing to the build environment (I'm testing out whether a build script will work right now)

I will report back whether if I get something up and running :D

from kitsune.

The Nginx mention was more of a "hey, you need a reverse proxy for TLS termination" than a hard requirement

from kitsune.

@aumetra Ah I see, thank you for the response! That's brilliant.

If we can get a minimal implementation working, then we could probably build off of that.

I should mention the other teething issue is that you can only implement one http-bound service at a time (presumably due to infrastructure). It's a minor issue, but this may inconvenience things if having both the back end and search service are required for kitsune to work since it appears (from the docker-compose file) that both require a separate port.

from kitsune.

This looks great, would you mind if I had a look at potentially extending the example?

from kitsune.

That’s awesome! 👏

Is Discord an option for you? I’m talking with the Shuttle folks on there about the other things this sort of development could unlock. Certain aspects of this work are easier to shape on chat, even if still asynchronous. Or email me (see profile) to discuss other options.

Personally, here is why I’m interested in what both Kitsune and Shuttle are doing: https://blog.erlend.sh/reclaiming-my-digital-identity

from kitsune.

@joshua-mo-143 Not at all, go ahead!
@erlend-sh Yes, Discord would be fine for me.

I would really like to provide something that you could call "experimental first-party support" for Shuttle. I think it's really awesome how easily things can be deployed there.

The only problems/questions I have at the moment are:

• No protoc in the build environment
  • This isn't too bad since I can probably get something like protoc-bin-vendored to work behind a feature flag. It just would be great if I didn't have to (looking at how the last crate version was released a year ago and I really would prefer not having to download protoc in the build file)
  • But thanks to the protoc-bin-vendored crate, this is a more minor issue. I'd call this something that would be "nice to have". I think this even falls under the issue the Shuttle team has in the "Considering" state tracked here.
• No support for cargo configs
  • This is a bigger one. Right now we are using cargo configs enable unstable features of the uuid crate for UUID v7 support. I would really like to be able to keep everything sourced from just the uuid crate.
  • I'm not sure how large the engineering effort would be to make shuttle to use the cargo config in the build environment
  • Maybe I'm doing something wrong on my side, if that's the case please correct me!
• Where do uploads go?
  • If someone, for example, uploads an attachment, where can we put it? Do we have to support S3-compatible storage solutions or can we put it in some special directory?
  • Is this what shuttle-static-folder is for?

So if the cargo config support would be implemented and if I'd implement a feature gate for tonic-build to use the binary from protoc-bin-vendored (and I know where to put the attachments), I would be 100% open to having something like kitsune-shuttle live alongside kitsune directly under the org.

from kitsune.