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

Deployment issues on M1 Mac #429

Closed
TTitcombe opened this issue Feb 2, 2023 · 9 comments
Closed

Deployment issues on M1 Mac #429

TTitcombe opened this issue Feb 2, 2023 · 9 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@TTitcombe
Copy link

The issue

I cannot deploy with VespaDocker multiple times without removing and re-pulling the image.

After pulling vespaengine/vespa (using latest), I can successfully deploy an instance using pyvespa on an M1 mac. If I stop and remove the container and then try to re-deploy, it timeouts on "waiting for application status". However, if I remove the image and then repull, the next deployment succeeds.

System Info

  • Image: vespaengine/vespa:latest (I think 8.116-8.118 based on dates)
  • Pyvespa: 0.22.0
  • OS: macOS 12.3.1
  • Chip: M1 pro
@kkraune
Copy link
Member

kkraune commented Feb 2, 2023

removing the image sounds excessive - maybe the last container is not cleaned up - what does docker ps -a -q -f status=exited show?

@TTitcombe
Copy link
Author

TTitcombe commented Feb 2, 2023

Only containers unrelated to vespa when I run that command and lsof shows that 8080 isn't in use.

I agree that removing the image is a ridiculous workaround seeing as images != containers, but yet it seems to work 🤷

@kkraune kkraune self-assigned this Feb 6, 2023
@kkraune
Copy link
Member

kkraune commented Feb 6, 2023

I am working on reproducing the problem now

@kkraune
Copy link
Member

kkraune commented Feb 6, 2023

Hi again, we have found that the signal handling in the start script does not seem to properly trap the TERM signal, so stopping the container isn't correct. We are working to find out more, and a fix, will update

@kkraune kkraune added the bug Something isn't working label Feb 6, 2023
@kkraune kkraune added this to the soon milestone Feb 6, 2023
@kkraune
Copy link
Member

kkraune commented Feb 6, 2023

vespa-engine/docker-image#44 will fix the Docker stop issue and be released later this week - so can test pyvespa again then - I will update

@kkraune
Copy link
Member

kkraune commented Feb 10, 2023

https://hub.docker.com/r/vespaengine/vespa/tags - 8.122.27 (latest as of today) has a fix for stopping the Docker container without the wait (link in above comment). Maybe that will help fix your issue, I don't have your problem, but I'm on intel...

Can I ask you to test again with the latest image? if still an issue, I will find someone with an M1 and try to reproduce

@arnej27959
Copy link
Member

copy-pasting the "getting started" sample python scripts and running it twice with stop/rm between works fine for me.
this is on M1 mac, pyvespa-0.31.0 and vespa-8.122.27 versions.

% python3 dd.py 
Waiting for configuration server, 0/300 seconds...
Waiting for configuration server, 5/300 seconds...
Waiting for application status, 0/300 seconds...
Waiting for application status, 5/300 seconds...
Waiting for application status, 10/300 seconds...
Waiting for application status, 15/300 seconds...
Waiting for application status, 20/300 seconds...
Waiting for application status, 25/300 seconds...
Finished deployment.
% docker stop qa
qa
% docker rm qa  
qa
% python3 dd.py 
Waiting for configuration server, 0/300 seconds...
Waiting for configuration server, 5/300 seconds...
Waiting for application status, 0/300 seconds...
Waiting for application status, 5/300 seconds...
Waiting for application status, 10/300 seconds...
Waiting for application status, 15/300 seconds...
Waiting for application status, 20/300 seconds...
Finished deployment.

@kkraune
Copy link
Member

kkraune commented Feb 20, 2023

Thanks Arne!

@kkraune kkraune closed this as completed Feb 20, 2023
@TTitcombe
Copy link
Author

I can also confirm this works. Thank you @kkraune + team (and sorry for not testing the fix sooner)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants