8000 Fix race condition when running `./bin/cli.sh` by csegarragonz · Pull Request #728 · faasm/faasm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fix race condition when running ./bin/cli.sh #728

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

Merged
merged 2 commits into from
Mar 8, 2023
Merged

Conversation

csegarragonz
Copy link
Collaborator
@csegarragonz csegarragonz commented Mar 4, 2023

This one was hard to catch, and probably the cause of many venv-related problems.

In essence, ./bin/cli.sh first makes sure that the cluster is up and running (docker compose up -d --no-recreate), and then execs into one of the CLI containers.

In a fresh environment, the call to docker compose up -d --no-recreate will start the containers and initialise the python virtual environment (i.e. will call ./bin/create_venv.sh). The latter takes a while to finish, and if we exec into the CLI before it finishes (which calls source ./bin/workon.sh), we break the installation.

This can be reproduced by (literally):

git clone https://github.com/faasm/faasm
cd faasm
git submodule update --init -f
./bin/refresh_local.sh
./bin/cli.sh faasm
bash: /usr/local/code/faasm/bin/../venv/bin/activate: No such file or directory
# inv -l does not work

The quick start tests circunvent this issue miraculously:

  • When we run docker compose up, we do it on the nginx service (that does not start the cpp and python services).
  • Then, when we start either the cpp or the python services, we docker compose run not docker compose exec (as the services had not been started before).
  • This means that when we call ./bin/inv_wrapper.sh the ./venv directory is initialised from scratch correctly.

This issue was brought up thanks to #726.

@csegarragonz csegarragonz self-assigned this Mar 4, 2023
< 8000 div data-view-component="true" class="TimelineItem-badge">
@csegarragonz csegarragonz requested a review from Shillaker March 4, 2023 18:57
@@ -111,7 +111,7 @@ FetchContent_Declare(wavm_ext

FetchContent_Declare(wamr_ext
GIT_REPOSITORY "https://github.com/faasm/wasm-micro-runtime"
GIT_TAG "135672cab24d877db4ef6933c0ab150351384d51"
GIT_TAG "a31e5a4fa299c4f8384f40e157b0a928ad0bda1b"
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, in a PR where I am working on SGX (#686) I rebased the faasm branch to the latest WAMR commit, effectively removing the previous tag. It does not exist anymore.

As a future note to self, any other time I rebase the WAMR dependency I will do it in a temporary branch whilst the PR is under development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0