[google-appengine] Re: Problem with Node.js Managed VMs deployment
Have you run your image in a local docker container and logged into it to see whether it works correctly? If so, what did you find? If not, I highly recommend this approach. Also, have you tried running the app locally using the `gcloud` command? https://cloud.google.com/appengine/docs/managed-vms/sdk#run-local I am sure you have, but just to double check - you have run `gcloud components update` recently as well right? Cheers, --Spain On Saturday, October 10, 2015 at 10:30:52 AM UTC-4, Alois Bělaška wrote: > > Hi, > > I've run into a problem with deployment of node.js managed VM to GAE. > Docker container is build successfully, new version established but then > the deloy failes with this error: > > ERROR: (gcloud.preview.app.deploy) Not enough VMs ready (0/1 ready, 1 > failed). The user does not have access to service account ' > frien...@appspot.gserviceaccount.com ' Deployed Version: > 20151010t162759.387751622472188220 > > This can happen when your application does not start successfully. > Please check your project logs at: > > https://console.developers.google.com/project/friendspme/appengine/logs?versionId=20151010t162759=default > > Logs are empty of course. > > I have no idea what may be wrong. Can anybody help? > > Thank you. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/1dcd16f6-da5a-4044-b4b7-04d0decf08a4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Problem with Node.js Managed VMs deployment
Agree that it looks like a permissions issue based on "The user does not have access to service account ...". That's why I was interested in whether the image and app worked locally. I run node.js in managed VMs, but have not encountered your specific problem unfortunately. On Saturday, October 10, 2015 at 3:41:33 PM UTC-4, Alois Bělaška wrote: > > Hey Michael, > > I've started with a simple project that I am able to deploy to a new > project but I am not able to deploy to one old project. > > I can deploy for example go project to the old project without a single > problem, the only problem is with managed VM GAE app. > > I am using the latest Google Cloud SDK 0.9.81 > > app 2015.10.05 > app-engine-java 1.9.27 > app-engine-php > app-engine-python 1.9.27 > beta 2015.10.05 > bq 2.0.18 > bq-nix 2.0.18 > core 2015.10.05 > core-nix 2015.09.03 > gcloud 2015.10.05 > gsutil 4.15 > gsutil-nix 4.14 > kubectl > kubectl-linux-x86_64 1.0.6 > > It looks more like permissions problem with my old project. > > HAve you ever encountered such a problem? > > On Saturday, October 10, 2015 at 9:01:05 PM UTC+2, Michael Spainhower > wrote: >> >> Have you run your image in a local docker container and logged into it to >> see whether it works correctly? If so, what did you find? If not, I >> highly recommend this approach. >> >> Also, have you tried running the app locally using the `gcloud` command? >> https://cloud.google.com/appengine/docs/managed-vms/sdk#run-local >> >> I am sure you have, but just to double check - you have run `gcloud >> components update` recently as well right? >> >> Cheers, >> --Spain >> >> On Saturday, October 10, 2015 at 10:30:52 AM UTC-4, Alois Bělaška wrote: >>> >>> Hi, >>> >>> I've run into a problem with deployment of node.js managed VM to GAE. >>> Docker container is build successfully, new version established but then >>> the deloy failes with this error: >>> >>> ERROR: (gcloud.preview.app.deploy) Not enough VMs ready (0/1 ready, 1 >>> failed). The user does not have access to service account ' >>> frien...@appspot.gserviceaccount.com' Deployed Version: >>> 20151010t162759.387751622472188220 >>> >>> This can happen when your application does not start successfully. >>> Please check your project logs at: >>> >>> https://console.developers.google.com/project/friendspme/appengine/logs?versionId=20151010t162759=default >>> >>> Logs are empty of course. >>> >>> I have no idea what may be wrong. Can anybody help? >>> >>> Thank you. >>> >> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/a5a22ade-8cb5-4b04-a684-a49cf7e9845f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Old versions of Managed VMs
Could anyone from Google comment on whether there is a plan to fix this issue? Versions that are not getting traffic really shouldn't have instances constantly running. Only using (and paying for) the resources that you really need and use is one of the key value props of Google Cloud and GAE. On Tuesday, September 15, 2015 at 7:15:10 PM UTC-4, Jeff Schnitzer wrote: > > I have a python app on a Managed VM which I deploy with: > > gcloud preview app deploy app.yaml --remote --set-default > > It's set to manual scaling, instances 1. > > It appears that every time I deploy it, the old instance stick around (and > get billed for). Even deleting the old versions from the appengine console > didn't shut down the compute engine instances. I had to figure out which > compute engine instance was my "live" one and delete all the others from > the Compute Engine part of the console. > > Is this supposed to work this way or is there a better workflow? I just > want to deploy the new version and have the old version go away... like > regular App Engine. > > Jeff > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/853b7998-fa21-4a65-a6a7-4a19dc778c5a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Old versions of Managed VMs
I am using managed vms and also have the issue of non-default versions running residual instances. However, I do not experience the issue you have described where the instances remain even after deleting the non-default versions. Are you using a standard runtime or custom runtime (https://cloud.google.com/appengine/docs/managed-vms/#runtimes)? The lifecycle (shutdown) request handling seems like a potential culprit, so that may be worth examining if you are using a custom runtime. I am using a node custom Dockerfile and my app just returns a 200 on requests to ` /_ah/stop` (https://github.com/home-buddy/express-appengine-handlers/blob/master/index.js#L18). You can probably check your logs for requests to that URL to see if there are non-200 responses. What version of the gcloud cli tool are you running? While potentially unrelated to this issue, you may want to update it because I do not think `--remote` is an option anymore (implying you may need an update). As an aside, I would love guidance on fixing the issue where every non-default version has instances running. Perhaps this is the expected behavior since managed VMs is labeled as beta? On Tuesday, September 15, 2015 at 7:15:10 PM UTC-4, Jeff Schnitzer wrote: > > I have a python app on a Managed VM which I deploy with: > > gcloud preview app deploy app.yaml --remote --set-default > > It's set to manual scaling, instances 1. > > It appears that every time I deploy it, the old instance stick around (and > get billed for). Even deleting the old versions from the appengine console > didn't shut down the compute engine instances. I had to figure out which > compute engine instance was my "live" one and delete all the others from > the Compute Engine part of the console. > > Is this supposed to work this way or is there a better workflow? I just > want to deploy the new version and have the old version go away... like > regular App Engine. > > Jeff > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/7779690b-5a1a-41df-8bdc-2c179daab1e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Python/Endpoints: Workaround for known Exception content-length issue?
> the line numbers for the patch have changed slightly That is basically the answer. On CI runs we always bring in the latest SDK release, so we would have to both script the patching to run on CI (not terrible) and keep it up-to-date along with SDK updates (not something I wish to do). For now I have been structuring my code so I can test Exceptions in non-Endpoints unit tests. I prefer to just refactor code and tests later (on our schedule) rather than have things break on CI unexpectedly. > We're currently working on getting this fixed Awesome, glad to hear it! cheers On Thursday, September 10, 2015 at 6:58:02 PM UTC-4, Nick (Cloud Platform Support) wrote: > > It's worth noting that the line numbers for the patch have changed > slightly, but the relevant code can still be patched. > > On Thursday, September 10, 2015 at 6:57:28 PM UTC-4, Nick (Cloud Platform > Support) wrote: >> >> Hey Michael, >> >> Thanks for bringing this up. We're currently working on getting this >> fixed. Is there any reason the patch suggested in the linked stackoverflow >> question won't help with your SDK for now? >> >> Best wishes, >> >> Nick >> >> On Thursday, August 20, 2015 at 1:44:22 AM UTC-4, Michael Spainhower >> wrote: >>> >>> Has anyone found a good workaround (not patching the library) for the >>> issue (https://code.google.com/p/googleappengine/issues/detail?id=10544) >>> that prevents testing Exceptions raised in Endpoints handlers? >>> >>> If you are unfamiliar with the issue, when an Endpoints handler raises >>> an Exception during an automated test, the content-length of the response >>> is not updated according to the content size of the serialized Exception >>> and raises "AssertionError: Content-Length is different from actual >>> app_iter length (512!=93)" >>> >>> Hopefully the real fix is released soon. Even though this is a dev and >>> testing, not production, issue, not being able to test Exception handling >>> is a pretty significant issue as far as non-production issues go. >>> >>> More context / See also: >>> http://stackoverflow.com/questions/24219654/content-length-error-in-google-cloud-endpoints-testing >>> >> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/a88a79a9-ef51-4624-9206-9e768207dc01%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Python/Endpoints: Workaround for known Exception content-length issue?
Has anyone found a good workaround (not patching the library) for the issue (https://code.google.com/p/googleappengine/issues/detail?id=10544) that prevents testing Exceptions raised in Endpoints handlers? If you are unfamiliar with the issue, when an Endpoints handler raises an Exception during an automated test, the content-length of the response is not updated according to the content size of the serialized Exception and raises AssertionError: Content-Length is different from actual app_iter length (512!=93) Hopefully the real fix is released soon. Even though this is a dev and testing, not production, issue, not being able to test Exception handling is a pretty significant issue as far as non-production issues go. More context / See also: http://stackoverflow.com/questions/24219654/content-length-error-in-google-cloud-endpoints-testing -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/487bbca5-d6d6-4b57-bf8d-ca00d8d59e49%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: python: error when calling platform.platform()
I want the 3rd party library (Authy) to work without modification in a way that is unlikely to break upon a change in that library, GAE, or the python 2.7 native API. Authy only uses the result of platform.platform() to create its user agent string for http requests, so it doesn't really matter what it returns. The hack I am currently using, that technically works, is import platform platform.platform = lambda aliased=0, terse=0: 'GAE' This may be as good as it gets until the 3rd party library includes better exception handling, but I am happy to solicit solutions that may be less likely to break. On Tuesday, August 11, 2015 at 9:55:48 AM UTC-4, Patrice (Cloud Platform Support) wrote: Hi! What do you want exactly? The platform.platform call to work? I don't think it can, unless you can change where it tries to get libc's version. Do you want to be able to look in the fs of your instance? You can't. If what you want is a platform string, you could always create your own string, put it in an environment variable (in your app.yaml) and get it there? If you could explain what you expect to get and do with the platform.platform return, I'd be happy to look into ways for you to do it. Cheers! On Monday, August 10, 2015 at 8:51:13 PM UTC-4, Michael Spainhower wrote: I have a 3rd party library (Authy) that calls `platform.platform()` ( https://docs.python.org/2/library/platform.html#platform.platform). Unfortunately, when this function tries to get the libc version (assuming so, function is named libc_ver), it tries to open the file /usr/bin/python. Obviously this does not work. Is there an established approach to handle this? It seems like the kind of thing that would be stubbed out by GAE SDK (returning its own platform string, or an empty string). I'll probably submit a PR for better exception handling with the library maintainer, but in the meantime I'd love a reasonable mitigation (I can think of some nasty hacks that would work). Cheers, --Spain -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/dcd8be6f-88c1-460d-a61d-44bde07452d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] python: error when calling platform.platform()
I have a 3rd party library (Authy) that calls `platform.platform()` (https://docs.python.org/2/library/platform.html#platform.platform). Unfortunately, when this function tries to get the libc version (assuming so, function is named libc_ver), it tries to open the file /usr/bin/python. Obviously this does not work. Is there an established approach to handle this? It seems like the kind of thing that would be stubbed out by GAE SDK (returning its own platform string, or an empty string). I'll probably submit a PR for better exception handling with the library maintainer, but in the meantime I'd love a reasonable mitigation (I can think of some nasty hacks that would work). Cheers, --Spain -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/2e0d4331-561a-431b-a0a9-7dbee82f6b1b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Best (hosted) CI solution to use with GAE (Python)?
Also, CodeShip has built in support for deploying to GAE. I have not used CodeShip myself. https://codeship.com/documentation/continuous-deployment/deployment-to-google-app-engine/ On Monday, August 3, 2015 at 6:29:41 AM UTC-4, Filip Nilsson wrote: Hi! Does anyone have experiences to share regarding hosted CI providers and Google App Engine. Currently I have my tests running locally using nose and nose-gae. One provider I have been looking at is CircleCI. Seems quite nice, they have instructions on how to set up testing with GAE. Any thoughts are welcome! Thanks in advance, Filip -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/862cde72-06fa-4a6f-b8ee-645edf9fc19e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Best (hosted) CI solution to use with GAE (Python)?
We use CircleCI and it is great for testing Python GAE apps. Here (https://gist.github.com/SpainTrain/28fe7da692f5b9bf3266) is a gist for our circle.yml, Makefile, .noserc, and requirements.txt as an example. We use vendoring (https://cloud.google.com/appengine/docs/python/tools/libraries27?hl=en#vendoring), so this config basically does the following: - Updates certain global pypi pkgs - Installs the local vendored pypi packages - Installs the GAE SDK - Runs linters - Runs tests with nose (outputting artifacts for results xml, coverage, and profiling) - [when building master branch] run a deployment script As a bit of errata, do not worry about caching the downloaded SDK zip files. CircleCI already reverse proxies these downloads with a cache, so they are extremely fast. As a different example, this project skeleton seems to use TravisCI - https://github.com/rbanffy/testable_appengine cheers, --Spain On Monday, August 3, 2015 at 6:29:41 AM UTC-4, Filip Nilsson wrote: Hi! Does anyone have experiences to share regarding hosted CI providers and Google App Engine. Currently I have my tests running locally using nose and nose-gae. One provider I have been looking at is CircleCI. Seems quite nice, they have instructions on how to set up testing with GAE. Any thoughts are welcome! Thanks in advance, Filip -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/b91b9b05-164b-4c3e-9f87-9ef78c78de51%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Have you had success with Traffic Splitting? How do you use it to roll out new versions?
Sure, I don't think David or I have any question of whether canary testing is a possible or intended use case of traffic splitting. I am interested in how folks have implemented it in practice for production apps. For example, I don't have a great solution for canary testing a version which changes the ndb model schema. I would love to hear the concrete lessons learned from anyone who has done such a thing. Another example is how do you elegantly synchronize decoupled apps? What I mean is that e.g., we run our APIs in a different project than our web front-end. There are several ways to handle this, but again would love to get war stories from anyone who has run something similar in production. On Friday, July 24, 2015 at 3:56:27 PM UTC-4, Jason Collins wrote: Traffic-splitting / canary releases on App Engine are definitely a thing. Traffic-splits on non-default modules are now available via API: https://cloud.google.com/appengine/docs/admin-api/quickstart/#splitting_traffic On Friday, 24 July 2015 11:50:33 UTC-7, Michael Spainhower wrote: @David, I started following this thread because I have the exact same question and agree the lack of response is worrisome. We are in the Cloud Startup Program and I plan to ask about canary testing during my next engineering 1-on-1. I will reply to this thread with what I learn from their engineer. On Friday, July 24, 2015 at 9:14:02 AM UTC-4, David Hardwick wrote: Oh boy, the lack of response here is not encouraging On Tuesday, July 21, 2015 at 1:53:17 PM UTC-4, David Hardwick wrote: Hello, We haven't used Traffic Splitting yet but it has been an available feature for a while and rumor has it that traffic splitting for non-default modules could be coming in as soon as a month. Any who, if you have experience use it, then I would like to hear how you are using it to roll out new features or versions. I've heard the term 'canary' testing where you roll out a new version to 10% of folks...you measure the results and then either rollback and fully roll it out. So if anyone is doing 'canary' testing and deployments as I've described it, then I've like to hear from you. Thanks in advance, Hardwick -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/d7a1d39c-24c8-48f4-aee3-08a452a75148%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[google-appengine] Re: Have you had success with Traffic Splitting? How do you use it to roll out new versions?
@David, I started following this thread because I have the exact same question and agree the lack of response is worrisome. We are in the Cloud Startup Program and I plan to ask about canary testing during my next engineering 1-on-1. I will reply to this thread with what I learn from their engineer. On Friday, July 24, 2015 at 9:14:02 AM UTC-4, David Hardwick wrote: Oh boy, the lack of response here is not encouraging On Tuesday, July 21, 2015 at 1:53:17 PM UTC-4, David Hardwick wrote: Hello, We haven't used Traffic Splitting yet but it has been an available feature for a while and rumor has it that traffic splitting for non-default modules could be coming in as soon as a month. Any who, if you have experience use it, then I would like to hear how you are using it to roll out new features or versions. I've heard the term 'canary' testing where you roll out a new version to 10% of folks...you measure the results and then either rollback and fully roll it out. So if anyone is doing 'canary' testing and deployments as I've described it, then I've like to hear from you. Thanks in advance, Hardwick -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/f8afb2b9-ad65-48a3-8aa2-3df98408f33b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [google-appengine] Re: HTTP/2 Protocol Support
Not sure if they have a limit on number of certs you can request, but https://www.startssl.com/?app=1 may be an options for you. On Saturday, March 21, 2015 at 3:03:57 PM UTC-4, Alexander Trakhimenok wrote: Not an option for us - we have too many domains linked to the app and costs for acquiring SSL certificates would be prohibitive. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/797b54f3-3779-4816-87f0-ef6b6eaa74e0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
