deploying app does not include sym linked files in flexible environment

[rachel...@gmail.com]

I have a python app that imports a small module that on my local machine is symlinked from another project. I can deploy it just fine to the standard App Engine environment. However, when I try to deploy to the flexible environment, I get normal behavior until:

Updating service [default]...failed.

ERROR: (gcloud.preview.app.deploy) Error Response: [13] Timed out when starting VMs.  It's possible that the application code is unhealthy. 

In the logs I can see an ImportError for the symlinked module. If I remove that import, the deployment is successful.

For both the standard and flexible environments I am using 'gcloud preview app deploy' to deploy.

Question 1: Is there a reason why symlinked files are not included with the flexible environment's upload, assuming that's what is causing this? 

Note that this module and its parent project are under development, and having a fixed version of the project to install via requirements.txt is less convenient. I realize another option is to git clone the entire project into this app's directory, but again that's a bit more overhead than simply linking to the one file I need, which automatically keeps it in sync with my development version that I am using the app to test.

Question 2: If symlinks will not work here, what's the preferred method to accomplish this? Again, in this case actually installing the package is less desirable than having a copy of the source accessible for imports.

[Justin Beckwith]

I've added a few engineers from the SDK and App Engine teams who should be able to help here.  

--
You received this message because you are subscribed to the Google Groups "google-cloud-sdk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-s...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-cloud-sdk.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sdk/825ad9e8-8239-46b2-85ee-42691cb278cc%40googlegroups.com.

--

Justin Beckwith | Google Cloud Platform | @justinbeckwith | http://jbeckwith.com

[Zachary Newman]

Hi Rachel,

Did some digging, and it looks like we’re just being consistent with the behavior of docker-py in this case, since App Engine Flexible Environment is Docker-based: https://github.com/docker/docker-py/blob/538a1db9dd210ee4824f0203341586b9aa3f2419/docker/utils/utils.py#L94

It’s an easy fix: just add dereference=True to line 97 in the linked file (we ship our own copy in $CLOUD_SDK_ROOT/lib/third_party/docker/docker/utils/utils.py); the issue is that there’s a decent number of steps that have to happen before that change would be reflected in a released version of the Cloud SDK (pull request to Docker, pull request being merged, Cloud SDK updating the docker-py version we ship). I put in such a feature request to docker-py, but I have no idea whether this is a change they’d be okay with. Note that in a previous discussion about the Docker CLI, Docker maintainers declined to do this.

In the meantime, you could void your warranty (so to speak) and make that change in the copy of docker-py in your Cloud SDK installation.

If you’d like, file an issue at [https://code.google.com/p/google-cloud-sdk/issues/entry](https://code.google.com/p/google-cloud-sdk/issues/entry) and we can keep you updated there. If there’s a good enough reason, we can hack around it on our end, without waiting on docker-py, but we do really value having consistent behavior with the Docker tooling.

Cheers,
Zack

​

To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sdk/CADd%3D1Q0tvst4jaQKX_qyuBjQKnetWDEEXNPzW2Edx9pihk2ezw%40mail.gmail.com.

[Rachel Finck]

Hi Zack,

Thanks for the detailed reply. The fix you mention is easy enough for now, which will allow me to keep my project's directory structure as is. I see that the Docker folks are hesitant to add this, but my opinion would be to add an option for it, even if maintaining the current default behavior. I'll keep an eye on your feature request to see what happens.

Cheers,

Rachel