If git.coopcloud.tech is down, try to keep going with local files #292
Closed
opened 2022-01-27 11:26:59 +00:00 by decentral1se
·
12 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
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#292
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.
Describe the current behavior
abrabails out if the internet is not there even though we have local files.Steps to reproduce
Take down git.coopcloud.tech like a total cowgirl and run
abra appanything...Describe the expected behavior
abrawill complain if it doesn't have local copies and bail out. Otherwise, it'll use the local copies and warn about doing so.Any idea how this might be fixed?
See above. Thought about a
--offlineflag but I'd rather not introduce new stuff right now before beta.Additional information
N/A
Ran into this again, also the linting fails with a missing repository which is not quite true! It just doesn't exist online. We probably shouldn't explode on that linting error in this case?
same experience here :D luckily only a short downtime ...
would love a --offline flag!
further thoughts: Maybe it would be cool to configure the catalogue url to make abra more robust in case git.coopcloud.tech is down for a longer period, people could git push the catalogue to git.newcoop.tech and continue from there on
Yeh, I think it might be time to look into this again shortly...
I think this ties into some other thinking nicely: potentially have a configuration option for the catalogue repository in coop-cloud/organising#303. A related ticket was coop-cloud/organising#139 but that might be too far for now.
Need for some sort of offline resilience i n t e n s i f i e s
I couldn't reproduce
abra app logsto fail ifgit.coopcloud.techis not reachable. Where doescli/app/logs.gofetch any ressources?that's a great question, thanks for investigating @moritz. @decentral1se you got any ideas how we could have seen the output in coop-cloud/organising#292 (comment)?
I could find it. The
app logscommands callsValidateAppThis function does much more than it should do (
ValidateApp ensures the app name arg is valid.). It callsEnsureExistswhich clones the recipe if it doesn't exist. This violates the principle of single responsibility and makes things complicated because the recipe is not necessary for acessing the logs.I am not sure how to quickly fix this as
ValidateAppis used at 22 locations and it does many multiple things that are sometimes necessary, sometimes not.The best way would be to do a large refactoring.
Nice investigation @moritz, thank you!
My principles while programming
abrawere Principle of Does It Work ™️ 🙃 Maybe we could do a co-work / online call one day to see how to strategise a refactor ofValidateApp?I think that would be good to do. I'm scared to do it because we have few tests but then again, we have a lot of people who can help us doing some release candidate testing and that has worked for us in the past.
Taking a look at coop-cloud/abra#235 now 💯
I believe this got fixed? We made the release, stuff has been down and no complaints. Going to close, please re-open if there is more to do.
In most scenarios abra should work if git.coopcloud.tech is down.
But I think there are still a few rare conditions, which could make problems.
For example running
abra app logscan only execute if the recipe repo is cloned. I think this should not be necessary for simply looking up the logs.But I consider this is not a very high priority case.
Oh yeh, let's keep this one going then! Any other situations come to mind?
Looking at the various call sites of
ValidateApp, yeh, I think we could include a new boolean which determines if we should error out if the recipe can't be cloned? Or better, if we should even clone the recipe to run the command? There could be some case-by-case time saving to be made here? Can take a run at this unless you feel like it @moritz?OK, coop-cloud/abra#275 should cover this streaming logs case and trys to set up the code to make this easier going forward. Gonna close this when merged. Let's open more specific tickets for further offline support. Thanks!