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?
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,
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
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
>> 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/googleap
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
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
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.
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
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
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
@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
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
13 matches
Mail list logo
