dan-online / autopulse

💫 automated scanning tool that bridges media organizers such as Sonarr and Radarr with media servers such as Plex and Jellyfin
https://autopulse.dancodes.online
Other
108 stars 3 forks source link

feat: Arm64 images #52

Open aleksasiriski opened 2 days ago

aleksasiriski commented 2 days ago

Description

Hello there, I'm the author of Autoscan continuation after the original author stopped working on it. I also stopped improving it after adding Postgres and would definitely prefer not to have to maintain it if this ends up working good :) I see you also support Postgres (which is great).

As for this issue, I see on Dockerhub that there are no arm64 build of the image. It would be great if you added these (as this is written in Rust, there shouldn't be any problems building cross platform binaries). If you decide to add arm64 images, I will be able to test this on my k8s cluster and see how it works.

Additional question: Have you thought about having multiple replicas of this project running at the same time, is there any kind of queue for the tasks? This would bring load balancing and high-availability to those of us that try to have it with Jellyfin

Additional Information

No response

dan-online commented 2 days ago

Hey @aleksasiriski, great to hear from you! Yep diesel is great to allow multiple database backends in Rust, makes development a lot easier. As for arm64, I do have to check out how to do that correctly as I had some issues with building binaries before.

As for multiple replicas- the only state that remains in-memory is the timers which I'll be refactoring to the database in #47. The only other issue I see is with the job loops which, in a rare case, could try to process simultaneously. Possibly a solution would be to add a "processing" state to prevent other replicas from touching those ScanEvents, however I'm open to any suggestions!

aleksasiriski commented 2 days ago

Great to hear!

Yeah, probably some lock mechanism as you described with "processing" state, just have to think about how to release it if it doesn't get processed (pod crashed or something). So maybe something with TTL that gets it's TTL reset every few seconds by the worker that is processing it. Not sure if you should introduce more complexity with some queueing system component or DIY it using the database. Either way, if you leave it as is currently it's also very good :D