Add a way to set a timeout for abra deploy
#437
Closed
opened 2023-03-22 14:10:36 +00:00 by moritz
·
3 comments
Labels
Clear labels
abra
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
design
documentation
duplicate
enhancement
fedi
fedi-infra
finance
funding
good first issue
help wanted
installer
legal
performance
proposal
question
security
test
wontfix
Everything to do with abra
Ping/pong on comms
Something is not working
Go build related issues
Getting the robots into the mix
Opening this thing up
Contributors stuff
Our main website
Design thinking required
Let's write things together
This issue or pull request already exists
New feature
Democratic decision making
Money things
Anything related to grant funding
Easy start with development
Need some help
Installation related issues
Performance related
Large change which requires feedback & decisin making
More information is needed
Securing our shit
Unit or integration test suite
This won't be fixed
No labels
enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
3wordchant
aadil (Aadil Ayub)
abra-bot (Abra Bot)
ammaratef45
amras (Sarma)
Apfelwurm
BornDeleuze
Brooke
carla
cas (Cassowary)
coopcloud
cyrnel
decentral1se (d1)
dede
devydave
fauno (fauno)
iexos
jade (Jade Ambrose)
jjsfunhouse
jmakdah2 (Jackie Makdah)
joe-irving (Joe Irving)
kawaiipunk (KawaiiPunk)
knoflook
kolaente
lambdabundesverband
linnealovespie (April)
moosemower
moritz
notplants
oxaliq (sorrel)
p4u1
pharaohgraphy (Andrew 🐦🔥❤️🔥✴️)
renovate-bot (Comrade Renovate Bot)
ripclap
simon
sixsmith (Sixsmith)
stevensting
trav (Trav Fryer)
val (val (he/him))
yksflip
Clear assignees
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: toolshed/organising#437
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Per default
abra deploywaits until every container returns a healthy state.But after a fixed timeout of 50s it will abort.
Many applications need much more time to come up, therefore it would be good to specify a timeout for each app.
I think the compose file could be a good place to specify the timeout, so it will be bound to the application and it won't clutter the .env even more.
Excellent idea @moritz!
I've tried to experiment with those timeout values quite a bit and they vary heavily according to app but also according to the machine you're deploying to. It's hard to get a correct balance but I agree that the naive 50 seconds could really be improved.
Keycloak, for example, often needs much more time no matter the machine.
Are you thinking about a global traefik flag on the recipes or another type of label like https://docs.docker.com/compose/compose-file/compose-file-v3/#labels-1? I don't think there is an existing
timeoutkey we can use in the Compose spec? I only see one inhealthcheck.I thought about a label like
coop-cloud.${STACK_NAME}.timeout=120this could easily be read by abra to set a custom timeout.@moritz oh nice, should we maybe do
coop-cloud.${STACK_NAME}.timeout=${TIMEOUT}and haveTIMEOUT=...option in the.envfile? If this isn't detected, then we default to 50 seconds? Then it's configurable which I think could be important for a long-term solution because the timeout depends on the capacity of the hardware to get the app up and that will always be different. So, e.g. a raspberry pi deploying a keycloak (could be like 2 mins) vs. a powerful desktop machine (could be 1 min).