If git.coopcloud.tech is down, try to keep going with local files #292
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#292
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe the current behavior
abra
bails 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 app
anything...Describe the expected behavior
abra
will 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
--offline
flag 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 #303. A related ticket was #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 logs
to fail ifgit.coopcloud.tech
is not reachable. Where doescli/app/logs.go
fetch any ressources?that's a great question, thanks for investigating @moritz. @decentral1se you got any ideas how we could have seen the output in #292 (comment)?
I could find it. The
app logs
commands callsValidateApp
This function does much more than it should do (
ValidateApp ensures the app name arg is valid.
). It callsEnsureExists
which 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
ValidateApp
is 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
abra
were 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 logs
can 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!