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

Client connect trigger instead of min threshold #10

Open
Vukodlak7 opened this issue Sep 8, 2022 · 2 comments
Open

Client connect trigger instead of min threshold #10

Vukodlak7 opened this issue Sep 8, 2022 · 2 comments
Labels
wontfix This will not be worked on

Comments

@Vukodlak7
Copy link

I got everything working great, but is there any way to make it spin up the docker container based on when a client connects or sends an http request to the port?

I am using it with motioneye, and motioneye doesn't ever really settle down to 0 packets and is impossible to gauge the threshold correctly. It does, however, seem to register the clients connected just fine. Also, you cannot send enough traffic to motioneye to get it to trigger back on because of the login screen it uses, I think.

TIA!

@Arson31
Copy link

Arson31 commented Dec 2, 2022

I agree some containers are always communicating with one another and it's almost impossible to get a good baseline of how many packets are too little or too much to start a container.

@vmorganp
Copy link
Owner

I've been hacking on this project a bunch over the last couple of days.

Something I've come across (and would love to be proven wrong on) is that in order to make a client connect trigger work, all traffic would need to be something where we could determine what a "client" is.

Because this was purpose built to be a lazy loading front for containers as a whole and not for something like web servers specifically, or game servers specifically, I don't know that it will be possible to determine "client connection".

Again, if you know a way to determine that for generic traffic, please let me know, but I just don't know if this issue is solvable without compromising the purpose of lazytainer or a TON of custom code.

That said, I'm actively developing port specific packet thresholds which should help with some of the "spammy traffic hit lazytainer and now your other container is awake" stuff that was happening.

@vmorganp vmorganp added the wontfix This will not be worked on label Mar 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants