Re: [google-appengine] Python 3 local development: fast startup or static assets, choose one?

[Ryan B]

I revisited this again recently and wrote a drop-in Flask extension that 
serves app.yaml static file and directory handlers: flask-gae-static 
<https://github.com/snarfed/flask-gae-static>. Feedback is welcome!

On Sunday, October 31, 2021 at 10:39:33 AM UTC-7 Ryan B wrote:

> Resurrecting this year and a half old thread to plug 
> https://github.com/XeoN-GHMB/app_server , a little dev_appserver 
> replacement that wraps your existing local app server and adds static file 
> serving that supports app.yaml static_* handlers. Sounds similar to the 40 
> line middleware you mentioned.
>
> I was finally forced to migrate away from dev_appserver due to the 
> continued degrading of the Python 2 ecosystem. Specifically, when I 
> migrated to macOS Monterey, dev_appserver failed to start and complained, 
> Cannot 
> use the Cloud Datastore Emulator because the packaged grpcio is 
> incompatible to this system. Please install grpcio using pip. I tried to 
> install grpcio for Python 2, but Montery doesn't include Python 2's pip, 
> and easy_install couldn't install it. app_server to the rescue!
>
> On Sunday, December 15, 2019 at 9:22:49 AM UTC-8 re...@el-tramo.be wrote:
>
>> Hi Ryan,
>>  
>>
>>> understood, but using a different static file server is not great. it 
>>> makes local development diverge significantly from production. local no 
>>> longer uses or tests app.yaml's static file handlers, but prod does, so 
>>> bugs will eventually pop up that only happen in production, and are thus 
>>> harder to test for and debug.
>>>
>>
>> The way I solve this is to have a little piece of middleware (only in dev 
>> mode) that loads app.yaml and serves the static_* handlers statically. The 
>> basic logic (I might not be handling all cover cases, but it works for me) 
>> is pretty simple, and the entire middleware class takes about 40 lines of 
>> code.
>>
>> thanks,
>> Remko
>>
>>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/369fedf4-ea0b-46a3-a62e-1e629af518cfn%40googlegroups.com.

Re: [google-appengine] Python 3 local development: fast startup or static assets, choose one?

[Ryan B]

Resurrecting this year and a half old thread to plug 
https://github.com/XeoN-GHMB/app_server , a little dev_appserver 
replacement that wraps your existing local app server and adds static file 
serving that supports app.yaml static_* handlers. Sounds similar to the 40 
line middleware you mentioned.

I was finally forced to migrate away from dev_appserver due to the 
continued degrading of the Python 2 ecosystem. Specifically, when I 
migrated to macOS Monterey, dev_appserver failed to start and complained, 
Cannot 
use the Cloud Datastore Emulator because the packaged grpcio is 
incompatible to this system. Please install grpcio using pip. I tried to 
install grpcio for Python 2, but Montery doesn't include Python 2's pip, 
and easy_install couldn't install it. app_server to the rescue!

On Sunday, December 15, 2019 at 9:22:49 AM UTC-8 re...@el-tramo.be wrote:

> Hi Ryan,
>  
>
>> understood, but using a different static file server is not great. it 
>> makes local development diverge significantly from production. local no 
>> longer uses or tests app.yaml's static file handlers, but prod does, so 
>> bugs will eventually pop up that only happen in production, and are thus 
>> harder to test for and debug.
>>
>
> The way I solve this is to have a little piece of middleware (only in dev 
> mode) that loads app.yaml and serves the static_* handlers statically. The 
> basic logic (I might not be handling all cover cases, but it works for me) 
> is pretty simple, and the entire middleware class takes about 40 lines of 
> code.
>
> thanks,
> Remko
>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/5262282a-44df-46e5-8bff-8de519f618ccn%40googlegroups.com.

[google-appengine] Re: Did the standard environment auto scaling scheduler change recently?

[Ryan B]

Thanks for looking! I made that app.yaml change (including min_pending_latency) 
after I noticed the scheduling change. It successfully brought my instance 
count back down, but it didn't explain what caused the initial increase. I'm 
still curious about that.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/e903cb28-4536-4307-b618-37ccc9371cado%40googlegroups.com.

[google-appengine] Re: Did the standard environment auto scaling scheduler change recently?

[Ryan B]

I changed my autoscaling settings to be much more aggressive, below, and 
steady state instance count is back down to more or less where it was 
before. I'm stil very curious what changed on App Engine's end, but I'm at 
least out of the woods for now.

automatic_scaling:
 max_idle_instances: 1
 target_cpu_utilization: .9
 min_pending_latency: 500ms
 max_concurrent_requests: 30 

On Monday, June 28, 2021 at 10:27:13 AM UTC-7 Ryan B wrote:

> Hi all! The steady state instance count for a couple of my apps (on Python 
> 3 Standard) increased recently, over the last week or two, without any 
> obvious code or architecture or traffic or load or change on my end. Did 
> the App Engine scheduler itself change recently?
>
> Here's the active instance count for one app. I haven't deployed a new 
> version since April, and load (etc) haven't meaningfully changed either.
>
> [image: 123658491-a116ad80-d7e6-11eb-8805-9ef33584cff7.png]
>
> Here's another. I deploy this one more often, multiple times a week, but 
> nothing related to utilization recently that I can think of, and there 
> haven't been any other architectural, app config, or load for months.
>
> [image: 123658263-657be380-d7e6-11eb-89b4-a8e334e0c5f8.png]
>
> Here are the app.yaml files; neither has changed since March, when I 
> upgraded both apps to Python 3.9.
> https://github.com/snarfed/bridgy-fed/blob/main/app.yaml
> https://github.com/snarfed/bridgy/blob/main/app.yaml
>
> If the scheduler did change, any chance anyone knows how to configure it 
> to get my steady state instance counts back to where they were before?
>
> Thanks in advance!
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/beb53b01-887e-4e74-8e07-68d9d2b262dan%40googlegroups.com.

Re: [google-appengine] Re: Appengine Dashboard broken?

[Ryan B]

Same here. The Current load, Application Errors, Server Errors, and Client 
Errors sections of the dashboard have been empty in pretty much all of my 
projects for a week or so now. Example project ids: brid-gy, 
bridgy-federated, granary-demo, oauth-dropins.

On Saturday, October 10, 2020 at 1:38:08 PM UTC-7 vit@gmail.com wrote:

> Hi.
>
> project: telegram-email
>
> [image: 1.PNG]
>
> суббота, 10 октября 2020 г. в 22:54:28 UTC+4, yananc: 
>
>> Hello, 
>>
>> We have received reports of the similar issue recently. The issue seemed 
>> to be transient and disappeared after a while. Does the issue still persist 
>> in your case? If so, would you please provide more information so we could 
>> look into it? Thank you.
>>
>>
>> On Thursday, October 8, 2020 at 3:40:44 PM UTC-4 vit@gmail.com wrote:
>>
>>> Same issue.
>>>
>>> Also:
>>>
>>> Client Errors 
>>> This app has not received any client errors in the last 24 hours.
>>>
>>> четверг, 8 октября 2020 г. в 21:08:56 UTC+4, linus@epspot.com: 
>>>
 Works again for me now.magic.

 Den tor 8 okt. 2020 10:19troberti  skrev:

> We have the same issue, for all our Appengine projects.
>
> On Wednesday, October 7, 2020 at 11:02:47 PM UTC+2 linus@gmail.com 
> wrote:
>
>> In cloud console, Appengine Dasboard for a few days it says:
>>
>> Current load
>>
>> This app has not received any requests in the last 24 hours.
>>
>> This is obviously wrong since I have loads of requests in the logs 
>> and I get billed for them as well.
>>
>> This used to show the top 10 or 20 requested urls, is it broken?
>>
>> The Dashboard in Home works as expected.
>>
>>
>> -- 
> 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-appengi...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/google-appengine/81428dd7-9003-4dd7-98de-2a52042cdd9en%40googlegroups.com
>  
> 
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/2c693f88-402f-417e-a67e-1ae77c7a2bb9n%40googlegroups.com.

[google-appengine] Re: App Engine HTTP issues

[Ryan B]

Looks like they're in the middle of a partial outage right now. 
https://status.cloud.google.com/

On Tuesday, October 6, 2020 at 8:08:44 AM UTC-7 kris...@escapemasters.co.nz 
wrote:

> Hi All,
> In the past hour we faced on standard java App Engine with numerous 
> unexpected error as java.net.UnknownHostException, ServiceConfigException: 
> java.net.UnknownHostException: servicemanagement.googleapis.com. On our 
> side nothing has been changed. 
> Moreover, when I tried to migrate the traffic to an older version the 
> traffic migration failed in half way.
>
> Who knows anything about this kind of outage?
>
> Thanks in advance,
> Krisztián Guba
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/435fad9f-0b88-4833-91c0-05756d89d0d7n%40googlegroups.com.

[google-appengine] Re: appspot.com started rejecting SSL without SNI causing U-Blox IoT modems to fail, since May

[Ryan B]

Interesting! And concerning. I'd definitely care about this too.

Just as another data point, I checked one of my apps that serves from both 
a custom domain (https://brid.gy/) and appspot 
(https://brid-gy.appspot.com/), and Qualys's SSL Labs test shows that the 
appspot subdomain is still happily supporting traditional IP-based SSL, 
without SNI.

   - 
   
https://www.ssllabs.com/ssltest/analyze.html?d=brid%2dgy.appspot.com=2607%3af8b0%3a4005%3a808%3a0%3a0%3a0%3a2014=on
   - 
   
https://www.ssllabs.com/ssltest/analyze.html?d=brid.gy=2001%3a4860%3a4802%3a32%3a0%3a0%3a0%3a15=on

On Tuesday, July 28, 2020 at 5:07:30 AM UTC-7 bjorn...@gmail.com wrote:

> We have a large fleet of *U-Blox* IoT modem-equipped devices out there, 
> calling in to our backend on AppEngine, using SSL to .
> appspot.com (we don't have any custom SSL cert or managed cert).
>
> Up until May 26 or so this year this has worked fine, after that some 
> endpoints started failing the SSL handshake, and the problem became worse 
> and worse until the entire fleet was disabled.
>
> U-Blox managed to trace it to a failing SSL negotiation, and that their 
> modems don't support the SSL SNI (Server Name Identification) option, which 
> is required normally to differ between certs on a server that has multiple 
> certs on the same IP.
>
> Sure enough, I checked with openssl s_client -noservername and it fails to 
> appspot.com now -* it doesn't provide the normal default cert of 
> *.appspot.com  anymore* when no SNI is given (just 
> the No SNI provided; please fix your client. message).
>
> I didn't find anything in the AppEngine release notes about this change.
>
> Now, this is a tricky because yes, SNI has been around since 2002 and I 
> think it's even mandatory in TLSv1.3. On the other hand, there must be 
> hundreds of thousands of U-Blox modems out there that doesn't support this, 
> and the companies that have built IoT products around AppEngine and U-Blox 
> (like us) will start to see their fleets fail.
>
> *Would it be possible to re-instate a default handling of the SSL 
> endpoints on appspot.com  to provide a default cert of 
> *.appspot.com  ? *
>
> We had to go non-encrypted as a panic work-around, which is obviously not 
> desirable.
>
> Another work-around is to purchase a completely separate IP and custom SSL 
> cert; this would remove the semantical requirement of SNI but it would be 
> helpful to confirm if there would still be a technical requirement for it 
> due to the way the AppEngine SSL endpoints are configured in that case.
>
> Best regards
> /Bjorn
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/a08842e6-87d3-4428-bafd-971d93d2b7f4n%40googlegroups.com.

Re: [google-appengine] Re: Any more migration stories?

[Ryan B]

hey alex, long time no see! yup, tests were a life saver for me in these 
migrations. probably also the single best technique i know of for software 
productivity and quality over time in general.

re testing jinja templates, i've gradually leaned toward writing more and 
more web app unit tests at the HTTP request level, integration test style, 
which makes testing templates and HTML output easier. set up the context, 
make the request, check the HTML output. example:

https://github.com/snarfed/bridgy/blob/dab476ec1f7cfd261341f381de645edaf3d97599/tests/test_app.py#L375-L381

On Thursday, May 7, 2020 at 4:06:25 PM UTC-7, Alex Martelli wrote:
>
> Just as a personal note (I'm a Googler but also help maintain App Engine 
> non-profit sites in my spare time etc), I enthusiastically agree that the 
> migration suddenly validated my own long-standing obsession with more and 
> more (automated, esp. unit) testing -- suddenly, that boring test activity 
> became a life-saver, catching most glitches well before moving into 
> staging, much less prod.
>
> Unsurprisingly the main exceptions (which we had to catch over time) were 
> about code hidden in Jinjia templates, which I had never thought of 
> subjecting to the same ambitious, aspirational standards of coverage I hold 
> Python code in .py files to.
>
> There ARE ways to unit test code hidden in Jinja, and I plan to research 
> and apply them, but the error I made as a tech lead in not insisting on 
> such testing earlier is yet another confirmation of how precious unit tests 
> ARE!-)
>
> Alex
>
> On Thu, May 7, 2020 at 3:42 PM Ryan B > 
> wrote:
>
>> i was also extremely fortunate that pretty much all of these apps had 
>> solid unit test coverage, which automatically found the vast majority of 
>> code that needed updating. if i'd had to resort to "rigorous search and 
>> runtime errors," as joshua mentioned, i'd probably be a lot more frustrated.
>>
>> On Thursday, May 7, 2020 at 3:38:57 PM UTC-7, Ryan B wrote:
>>>
>>> hi charlie, thanks for asking!
>>>
>>> my experience was similar to joshua's, if not quite so extreme. i've 
>>> migrated seven or so apps now, the largest weighing in at 26kloc. the big 
>>> differences in API availability and compatibility were the most painful 
>>> parts, followed by changes and difficulties with local development, as 
>>> joshua mentioned.
>>>
>>> here are a handful of threads and issues with details:
>>>
>>>- local dev, deployment:
>>>- 
>>>   
>>> https://groups.google.com/d/topic/google-appengine/BJDE8y2KISM/discussion 
>>>   (fast startup or static assets, choose one?)
>>>   - https://issuetracker.google.com/issues/144150446 (dev_appserver 
>>>   patch to fix this)
>>>   - https://issuetracker.google.com/issues/146780347 (Cloud Build 
>>>   uses stale GitHub clones)
>>>   - logging:
>>>- 
>>>   
>>> https://groups.google.com/d/topic/google-appengine/xTDZ-da27ow/discussion 
>>>   (difficulties reading GAE app logs from the logging API)
>>>   - 
>>>   
>>> https://stackoverflow.com/questions/58753378/how-to-deserialize-app-engine-application-logs-from-stackdriver-logging-api
>>>   - https://github.com/googleapis/google-cloud-python/issues/2572
>>>   - https://github.com/snarfed/bridgy/issues/940 (my app's feature 
>>>   that uses logging API is now way slower)
>>>   - 
>>>   
>>> https://groups.google.com/forum/#!topic/google-stackdriver-discussion/k96EQHCacKM
>>>  
>>>   (can't request increase to logs API read quota)
>>>   - 
>>>   
>>> https://stackoverflow.com/questions/59398479/why-is-my-app-engine-app-hitting-the-stackdriver-logging-256kb-limit
>>>   - https://github.com/snarfed/bridgy/issues/904 (originally 
>>>   ingested way more logs than i expected)
>>>   - ndb, misc growing pains:
>>>- https://github.com/googleapis/python-ndb/issues/263
>>>   - https://github.com/googleapis/python-ndb/issues/238
>>>   - https://github.com/googleapis/python-ndb/issues/277
>>>   - https://github.com/googleapis/python-ndb/issues/376
>>>   - https://github.com/googleapis/python-ndb/issues/267
>>>- cloud tasks missing local emulator, transactional tasks
>>>   - 
>>>   
>>> https://cloud.google.com/tasks/docs/migrating#features_in_task_queues_not_yet_available_via
>>>- migration increased our frontend instan

[google-appengine] Re: Any more migration stories?

[Ryan B]

i was also extremely fortunate that pretty much all of these apps had solid 
unit test coverage, which automatically found the vast majority of code 
that needed updating. if i'd had to resort to "rigorous search and runtime 
errors," as joshua mentioned, i'd probably be a lot more frustrated.

On Thursday, May 7, 2020 at 3:38:57 PM UTC-7, Ryan B wrote:
>
> hi charlie, thanks for asking!
>
> my experience was similar to joshua's, if not quite so extreme. i've 
> migrated seven or so apps now, the largest weighing in at 26kloc. the big 
> differences in API availability and compatibility were the most painful 
> parts, followed by changes and difficulties with local development, as 
> joshua mentioned.
>
> here are a handful of threads and issues with details:
>
>- local dev, deployment:
>- 
>   
> https://groups.google.com/d/topic/google-appengine/BJDE8y2KISM/discussion 
>   (fast startup or static assets, choose one?)
>   - https://issuetracker.google.com/issues/144150446 (dev_appserver 
>   patch to fix this)
>   - https://issuetracker.google.com/issues/146780347 (Cloud Build 
>   uses stale GitHub clones)
>   - logging:
>- 
>   
> https://groups.google.com/d/topic/google-appengine/xTDZ-da27ow/discussion 
>   (difficulties reading GAE app logs from the logging API)
>   - 
>   
> https://stackoverflow.com/questions/58753378/how-to-deserialize-app-engine-application-logs-from-stackdriver-logging-api
>   - https://github.com/googleapis/google-cloud-python/issues/2572
>   - https://github.com/snarfed/bridgy/issues/940 (my app's feature 
>   that uses logging API is now way slower)
>   - 
>   
> https://groups.google.com/forum/#!topic/google-stackdriver-discussion/k96EQHCacKM
>  
>   (can't request increase to logs API read quota)
>   - 
>   
> https://stackoverflow.com/questions/59398479/why-is-my-app-engine-app-hitting-the-stackdriver-logging-256kb-limit
>   - https://github.com/snarfed/bridgy/issues/904 (originally ingested 
>   way more logs than i expected)
>   - ndb, misc growing pains:
>- https://github.com/googleapis/python-ndb/issues/263
>   - https://github.com/googleapis/python-ndb/issues/238
>   - https://github.com/googleapis/python-ndb/issues/277
>   - https://github.com/googleapis/python-ndb/issues/376
>   - https://github.com/googleapis/python-ndb/issues/267
>- cloud tasks missing local emulator, transactional tasks
>   - 
>   
> https://cloud.google.com/tasks/docs/migrating#features_in_task_queues_not_yet_available_via
>- migration increased our frontend instance usage noticeably, had to 
>rearchitect and extract out task processing into a separate background 
>service to get costs back down: 
>https://github.com/snarfed/bridgy/issues/578
>(not entirely sure this was GAE's fault)
>- shared memcache got lost entirely, so i had to switch to a runtime 
>in-memory cache, which isn't as helpful
>- https://github.com/GoogleCloudPlatform/webapp2/issues/151 (webapp2 
>is unmaintained, and its port to Python 3 is a bit rough)
>- 
>https://groups.google.com/d/topic/google-appengine/WHo99Gz1S3g/discussion 
>(difficulty finding replacement for app_identity module)
>
>
>
> On Tuesday, May 5, 2020 at 2:06:48 PM UTC-7, Charlie Engelke wrote:
>>
>> This is very helpful feedback. Anybody else have comments for us?
>>
>> On Tuesday, May 5, 2020 at 1:17:52 PM UTC-7 Charlie Engelke wrote:
>>
>>> I'd still like to here anyone's stories involving migrating their App 
>>> Engine apps from Python 2.7 to Python 3.7. Have you migrated yet? Planning 
>>> to do so soon? Not going to move to the new platform?
>>>
>>> And any particular pain points? Things that would have helped? 
>>>
>>> Thanks,
>>>
>>> Charlie
>>>
>>> On Friday, May 1, 2020 at 2:18:33 PM UTC-7 Charlie Engelke wrote:
>>>
>>>> Have you recently migrated from App Engine for Python 2.7 to App Engine 
>>>> for Python 3.7? Are you working on migrating now, or planning to soon? Or 
>>>> maybe you are using App Engine for Python 2.7 and aren't planning such a 
>>>> migration.
>>>>
>>>> In each of those cases, I'd like to hear how things went or are going 
>>>> for you, pain points you encounter, things that went easily, and anything 
>>>> else you have to share. I'm working on creating some new code samples to 
>>>> help with this, and your stories will be a big help.
>>>>
>>>> Thanks,
>>>>
>>>> Charlie
>>>>
>>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/5f63c9c5-72f3-40f5-a0b5-cd92979cda2d%40googlegroups.com.

[google-appengine] Re: Any more migration stories?

[Ryan B]

hi charlie, thanks for asking!

my experience was similar to joshua's, if not quite so extreme. i've 
migrated seven or so apps now, the largest weighing in at 26kloc. the big 
differences in API availability and compatibility were the most painful 
parts, followed by changes and difficulties with local development, as 
joshua mentioned.

here are a handful of threads and issues with details:

   - local dev, deployment:
   - 
  https://groups.google.com/d/topic/google-appengine/BJDE8y2KISM/discussion 
  (fast startup or static assets, choose one?)
  - https://issuetracker.google.com/issues/144150446 (dev_appserver 
  patch to fix this)
  - https://issuetracker.google.com/issues/146780347 (Cloud Build uses 
  stale GitHub clones)
  - logging:
   - 
  https://groups.google.com/d/topic/google-appengine/xTDZ-da27ow/discussion 
  (difficulties reading GAE app logs from the logging API)
  - 
  
https://stackoverflow.com/questions/58753378/how-to-deserialize-app-engine-application-logs-from-stackdriver-logging-api
  - https://github.com/googleapis/google-cloud-python/issues/2572
  - https://github.com/snarfed/bridgy/issues/940 (my app's feature that 
  uses logging API is now way slower)
  - 
  
https://groups.google.com/forum/#!topic/google-stackdriver-discussion/k96EQHCacKM
 
  (can't request increase to logs API read quota)
  - 
  
https://stackoverflow.com/questions/59398479/why-is-my-app-engine-app-hitting-the-stackdriver-logging-256kb-limit
  - https://github.com/snarfed/bridgy/issues/904 (originally ingested 
  way more logs than i expected)
  - ndb, misc growing pains:
   - https://github.com/googleapis/python-ndb/issues/263
  - https://github.com/googleapis/python-ndb/issues/238
  - https://github.com/googleapis/python-ndb/issues/277
  - https://github.com/googleapis/python-ndb/issues/376
  - https://github.com/googleapis/python-ndb/issues/267
   - cloud tasks missing local emulator, transactional tasks
  - 
  
https://cloud.google.com/tasks/docs/migrating#features_in_task_queues_not_yet_available_via
   - migration increased our frontend instance usage noticeably, had to 
   rearchitect and extract out task processing into a separate background 
   service to get costs back down: 
   https://github.com/snarfed/bridgy/issues/578
   (not entirely sure this was GAE's fault)
   - shared memcache got lost entirely, so i had to switch to a runtime 
   in-memory cache, which isn't as helpful
   - https://github.com/GoogleCloudPlatform/webapp2/issues/151 (webapp2 is 
   unmaintained, and its port to Python 3 is a bit rough)
   - 
   https://groups.google.com/d/topic/google-appengine/WHo99Gz1S3g/discussion 
   (difficulty finding replacement for app_identity module)
   


On Tuesday, May 5, 2020 at 2:06:48 PM UTC-7, Charlie Engelke wrote:
>
> This is very helpful feedback. Anybody else have comments for us?
>
> On Tuesday, May 5, 2020 at 1:17:52 PM UTC-7 Charlie Engelke wrote:
>
>> I'd still like to here anyone's stories involving migrating their App 
>> Engine apps from Python 2.7 to Python 3.7. Have you migrated yet? Planning 
>> to do so soon? Not going to move to the new platform?
>>
>> And any particular pain points? Things that would have helped? 
>>
>> Thanks,
>>
>> Charlie
>>
>> On Friday, May 1, 2020 at 2:18:33 PM UTC-7 Charlie Engelke wrote:
>>
>>> Have you recently migrated from App Engine for Python 2.7 to App Engine 
>>> for Python 3.7? Are you working on migrating now, or planning to soon? Or 
>>> maybe you are using App Engine for Python 2.7 and aren't planning such a 
>>> migration.
>>>
>>> In each of those cases, I'd like to hear how things went or are going 
>>> for you, pain points you encounter, things that went easily, and anything 
>>> else you have to share. I'm working on creating some new code samples to 
>>> help with this, and your stories will be a big help.
>>>
>>> Thanks,
>>>
>>> Charlie
>>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/5c75e080-b0d9-48da-832e-60b69daefcd1%40googlegroups.com.

[google-appengine] Re: Cloud Datastore Emulator support?

[Ryan B]

hi again, jon! silly question, but are you also overriding tearDown() and 
calling self.ndb_context.__exit__(None, None, None) there? if not, i wonder 
if all of the previous tests' contexts are holding onto open connections to 
the datastore emulator and exhausting a connection pool somewhere. seems 
unlikely, but maybe possible.

On Wednesday, March 4, 2020 at 2:42:14 PM UTC-8, Jon Grover wrote:
>
> First, my apologies: I realize this is a bit off-topic. I'm running into a 
> mysterious issue w/ the Cloud Datastore Emulator during a migration from 
> NDB to Cloud NDB. I don't think the issue is related to Cloud NDB in 
> particular, but I'm not sure where to turn for help. I posted a more 
> detailed description in the Google Cloud Datastore Googlegroup here 
> , 
> but it appears to be much less active than this group.
>
> The nutshell version is that I am calling 
> *requests.post('http://localhost:8089/reset 
> ') *in the setUp() method for each of my 
> tests which involve NDB in order to clear the datastore . This works when I 
> run any one test file individually, but when I try to run our full test 
> suite of 580 tests we start seeing an error about halfway through. The 
> error indicates that it wasn't able to create any new connections to the 
> URL, and once it first appears all subsequent tests fail with the same 
> error. 
>
> Traceback (most recent call last):
>   File "test/my_test.py", line 11, in setUp
>   File "/Projects/tilegames/test/_base_test.py", line 50, in setUp
>   File "/Projects/tilegames/lib/requests/api.py", line 119, in post
>   File "/Projects/tilegames/lib/requests/api.py", line 61, in request
>   File "/Projects/tilegames/lib/requests/sessions.py", line 530, in 
> request
>   File "/Projects/tilegames/lib/requests/sessions.py", line 643, in send
>   File "/Projects/tilegames/lib/requests/adapters.py", line 516, in send
> ConnectionError: HTTPConnectionPool(host='localhost', port=8089): Max 
> retries exceeded with url: /reset (Caused by 
> NewConnectionError(' object at 0x11286e590>: Failed to establish a new connection: [Errno 8] 
> nodename nor servname provided, or not known',))
>
> My initial efforts to troubleshoot what's going on here have all failed 
> and I'm not sure where the best place is to turn for support. I suppose 
> Stack Overflow is always an option. Anyone here have thoughts?
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/8e9377ed-8b0a-4837-9b65-ccea73f8da3a%40googlegroups.com.

Re: [google-appengine] Re: Cloud NDB is now GA

[Ryan B]

On Sunday, March 1, 2020 at 2:44:04 PM UTC-8, Jon Grover wrote:
>
> I've found that entering/exiting context in the setUp/tearDown methods (as 
> you do in your example) is adding about 0.7s to each of my tests, so I'm 
> wondering how you're able to do 500 tests in 52s (works out to 0.1s per 
> test). Perhaps it's machine dependent; I'm running these tests on a 2015 
> MacBook Pro, so maybe they'd be faster on something newer.
>

hmm! i'm actually on a 2014 MBP, so i doubt it's your hardware. feel free 
to poke at that repo, stack, and test suite if you want to see if you can 
find a difference. all of the tests use that base HandlerTest class, 
unittest, and mox3.

 

> On Saturday, February 29, 2020 at 8:22:35 PM UTC-8, Ryan B wrote:
>>
>> the datastore emulator is indeed slower than testbed for unit tests, but 
>> just as another data point, it's not way too slow for me. i routinely use 
>> it as part of my edit/compile/test loop on an app with a cumulative total 
>> of >1600 tests. around 500 of them use the datastore heavily, and running 
>> just those tests takes ~52s. not fast, but manageable, especially when i 
>> iterate on just a few relevant tests, and then expand to all of them before 
>> committing.
>>
>> also, you don't have to entirely tear down and restart the emulator just 
>> to clear its data between tests. just POST to http://localhost:8089/reset 
>> (or whichever port you run the emulator on). example: 
>> https://github.com/snarfed/bridgy/blob/master/tests/testutil.py#L282-L289
>>
>>
>> On Monday, February 24, 2020 at 1:05:33 PM UTC-8, Remko Tronçon wrote:
>>>
>>> On Monday, February 24, 2020 at 9:52:25 PM UTC+1, Andrew Gorcester 
>>> wrote: 
>>> > Cloud NDB is compatible with the Cloud Datastore Emulator; we 
>>> recommend tests be done using that, the same way on Cloud NDB as they would 
>>> be with the Cloud Datastore library. 
>>>
>>> Using an external emulator is way too slow to use for unit tests, even 
>>> if you are able to get all your code changed so you don’ have to tear down 
>>> and clean start the emulator to avoid interference between tests. This is 
>>> pretty disappointing, and means I (and I expect many others) will be forced 
>>> to rewrite everything if your app isn’t in pure maintenance mode. 
>>>
>>> Remko 
>>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/9b06feba-3fc3-49eb-aba9-4d5923087a80%40googlegroups.com.

Re: [google-appengine] Re: Cloud NDB is now GA

[Ryan B]

the datastore emulator is indeed slower than testbed for unit tests, but 
just as another data point, it's not way too slow for me. i routinely use 
it as part of my edit/compile/test loop on an app with a cumulative total 
of >1600 tests. around 500 of them use the datastore heavily, and running 
just those tests takes ~52s. not fast, but manageable, especially when i 
iterate on just a few relevant tests, and then expand to all of them before 
committing.

also, you don't have to entirely tear down and restart the emulator just to 
clear its data between tests. just POST to http://localhost:8089/reset (or 
whichever port you run the emulator on). example: 
https://github.com/snarfed/bridgy/blob/master/tests/testutil.py#L282-L289


On Monday, February 24, 2020 at 1:05:33 PM UTC-8, Remko Tronçon wrote:
>
> On Monday, February 24, 2020 at 9:52:25 PM UTC+1, Andrew Gorcester wrote: 
> > Cloud NDB is compatible with the Cloud Datastore Emulator; we recommend 
> tests be done using that, the same way on Cloud NDB as they would be with 
> the Cloud Datastore library. 
>
> Using an external emulator is way too slow to use for unit tests, even if 
> you are able to get all your code changed so you don’ have to tear down and 
> clean start the emulator to avoid interference between tests. This is 
> pretty disappointing, and means I (and I expect many others) will be forced 
> to rewrite everything if your app isn’t in pure maintenance mode. 
>
> Remko 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/f7c51bc3-8ac4-4979-9de8-2932393c6fdf%40googlegroups.com.

[google-appengine] Re: Cloud NDB is now GA

[Ryan B]

congratulations andrew! and to chris, carlos, danny, and everyone else who 
built python 3 ndb. it's been a huge boon for migrating from appengine 
python 2 to python 3. we appreciate all the hard work you all put into it!

On Monday, February 24, 2020 at 11:02:36 AM UTC-8, Andrew Gorcester wrote:
>
> Hello Pythonistas,
>
>
> The Cloud NDB client library for Cloud Datastore and Cloud Firestore in 
> Datastore mode, previously introduced as a beta project in September 2019, 
> has been launched to GA with its 1.0 release.
>
>
> Cloud NDB is an updated version of the App Engine NDB client library for 
> Datastore, adding support for Python 3 and targeting the Datastore API. 
> While it is intended for users migrating from App Engine Python 2.7 to App 
> Engine Python 3, it is fully portable and compatible with other Python 
> platforms. The library can be installed with `pip install google-cloud-ndb` 
> and the source code can be found on Github at 
> https://github.com/googleapis/python-ndb.
>
>
> We also have a migration guide for NDB 
> 
>  
> at, as part of our broader GAE Python migration documentation 
> . 
> We'll continue updating and adding to this documentation and library as 
> part of our migration support effort, so please also continue sending us 
> your feedback.
>
>
> Thank you again for your continued support for App Engine and our Cloud 
> platform. I am looking forward to hearing feedback from the community on 
> this and upcoming efforts.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/d7adc2e4-0d1a-4fdf-9493-0f8d1ea58ba4%40googlegroups.com.

[google-appengine] Re: Google appengine free quota per application?

[Ryan B]

On Thursday, February 20, 2020 at 12:41:49 PM UTC-8, David (Cloud Platform 
Support) wrote:
>
>
> I would like to clarify this for you. Free quotas are per billing account 
> and not per application.
>
 
hi david! i know you're an official representative, but i don't think this 
is right. i have (and have always had) multiple apps serving under a single 
billing account, and each one gets the standard app engine free quota, eg 
28 frontend instance hours, etc.

...unless my account is grandfathered into some od plan that no longer 
applies to new accounts? that seems unlikely. 


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/2a762e1c-820f-42ec-be00-eff7817ac004%40googlegroups.com.

[google-appengine] Re: ndb to cloud ndb migration experience

[Ryan B]

hi jon!

On Tuesday, February 18, 2020 at 5:42:26 AM UTC-8, Jon Grover wrote:
>
> On Thursday, January 16, 2020 at 1:47:03 PM UTC-8, Ryan B wrote:
> 1) First and foremost, I had repeated issues with dev_appserver connecting 
> to my production datastore despite having set all the correct environment 
> variables and setting the --support_datastore_emulator flag. I was finally 
> able to solve it by explicitly passing *--env_var 
> DATASTORE_EMULATOR_HOST=localhost:8081*, but I'm not immediately sure how 
> to do that from within our unittest framework and I'm very worried about 
> our unit tests writing to the production datastore. (For the time being, I 
> used the gcloud CLI to change my project to a dummy one.)
>

yes! this one was/is disappointing. it's a hole in dev_appserver that most 
likely will never be closed, since dev_appserver itself is basically 
deprecated. i literally monkey patch the host/port into the ndb context 
manually: 
https://github.com/snarfed/webutil/blob/master/appengine_config.py#L39 . 
background: https://github.com/googleapis/python-ndb/issues/238
 
 

> 2) This is maybe my own unfamiliarity with NDB context, but I'm not sure 
> what the correct way is to use the same NDB context across all unit tests. 
> I borrowed your WSGI middleware trick for the app itself, but I haven't yet 
> quite figured out how to apply a single context across our entire unittest 
> suite. I tried creating a new NDB context in our base setUp method, which 
> looked like it was working but dragged the test speed to a crawl.
>

right! i do exactly that, and also reset the datastore and call 
__enter__(), and then __exit__() in tearDown: 
https://github.com/snarfed/bridgy/blob/master/tests/testutil.py#L282-L289

unit tests are definitely slower now with the emulator vs testbed in the 
python 2 runtime. one test suite of mine that does datastore operations in 
almost every test, often many per test, takes ~50s to run 526 tests. not 
great, but i usually iterate by running individual tests, so it doesn't 
hurt too much.

 
 

> Just curious if you had any additional insights or example code available. 
> I've already learned quite a bit by reading through your other postings, so 
> thanks regardless.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/86f581f9-886b-4cf9-8cc2-e07c76df07b5%40googlegroups.com.

[google-appengine] Re: No Cloud Tasks local emulator

[Ryan B]

On Friday, January 17, 2020 at 7:04:24 AM UTC-8, Aert van de Hulsbeek wrote:
>
>
> See if the emulator I built works for you: 
> https://github.com/aertje/cloud-tasks-emulator. It's pretty bare bones 
> but hopefully it helps. 
>
> Thanks for replying to my question re. the NDB migration btw!


oh wow, that's exciting! thanks for the nudge, and the kind words. i'll 
give it a shot. 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/2998b352-d516-487b-b69d-aeae2a33ace3%40googlegroups.com.

Re: [google-appengine] Python 3 standard environment data storage

[Ryan B]

On Friday, January 17, 2020 at 9:28:56 AM UTC-8, Joshua Smith wrote:
>
> That thing is invaluable when you have lots of apps. Is there something 
> similar for P3.7 that will send me exception summaries daily?
>
> I’m familiar with the “Cloud Console” phone app, which will do 
> notifications. But in my experience you can’t rely on that, because 
> sometimes it spontaneously stops notifying.
>

i've been using stackdriver error reporting 
 for this for a while, and it's 
great, and pretty automatic and built in. i don't think it does daily 
digest emails, but you can definitely have it email individual new errors 
when they first appear, or recur after closing them, and those emails have 
been very reliable in my experience.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/43b02b5f-3583-44b3-8f1b-9d1e28d45f87%40googlegroups.com.

Re: [google-appengine] Python 3 standard environment data storage

[Ryan B]

On Friday, January 17, 2020 at 8:42:11 AM UTC-8, Joshua Smith wrote:
>
> Running locally, I’m using this datastore emulator:
>
> https://cloud.google.com/datastore/docs/tools/datastore-emulator
>
> It works, but it is SOOO SLW. It takes literally 10-20 seconds to 
> respond to a simple query.
>

huh, that's surprising. just as a data point, i definitely don't see that 
behavior. i use the datastore emulator locally for both unit tests and 
interactive development, and it responds many orders of magnitude faster, 
as expected. for example, one project runs 524 unit tests in ~53s, many of 
which do multiple operations (both read and write) against the emulator.

i'm on mac os 10.15.2, gcloud 276.0.0, cloud-datastore-emulator 2.1.0, 
python 3.6.5.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/7d3216cc-15d6-48c5-989f-0f963c3b7e07%40googlegroups.com.

[google-appengine] Re: ndb to cloud ndb migration experience

[Ryan B]

i recently migrated a number of nontrivial apps from python 2 to python 3 
(standard). it wasn't easy, especially since i used a number of the old 
APIs - task queues, logging, memcache, ndb, etc - that have changed 
significantly or disappeared entirely. it took a significant amount of 
effort, coding, and workarounds, but it was doable in the end. kudos in 
particular to chris rossi, danny hermes, carlos de la guardia, et al for 
the new python 3 ndb library !

i've posted many of the bigger gotchas i hit here on this list 
,
 
and over 

 on 
SO , and on the python 3 ndb 
issue tracker 
.
 
beyond all those, two key things i ended up doing for ndb were:

* replace testbed 

 
with the datastore emulator 
 for 
running unit tests without mocking out ndb. example commands. 

* this WSGI middleware to run all HTTP request handlers inside an NDB 
client context. 
 
without it, i would have had to add a ton of ugly new with 
ndb_client.context(): ... blocks and indents everywhere.

also, shameless plug, feel free to test things out in shell-py3.appspot.com, 
an interactive REPL inside python 3 GAE standard that includes the new ndb.

On Wednesday, January 15, 2020 at 5:27:12 AM UTC-8, Aert van de Hulsbeek 
wrote:
>
> We are currently looking to migrate a reasonable number of gae std 
> services from py2 to py3 and are tossing up between a datastore or cloud 
> ndb implementation.
> Has anyone done a somewhat complex migration from ndb to cloud ndb and 
> what was this experience like? I am mainly interested in unforeseen and 
> undocumented gotcha's / blockers that might direct us down the datastore 
> path.
> If anyone can share some hands-on experience, that would be fantastic. 
> Thanks, Aert.
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/142c3da2-0871-43c1-be3c-0c7b6c0eb674%40googlegroups.com.

[google-appengine] server-side REPL shell for Python 3 Standard Environment

[Ryan B]

hi all! i've ported the venerable, old school server side shell app 
shell-hrd.appspot.com from Python 2 to 3: shell-py3.appspot.com. it's a 
full fledged, interactive Python REPL that runs its code server side inside 
the Python 3 Standard Environment. feel free to try it out!

in the process of porting a few nontrivial apps to Python 3, i regularly 
found myself asking how bits of the production runtime behaved. which 
directory on the filesystem is the virtualenv installed in? what do the 
app-default credentials look like, specifically? what are the WSGI (etc) 
environment variables set to?

one way to answer these is to add logging that prints them, deploy that 
code, run it, make a request, and look at the logs. that iteration cycle is 
pretty slow, though. using this shell is way faster.

it also includes a number of the new Google Cloud API libraries, including 
google.cloud.ndb, .logging, and .error_reporting, which has been useful for 
experimenting with them.

feedback is welcome!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/d2152351-0153-446e-980c-327181069bd5%40googlegroups.com.

[google-appengine] Re: GAE Standard | Local Dev | Python37: google.appengine.api not found

[Ryan B]

hi Yanay! the classic App Engine APIs in google.appengine.api aren't available 
in the Python 3 runtime. More details: 
https://cloud.google.com/appengine/docs/standard/python3/python-differences#app_engine_apis


On Sunday, November 24, 2019 at 6:08:57 PM UTC-8, Yanay Lehavi wrote:
>
> I see a number of threads on this in git etc. but they all seem unresolved:
>
> >>> import google.appengine.api
>
> Traceback (most recent call last):
>
>   File "", line 1, in 
>
> ModuleNotFoundError: No module named 'google'
>
> >>> 
>
> In the above mentioned threads, some people suggested various env vars, 
> none of which I have, nor ever needed... (been developing GAE locally for a 
> long time).
> My platform: Mac Catalina.
> Anyone knows how to resolve this?
> Many thanks
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/2fbbae44-76e6-4e28-9cc6-3c4bfe50f074%40googlegroups.com.

Re: [google-appengine] Python 3 local development: fast startup or static assets, choose one?

[Ryan B]

the patch below makes dev_appserver use an existing virtualenv instead of 
creating a new one from scratch each time. it applies cleanly against 
google cloud SDK 272.0.0, app-engine-python component 1.9.87. i'd happily 
add a command line flag and send a PR, but afaik the google cloud SDK isn't 
open source.

put it in a file named dev_appserver.virtualenv.diff, then apply it with:

patch /opt/homebrew-cask/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/
platform/google_appengine/google/appengine/tools/devappserver2/python/
instance_factory.py ~/dev_appserver.virtualenv.diff

that path is for Mac OS, for a google cloud SDK originally installed via 
homebrew. you may need to update it for your own environment. you'll also 
need to change 'local3' below in the patch to your own virtualenv's path, 
relative to the app root directory.

diff instance_factory.py.orig instance_factory.py
105,106c105
< if os.path.exists(venv_dir):
<   shutil.rmtree(venv_dir)
--
> pass
120,121c119,124
< self._CleanUpVenv(self._venv_dir)
< self._venv_dir = tempfile.mkdtemp()
--
> self._venv_dir = os.path.join(os.path.dirname(self.
_module_configuration.config_path), 'local3')
> self.venv_env_vars = {
> 'VIRTUAL_ENV': self._venv_dir,
> 'PATH': ':'.join([os.path.join(self._venv_dir, 'bin'), os.environ[
'PATH']])
> }
> return

i'd hoped to write a wrapper script with a monkey patch instead, so i 
wouldn't have to reapply the patch every time i upgrade gcloud, but 
dev_appserver goes through a couple layers of import bootstraps at startup, 
and it wasn't easy to inject the monkey patch at just the right time. ah 
well. fingers crossed for the feature request to add this officially. 
<https://issuetracker.google.com/issues/144150446>


On Friday, November 8, 2019 at 4:56:35 PM UTC-8, Ryan B wrote:
>
> The latest in the saga of using dev_appserver.py locally is that Python 3 
> ndb (aka google-cloud-ndb) doesn't support it. I've filed this bug report. 
> <https://github.com/googleapis/python-ndb/issues/238> Whee!
>
> On Friday, November 8, 2019 at 3:35:40 PM UTC-8, Andrew Gorcester wrote:
>>
>> That does make sense. If you could bridge the gap by using a single 
>> static file directory in app.yaml served with a single static_dir handler, 
>> that might work too. But I know some apps have very complex app.yaml 
>> defined static files, so I understand why you're looking at the 
>> dev_appserver.py option instead.
>>
>> On Fri, Nov 8, 2019 at 3:33 PM Ryan Barrett  wrote:
>>
>>> thanks for the reply!
>>>
>>> On Fri, Nov 8, 2019 at 2:40 PM 'Andrew Gorcester' via Google App Engine <
>>> google-a...@googlegroups.com> wrote:
>>>
>>>> I would recommend trying to solve the first problem and serving static 
>>>> files locally.
>>>>
>>>
>>> understood, but using a different static file server is not great. it 
>>> makes local development diverge significantly from production. local no 
>>> longer uses or tests app.yaml's static file handlers, but prod does, so 
>>> bugs will eventually pop up that only happen in production, and are thus 
>>> harder to test for and debug.
>>>
>>> for that reason, i'm actually going the other way and using 
>>> dev_appserver right now, soi still have some confidence that my app will 
>>> behave more or less the same in production that it does locally. the minute 
>>> long delay on startup is definitely painful though.
>>>
>>>
>>> At first glance I think the most straightforward ways to do that would 
>>>> be to either:
>>>>
>>>> - Use the Flask development server instead of gunicorn and leverage 
>>>> Flask's integrated /static directory 
>>>> https://flask.palletsprojects.com/en/1.1.x/tutorial/static/
>>>> - If you prefer to use gunicorn or you need more serving options, add 
>>>> WhiteNoise middleware to your app; ideally, have your app detect whether 
>>>> it's running in production or in development mode and conditionally add 
>>>> WhiteNoise in development only: http://whitenoise.evans.io/en/stable/
>>>>
>>>>
>>>> On Fri, Nov 8, 2019 at 2:21 PM Ryan B  wrote:
>>>>
>>>>> Hi all! My Python 3 topic for the day is local development. How are 
>>>>> you all doing it? Any tips?
>>>>>
>>>>> The two main ways seem to be a third party server, eg Flask or 
>>>>> Gunicorn, or dev_appserver.py. I have both working, but each one has 
>>>>> a fatal flaw that makes it basically unusable for me so far

Re: [google-appengine] Python 3 local development: fast startup or static assets, choose one?

[Ryan B]

The latest in the saga of using dev_appserver.py locally is that Python 3 
ndb (aka google-cloud-ndb) doesn't support it. I've filed this bug report. 
<https://github.com/googleapis/python-ndb/issues/238> Whee!

On Friday, November 8, 2019 at 3:35:40 PM UTC-8, Andrew Gorcester wrote:
>
> That does make sense. If you could bridge the gap by using a single static 
> file directory in app.yaml served with a single static_dir handler, that 
> might work too. But I know some apps have very complex app.yaml defined 
> static files, so I understand why you're looking at the dev_appserver.py 
> option instead.
>
> On Fri, Nov 8, 2019 at 3:33 PM Ryan Barrett  > wrote:
>
>> thanks for the reply!
>>
>> On Fri, Nov 8, 2019 at 2:40 PM 'Andrew Gorcester' via Google App Engine <
>> google-a...@googlegroups.com > wrote:
>>
>>> I would recommend trying to solve the first problem and serving static 
>>> files locally.
>>>
>>
>> understood, but using a different static file server is not great. it 
>> makes local development diverge significantly from production. local no 
>> longer uses or tests app.yaml's static file handlers, but prod does, so 
>> bugs will eventually pop up that only happen in production, and are thus 
>> harder to test for and debug.
>>
>> for that reason, i'm actually going the other way and using dev_appserver 
>> right now, soi still have some confidence that my app will behave more or 
>> less the same in production that it does locally. the minute long delay on 
>> startup is definitely painful though.
>>
>>
>> At first glance I think the most straightforward ways to do that would be 
>>> to either:
>>>
>>> - Use the Flask development server instead of gunicorn and leverage 
>>> Flask's integrated /static directory 
>>> https://flask.palletsprojects.com/en/1.1.x/tutorial/static/
>>> - If you prefer to use gunicorn or you need more serving options, add 
>>> WhiteNoise middleware to your app; ideally, have your app detect whether 
>>> it's running in production or in development mode and conditionally add 
>>> WhiteNoise in development only: http://whitenoise.evans.io/en/stable/
>>>
>>>
>>> On Fri, Nov 8, 2019 at 2:21 PM Ryan B > 
>>> wrote:
>>>
>>>> Hi all! My Python 3 topic for the day is local development. How are you 
>>>> all doing it? Any tips?
>>>>
>>>> The two main ways seem to be a third party server, eg Flask or 
>>>> Gunicorn, or dev_appserver.py. I have both working, but each one has a 
>>>> fatal flaw that makes it basically unusable for me so far.
>>>>
>>>> When I run my app with eg gunicorn -b :8080 app:application - the way 
>>>> Google recommends 
>>>> <https://cloud.google.com/appengine/docs/standard/python3/testing-and-deploying-your-app#running_locally>
>>>>  
>>>> - it works, but doesn't serve any assets from static file handlers in my 
>>>> app.yaml. This is widely reported on StackOverflow 
>>>> <https://stackoverflow.com/search?q=%5Bgoogle-app-engine%5D+%5Bpython-3.x%5D+static>
>>>>  
>>>> and elsewhere. Responses are often some variation of, "why do you need 
>>>> static assets for dynamic requests?" The obvious reason is that pretty 
>>>> much 
>>>> all webapps use images, CSS, and/or JS, among other static files. They're 
>>>> generally not usable without those assets.
>>>>
>>>> When I run my app with  dev_appserver.py, it creates a new virtualenv 
>>>> and installs all of my dependencies from requirements.txt. This is 
>>>> nice, but also extremely slow for any nontrivial app. My current medium 
>>>> sized app has 155 packages, and even when they're all cached locally, 
>>>> installing them takes around 60s. I often switch between different apps 
>>>> and 
>>>> other stacks, so I can't often keep dev_appserver running for hours or 
>>>> days 
>>>> on end to avoid this. (I've filed this feature request for 
>>>> dev_appserver to reuse an existing virtualenv. 
>>>> <https://issuetracker.google.com/u/1/issues/144150446>)
>>>>
>>>> Let me know if you have any ideas!
>>>>
>>>> -- 
>>>> 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 
>>

Re: [google-appengine] Python 3 local development: fast startup or static assets, choose one?

[Ryan Barrett]

thanks for the reply!

On Fri, Nov 8, 2019 at 2:40 PM 'Andrew Gorcester' via Google App Engine <
google-appengine@googlegroups.com> wrote:

> I would recommend trying to solve the first problem and serving static
> files locally.
>

understood, but using a different static file server is not great. it makes
local development diverge significantly from production. local no longer
uses or tests app.yaml's static file handlers, but prod does, so bugs will
eventually pop up that only happen in production, and are thus harder to
test for and debug.

for that reason, i'm actually going the other way and using dev_appserver
right now, soi still have some confidence that my app will behave more or
less the same in production that it does locally. the minute long delay on
startup is definitely painful though.


At first glance I think the most straightforward ways to do that would be
> to either:
>
> - Use the Flask development server instead of gunicorn and leverage
> Flask's integrated /static directory
> https://flask.palletsprojects.com/en/1.1.x/tutorial/static/
> - If you prefer to use gunicorn or you need more serving options, add
> WhiteNoise middleware to your app; ideally, have your app detect whether
> it's running in production or in development mode and conditionally add
> WhiteNoise in development only: http://whitenoise.evans.io/en/stable/
>
>
> On Fri, Nov 8, 2019 at 2:21 PM Ryan B  wrote:
>
>> Hi all! My Python 3 topic for the day is local development. How are you
>> all doing it? Any tips?
>>
>> The two main ways seem to be a third party server, eg Flask or Gunicorn,
>> or dev_appserver.py. I have both working, but each one has a fatal flaw
>> that makes it basically unusable for me so far.
>>
>> When I run my app with eg gunicorn -b :8080 app:application - the way
>> Google recommends
>> <https://cloud.google.com/appengine/docs/standard/python3/testing-and-deploying-your-app#running_locally>
>> - it works, but doesn't serve any assets from static file handlers in my
>> app.yaml. This is widely reported on StackOverflow
>> <https://stackoverflow.com/search?q=%5Bgoogle-app-engine%5D+%5Bpython-3.x%5D+static>
>> and elsewhere. Responses are often some variation of, "why do you need
>> static assets for dynamic requests?" The obvious reason is that pretty much
>> all webapps use images, CSS, and/or JS, among other static files. They're
>> generally not usable without those assets.
>>
>> When I run my app with  dev_appserver.py, it creates a new virtualenv
>> and installs all of my dependencies from requirements.txt. This is nice,
>> but also extremely slow for any nontrivial app. My current medium sized app
>> has 155 packages, and even when they're all cached locally, installing them
>> takes around 60s. I often switch between different apps and other stacks,
>> so I can't often keep dev_appserver running for hours or days on end to
>> avoid this. (I've filed this feature request for dev_appserver to reuse
>> an existing virtualenv.
>> <https://issuetracker.google.com/u/1/issues/144150446>)
>>
>> Let me know if you have any ideas!
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-appengine/eff3cf33-3a7b-4cc4-8b8c-2a46b2c56c45%40googlegroups.com
>> <https://groups.google.com/d/msgid/google-appengine/eff3cf33-3a7b-4cc4-8b8c-2a46b2c56c45%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google App Engine" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-appengine/BJDE8y2KISM/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-appengine+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/CANtYgF%2BPRh3vU%3Dpp3708sRAFE8%2BYxC%3Dm%2BmC8oGVqHyLw3yKBhw%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-appengine/CANtYgF%2BPRh3vU%3Dpp3708sRAFE8%2BYxC%3Dm%2BmC8oGVqHyLw3yKBhw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
https://snarfed.org/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CA%2BcaGh-8rd4NVj2HmcS0t0PRAAJ%2BiWo3huzjXcbJSDxyJtsAPw%40mail.gmail.com.

[google-appengine] Python 3 local development: fast startup or static assets, choose one?

[Ryan B]

Hi all! My Python 3 topic for the day is local development. How are you all 
doing it? Any tips?

The two main ways seem to be a third party server, eg Flask or Gunicorn, or 
dev_appserver.py. I have both working, but each one has a fatal flaw that 
makes it basically unusable for me so far.

When I run my app with eg gunicorn -b :8080 app:application - the way 
Google recommends 

 
- it works, but doesn't serve any assets from static file handlers in my 
app.yaml. This is widely reported on StackOverflow 

 
and elsewhere. Responses are often some variation of, "why do you need 
static assets for dynamic requests?" The obvious reason is that pretty much 
all webapps use images, CSS, and/or JS, among other static files. They're 
generally not usable without those assets.

When I run my app with  dev_appserver.py, it creates a new virtualenv and 
installs all of my dependencies from requirements.txt. This is nice, but 
also extremely slow for any nontrivial app. My current medium sized app has 
155 packages, and even when they're all cached locally, installing them 
takes around 60s. I often switch between different apps and other stacks, 
so I can't often keep dev_appserver running for hours or days on end to 
avoid this. (I've filed this feature request for dev_appserver to reuse an 
existing virtualenv. )

Let me know if you have any ideas!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/eff3cf33-3a7b-4cc4-8b8c-2a46b2c56c45%40googlegroups.com.

Re: [google-appengine] Python 3: how to deserialize App Engine application logs from StackDriver Logging API?

[Ryan B]

thanks guys! as mentioned, LogEntry.to_api_repr() is currently broken for 
this use case with the latest version of google-cloud-logging, 1.14.0. i've 
posted details on 
https://github.com/googleapis/google-cloud-python/issues/2572#issuecomment-551199704
 
(which is unfortunately closed right now).

On Thursday, November 7, 2019 at 10:56:53 AM UTC-8, Dustin Ingram wrote:
>
> You can use the LogEntry.to_api_repr() 
> <https://googleapis.dev/python/logging/latest/entries.html#google.cloud.logging.entries.LogEntry.to_api_repr>
>  
> function to get a JSON version of the LogEntry.
>
> On Thu, Nov 7, 2019 at 9:36 AM Ryan B > 
> wrote:
>
>> Hi again! As part of migrating to Python 3, I need to migrate from 
>> logservice 
>> <https://cloud.google.com/appengine/docs/standard/python/refdocs/google.appengine.api.logservice.logservice>
>>  
>> to the StackDriver Logging API 
>> <https://cloud.google.com/logging/docs/reference/api-overview>. I have 
>> google-cloud-logging <https://pypi.org/project/google-cloud-logging/> 
>> installed, and I can successfully fetch GAE application logs with eg:
>>
>> >>> from google.cloud.logging_v2 import LoggingServiceV2Client
>> >>> entries = LoggingServiceV2Client().list_log_entries((
>> 'projects/brid-gy',),
>>  filter_='resource.type="gae_app" AND protoPayload.@type="
>> type.googleapis.com/google.appengine.logging.v1.RequestLog"')
>> >>> print(next(iter(entries)))
>> proto_payload {
>>   type_url: "type.googleapis.com/google.appengine.logging.v1.RequestLog"
>>   value: "\n\ts~brid-gy\022\0018\032R5d..."
>> }
>> ...
>>
>> This gets me a LogEntry with text application logs in the 
>> proto_payload.value field. How do I deserialize that field? I've found 
>> lots of related mentions in the docs - links below - but nothing pointing 
>> me to a google.appengine.logging.v1.RequestLog protobuf generated class 
>> anywhere that I can use, if that's even the right idea. Has anyone done 
>> this?
>>
>>
>> https://googleapis.dev/python/logging/latest/gapic/v2/types.html#google.cloud.logging_v2.types.LogEntry.proto_payload
>>
>> https://cloud.google.com/logging/docs/reference/v2/rpc/google.appengine.logging.v1#requestlog
>>
>> https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.proto_payload
>>
>> https://cloud.google.com/logging/docs/api/v2/resource-list#resource-indexes
>> https://groups.google.com/d/topic/google-cloud-dev/Xr6tZxOIaJY/discussion
>>
>> -- 
>> 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-a...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-appengine/a6665355-a7e6-42d4-96c2-82090d457adf%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/google-appengine/a6665355-a7e6-42d4-96c2-82090d457adf%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/4fc5946c-5e8e-4d86-b30f-98575508e4b4%40googlegroups.com.

[google-appengine] Re: Python 3: how to deserialize App Engine application logs from StackDriver Logging API?

[Ryan B]

Interesting. Dustin Ingram (Google DevRel) copied this question to 
StackOverflow 
<https://stackoverflow.com/questions/58753378/how-to-deserialize-app-engine-application-logs-from-stackdriver-logging-api>,
 
and answered it there, but not here. Is that standard for this group?

In any case, thanks Dustin! Except your answer 
<https://stackoverflow.com/a/58753379/186123> to switch to the v1 
StackDriver Logging API and use LogEntry.to_api_repr() doesn't work for me. 
I get:

Traceback (most recent call last):
  File "", line 1, in 
  File 
"/Users/ryan/src/bridgy/local/lib/python2.7/site-packages/google/cloud/logging/entries.py"
, line 357, in to_api_repr
info["protoPayload"] = MessageToDict(self.payload)
  File 
"/Users/ryan/src/bridgy/local/lib/python2.7/site-packages/google/protobuf/json_format.py"
, line 168, in MessageToDict
return printer._MessageToJsonObject(message)
  File 
"/Users/ryan/src/bridgy/local/lib/python2.7/site-packages/google/protobuf/json_format.py"
, line 202, in _MessageToJsonObject
return methodcaller(_WKTJSONMETHODS[full_name][0], message)(self)
  File 
"/Users/ryan/src/bridgy/local/lib/python2.7/site-packages/google/protobuf/json_format.py"
, line 314, in _AnyMessageToJsonObject
sub_message = _CreateMessageFromTypeUrl(type_url, self.descriptor_pool)
  File 
"/Users/ryan/src/bridgy/local/lib/python2.7/site-packages/google/protobuf/json_format.py"
, line 389, in _CreateMessageFromTypeUrl
'Can not find message descriptor by type_url: {0}.'.format(type_url))
TypeError: Can not find message descriptor by type_url: type.googleapis.com/
google.appengine.logging.v1.RequestLog.

Searching turns up a few GitHub issues showing that people maintaining 
Google Cloud Python libraries have struggled with this for years. I got 
lost in them and haven't yet managed to find a conclusion:

https://github.com/googleapis/google-cloud-python/issues/2572
https://github.com/googleapis/google-cloud-python/issues/2674
etc.

In case it helps, here are the relevant packages I have installed in my 
virtualenv:

google-api-core1.14.3
google-api-python-client   1.7.11
google-auth1.6.3
google-auth-httplib2   0.0.3
google-cloud-core  1.0.3
google-cloud-logging   1.14.0
googleapis-common-protos   1.6.0
oauth2client   4.1.3


On Thursday, November 7, 2019 at 7:34:42 AM UTC-8, Ryan B wrote:
>
> Hi again! As part of migrating to Python 3, I need to migrate from 
> logservice 
> <https://cloud.google.com/appengine/docs/standard/python/refdocs/google.appengine.api.logservice.logservice>
>  
> to the StackDriver Logging API 
> <https://cloud.google.com/logging/docs/reference/api-overview>. I have 
> google-cloud-logging <https://pypi.org/project/google-cloud-logging/> 
> installed, and I can successfully fetch GAE application logs with eg:
>
> >>> from google.cloud.logging_v2 import LoggingServiceV2Client
> >>> entries = LoggingServiceV2Client().list_log_entries((
> 'projects/brid-gy',),
>  filter_='resource.type="gae_app" AND protoPayload.@type="
> type.googleapis.com/google.appengine.logging.v1.RequestLog"')
> >>> print(next(iter(entries)))
> proto_payload {
>   type_url: "type.googleapis.com/google.appengine.logging.v1.RequestLog"
>   value: "\n\ts~brid-gy\022\0018\032R5d..."
> }
> ...
>
> This gets me a LogEntry with text application logs in the 
> proto_payload.value field. How do I deserialize that field? I've found 
> lots of related mentions in the docs - links below - but nothing pointing 
> me to a google.appengine.logging.v1.RequestLog protobuf generated class 
> anywhere that I can use, if that's even the right idea. Has anyone done 
> this?
>
>
> https://googleapis.dev/python/logging/latest/gapic/v2/types.html#google.cloud.logging_v2.types.LogEntry.proto_payload
>
> https://cloud.google.com/logging/docs/reference/v2/rpc/google.appengine.logging.v1#requestlog
>
> https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.proto_payload
> https://cloud.google.com/logging/docs/api/v2/resource-list#resource-indexes
> https://groups.google.com/d/topic/google-cloud-dev/Xr6tZxOIaJY/discussion
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/c28a02dc-b15a-4ff6-9771-023bae2b4e80%40googlegroups.com.

[google-appengine] Python 3: how to deserialize App Engine application logs from StackDriver Logging API?

[Ryan B]

Hi again! As part of migrating to Python 3, I need to migrate from 
logservice 

 
to the StackDriver Logging API 
. I have 
google-cloud-logging  
installed, and I can successfully fetch GAE application logs with eg:

>>> from google.cloud.logging_v2 import LoggingServiceV2Client
>>> entries = LoggingServiceV2Client().list_log_entries(('projects/brid-gy'
,),
 filter_='resource.type="gae_app" AND 
protoPayload.@type="type.googleapis.com/google.appengine.logging.v1.RequestLog"'
)
>>> print(next(iter(entries)))
proto_payload {
  type_url: "type.googleapis.com/google.appengine.logging.v1.RequestLog"
  value: "\n\ts~brid-gy\022\0018\032R5d..."
}
...

This gets me a LogEntry with text application logs in the 
proto_payload.value field. How do I deserialize that field? I've found lots 
of related mentions in the docs - links below - but nothing pointing me to 
a google.appengine.logging.v1.RequestLog protobuf generated class anywhere 
that I can use, if that's even the right idea. Has anyone done this?

https://googleapis.dev/python/logging/latest/gapic/v2/types.html#google.cloud.logging_v2.types.LogEntry.proto_payload
https://cloud.google.com/logging/docs/reference/v2/rpc/google.appengine.logging.v1#requestlog
https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#FIELDS.proto_payload
https://cloud.google.com/logging/docs/api/v2/resource-list#resource-indexes
https://groups.google.com/d/topic/google-cloud-dev/Xr6tZxOIaJY/discussion

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/a6665355-a7e6-42d4-96c2-82090d457adf%40googlegroups.com.

[google-appengine] Re: Python 3: how to determine the current app's project id?

[Ryan B]

ah, found it. looks like it's GAE_APPLICATION: 
https://cloud.google.com/appengine/docs/standard/python3/runtime#environment_variables

might be worth adding to the differences page 
<https://cloud.google.com/appengine/docs/standard/python3/python-differences>
!

On Wednesday, November 6, 2019 at 7:11:14 AM UTC-8, Ryan B wrote:
>
> Hi all! In the Python 2 runtime, I can use the app_identity API 
> <https://cloud.google.com/appengine/docs/standard/python/appidentity/> to 
> determine the current app's project id (ie application id) with 
> app_identity.get_application_id(). Anyone know how to do this in the 
> Python 3 runtime? 
> https://cloud.google.com/appengine/docs/standard/python3/python-differences#app_engine_apis
>  
> doesn't mention the app_identity API, and 
> https://cloud.google.com/appengine/docs/standard/python3/python-differences#modules
>  
> doesn't mention project id.
>
> Thanks in advance!
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/07d5e8e9-b601-467a-86e2-e18499196041%40googlegroups.com.

[google-appengine] Python 3: how to determine the current app's project id?

[Ryan B]

Hi all! In the Python 2 runtime, I can use the app_identity API 
 to 
determine the current app's project id (ie application id) with 
app_identity.get_application_id(). Anyone know how to do this in the Python 
3 runtime? 
https://cloud.google.com/appengine/docs/standard/python3/python-differences#app_engine_apis
 
doesn't mention the app_identity API, and 
https://cloud.google.com/appengine/docs/standard/python3/python-differences#modules
 
doesn't mention project id.

Thanks in advance!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/969a7b5d-ba89-4b31-9d06-724ce3a5597a%40googlegroups.com.

[google-appengine] No Cloud Tasks local emulator

[Ryan B]

I have a bunch of small apps on App Engine Standard, on the old generation 
Python 2 runtime. I'm itching to migrate to Python 3 Standard, but I use 
many of the classic App Engine APIs - datastore via ndb, task queues, 
memcache, etc - which are difficult to migrate away from 

.

Tasks is one of the biggest current blockers. I'd happily switch to Cloud 
Tasks, but it has no local emulator, which makes local development and unit 
testing difficult at best. I've starred the issue. 
 Any news on if/when we 
can expect an emulator? (I'd ask on the Cloud tasks mailing list 
, but it requires 
approval to join.)

More broadly, the writing is on the wall. App Engine's future is 
serverless, containerized, and decoupled from services like datastore, task 
management, in-memory caches, etc. Flexible got there first, Standard's new 
generation of runtimes (Python 3 etc) followed.

Other forum members have already written eloquently about this here (see GAE 
APIs 
, 
The end of PaaS? 
), 
so I won't recap their concerns. Personally, I'm ok with this decoupling 
roadmap. I even trust that you all will gradually fill in our migration 
path. And I know Python 2 isn't going EOL anytime soon. I'm just impatient 
to get onto Python 3, so I'm chafing at blockers like Cloud Tasks' lack of 
an emulator.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/b674ef4b-351b-49e8-9e2c-0ca0f61cb47d%40googlegroups.com.

[google-appengine] Re: webapp2 based web application development, add social login

[Ryan B]

harmit is right, but at a fairly low level. i've encapsulated the oauth 
implementations for lots of existing social sites and integrated them with 
app engine in the oauth-dropins package. feel free to try it out: 
https://oauth-dropins.appspot.com/ . if you like it, you can pip install it 
into your app's virtualenv and use it from there. more details in the docs: 
https://oauth-dropins.readthedocs.io/

On Monday, July 8, 2019 at 11:59:51 AM UTC-7, Harmit Rishi (Cloud Platform 
Support) wrote:
>
> Hello, 
>
> Thank you for using Google Groups!
>
> Based on my understanding of what you have described, you can implement 
> OAuth within Google App engine. You may find further details of this here 
> .
>  
>
>
> However, I was able to find *StackOverflow* threads that revolve around 
> this issue with Webapp2. In regards to specific social logins, I was able 
> to find the following thread here 
> 
>  that 
> discusses how to integrate Facebook login within App Engine. Though, I 
> believe it would be worthwhile for you to check out the discussion here 
> 
>  as 
> the entire thread discusses "Webapp2 Authentication and Login". 
> Additionally, there is a third party boilerplate provided by the community 
> on that thread for what you are attempting to do. You may feel free to 
> explore the links shared to determine if the ideas discussed in them would 
> be applicable in your use case.
>
> I hope this helps!
>
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/00426117-a13e-4396-813a-b4e4190550b8%40googlegroups.com.

[google-appengine] gcloud 238.0.0 broke dev_appserver.py on Mac OS X

[Ryan B]

hi all! looks like gcloud 238.0.0 + app-engine-python 1.9.84 and later 
broke dev_appserver.py on Mac OS X, at least when using 
google.appengine.ext.vendor to load libraries from a virtualenv. (i expect 
that's many/most of us. :P)

stack trace and SO questions below. any chance this will be fixed in gcloud 
241.0.0? thanks in advance!

https://stackoverflow.com/questions/55166959/osx-dev-appserver-py-file-not-accessible-system-library-coreservices-systemve
https://stackoverflow.com/questions/55151062/gcloud-update-broke-my-app-gcp-python-2-7

Traceback (most recent call last):
  ...
  File 
"/Users/ryan/src/granary/local/lib/python2.7/site-packages/pkg_resources/__init__.py",
 
line 951, in 
class Environment(object):
  File 
"/Users/ryan/src/granary/local/lib/python2.7/site-packages/pkg_resources/__init__.py",
 
line 955, in Environment
self, search_path=None, platform=get_supported_platform(),
  File 
"/Users/ryan/src/granary/local/lib/python2.7/site-packages/pkg_resources/__init__.py",
 
line 180, in get_supported_platform
plat = get_build_platform()
  File 
"/Users/ryan/src/granary/local/lib/python2.7/site-packages/pkg_resources/__init__.py",
 
line 389, in get_build_platform
version = _macosx_vers()
  File 
"/Users/ryan/src/granary/local/lib/python2.7/site-packages/pkg_resources/__init__.py",
 
line 356, in _macosx_vers
version = platform.mac_ver()[0]
  File 
"/usr/local/Cellar/python@2/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/platform.py",
 
line 764, in mac_ver
info = _mac_ver_xml()
  File 
"/usr/local/Cellar/python@2/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/platform.py",
 
line 741, in _mac_ver_xml
pl = plistlib.readPlist(fn)
  File 
"/usr/local/Cellar/python@2/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plistlib.py",
 
line 75, in readPlist
pathOrFile = open(pathOrFile)
  File 
"/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/python/runtime/stubs.py",
 
line 283, in __init__
raise IOError(errno.EACCES, 'file not accessible', filename)
IOError: [Errno 13] file not accessible: 
'/System/Library/CoreServices/SystemVersion.plist'



-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/8099b259-f961-4b04-adc3-027e5e6e965f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: GAE APIs

[Ryan B]

this is the existential question facing app engine's 
glacier-under-the-surface installed base of python 2 apps. the writing 
seems to be on the wall for the legacy, custom app engine python APIs; all 
signs point to the decoupled, REST-based APIs to standalone services 
(datastore, cloud tasks, etc) as the future.

you're right, though, we still haven't heard a migration path for long time 
users like us with existing python codebases that use the old APIs. word on 
the street seems to be that google knows this, and has been thinking about 
an answer for a while. one obvious reason is that there are plenty of big 
whale app engine customers in the same boat as us (ahem 
) who presumably have more leverage.

i have no inside knowledge, but my bet is that we'll get some form of 
compatibility layer, either porting (most) old libraries to use the new 
REST APIs under the hood, and/or (less likely) a code transformation tool 
like python's 2to3. i doubt either one would handle 100% of existing code, 
but if they hit 80% or 90%, i expect they'd declare victory. here's hoping!

On Monday, January 28, 2019 at 1:54:49 AM UTC-8, Joshua Fox wrote:
>
> Are there end-of-life plans   for GAE APIs in GAE Standard Environment, as 
> indeed happened in Flexible Environment already?
>
> If so, what is the timeline?
>
> -- 
>  
>
> *JOSHUA FOX*
> Director, Software Architecture | Freightos
>
>
>
> *T (Israel): *+972-545691165 | *T (US)*:  +1-3123400953  
> Smooth shipping.
>
>
>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/561c5a7a-414b-4601-a680-4df119bd437d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: dev_appserver in 1.9.76 switched import resolution from relative to absolute?

[Ryan B]

thanks for the link, amit! that issue definitely looks related. this 
problem still happens for me on cloud SDK 220 + app-engine-python 1.9.77, 
so i may be seeing a different variation of that issue, since most people 
there say 220 fixed it for them. i've added a comment.


On Thursday, October 11, 2018 at 9:31:52 AM UTC-7, Amit (Google Cloud 
Support) wrote:
>
> Hello Ryan
>
> What is the current Google Cloud SDK version you are using? As of now current 
> version <https://cloud.google.com/sdk/docs/release-notes> for Google 
> Cloud SDK is [220.0.0]. We had a known issue [1] on version [219.0.1] in 
> dev_appserver with app-engine-python [1.9.76] which should be resolved in 
> the current version where the version of app-engine-python is [1.9.77]. I 
> would recommend to update your SDK version using this [2] command and try 
> again. If you still having this issue after upgrade and believe this could 
> be a bug, please create an issue in issuetracker 
> <https://cloud.google.com/support/docs/issue-trackers> with details 
> description of your issue and provide the output of this [3] command so 
> that we know more about your SDK.
>
> [1] https://issuetracker.google.com/117145272
>
> [2] gcloud components update
>
> [3] gcloud info --anonymize
>
>
> On Wednesday, October 10, 2018 at 6:51:57 PM UTC-4, Ryan B wrote:
>>
>> fwiw, i've deployed at least one of the affected apps since 
>> app-engine-python 1.9.76 was released, and it's still working fine, which 
>> implies that the prod runtime isn't similarly affected. (i did that deploy 
>> with gcloud sdk 218, purely out of superstition, but i didn't really expect 
>> it to matter much one way or the other.)
>>
>> On Wednesday, October 10, 2018 at 3:50:02 PM UTC-7, Ryan B wrote:
>>>
>>> hi all! i'm debugging a dev_appserver problem that seems to have been 
>>> introduced in google cloud sdk 219 / app-engine-python 1.9.76: imports are 
>>> now all resolved as absolute instead of relative. does that sound familiar?
>>>
>>> for example, i use the future library <http://python-future.org/> in 
>>> many of my apps, which has this line of code 
>>> <https://github.com/PythonCharmers/python-future/blob/fdd5eebe3aea61959533dbb722820fac7c5954ea/src/future/standard_library/__init__.py#L484>
>>> :
>>>
>>> import test
>>>
>>> on gcloud sdk 218 / app-engine-python 1.9.75 and before, this worked 
>>> fine. it resolved the import relative to the containing source file, in 
>>> local/lib/python2.7/site-packages/future/... , a virtualenv, which i 
>>> set up with vendor 
>>> <https://cloud.google.com/appengine/docs/standard/python/tools/using-libraries-python-27#vendoring>.
>>>  
>>> on 1.9.76, it changed to resolving absolute instead, so it imports an 
>>> unrelated test/ package directory in the top level of my app, which 
>>> obviously won't work, and the app breaks.
>>>
>>> i couldn't find any mention of this in release notes or docs. was this 
>>> expected? any recommendations for handling it? thanks in advance!
>>>
>>>
>>>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/043b9c9d-f2f4-4aec-91bb-e94dc9d090d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: dev_appserver in 1.9.76 switched import resolution from relative to absolute?

[Ryan B]

fwiw, i've deployed at least one of the affected apps since 
app-engine-python 1.9.76 was released, and it's still working fine, which 
implies that the prod runtime isn't similarly affected. (i did that deploy 
with gcloud sdk 218, purely out of superstition, but i didn't really expect 
it to matter much one way or the other.)

On Wednesday, October 10, 2018 at 3:50:02 PM UTC-7, Ryan B wrote:
>
> hi all! i'm debugging a dev_appserver problem that seems to have been 
> introduced in google cloud sdk 219 / app-engine-python 1.9.76: imports are 
> now all resolved as absolute instead of relative. does that sound familiar?
>
> for example, i use the future library <http://python-future.org/> in many 
> of my apps, which has this line of code 
> <https://github.com/PythonCharmers/python-future/blob/fdd5eebe3aea61959533dbb722820fac7c5954ea/src/future/standard_library/__init__.py#L484>
> :
>
> import test
>
> on gcloud sdk 218 / app-engine-python 1.9.75 and before, this worked fine. 
> it resolved the import relative to the containing source file, in 
> local/lib/python2.7/site-packages/future/... , a virtualenv, which i set 
> up with vendor 
> <https://cloud.google.com/appengine/docs/standard/python/tools/using-libraries-python-27#vendoring>.
>  
> on 1.9.76, it changed to resolving absolute instead, so it imports an 
> unrelated test/ package directory in the top level of my app, which 
> obviously won't work, and the app breaks.
>
> i couldn't find any mention of this in release notes or docs. was this 
> expected? any recommendations for handling it? thanks in advance!
>
>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/d04cbc6c-98cf-468c-beec-35aa5e37ea39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] dev_appserver in 1.9.76 switched import resolution from relative to absolute?

[Ryan B]

hi all! i'm debugging a dev_appserver problem that seems to have been 
introduced in google cloud sdk 219 / app-engine-python 1.9.76: imports are 
now all resolved as absolute instead of relative. does that sound familiar?

for example, i use the future library  in many 
of my apps, which has this line of code 

:

import test

on gcloud sdk 218 / app-engine-python 1.9.75 and before, this worked fine. 
it resolved the import relative to the containing source file, in 
local/lib/python2.7/site-packages/future/... , a virtualenv, which i set up 
with vendor 
.
 
on 1.9.76, it changed to resolving absolute instead, so it imports an 
unrelated test/ package directory in the top level of my app, which 
obviously won't work, and the app breaks.

i couldn't find any mention of this in release notes or docs. was this 
expected? any recommendations for handling it? thanks in advance!


-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/51b6c05e-02ef-4c99-9ff7-33bf432b8a8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] High network latency, but logs should sub milisecond response time?

[Ryan Sacha]

I can't figure out why when i curl to my service the response fluctuates 
from a minimum of 400ms upto 1 second and beyond for a simple request that 
literally just returns a json response. (no db calls, or anything) even 
static files take >400ms.

In fact i went to the logs and indeed the server only takes 4ms at max. but 
when a user requests the url it takes a long time.

[image: 10-01_18-19-40.png]

What am i missing here?

Avg response:

[image: 10-01_18-20-34.png]


This is not just due to my distance to the server, i'm totally fine with 
100ms due to normal network latency.


*App.yaml:*


runtime: nodejs

env: flex

service: default


manual_scaling:

  instances: 1

resources:

  cpu: 1

  memory_gb: 1.5

  disk_size_gb: 10

network:

  name: default



-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/58ed181b-069c-4315-ad52-4072c4574d0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Route app engine's subdirectory to a wordpress VM?

[Ryan Sacha]

I have a Node JS appengine app. but i want to route anything /blog/* to a 
separate wordpress VM created through the cloud launcher. it's not an 
appengine service, just a compute engine VM.

How can I do this?


Current app.yaml:


runtime: nodejs
env: flex

manual_scaling:
  instances: 1
resources:
  cpu: 1
  memory_gb: 0.5
  disk_size_gb: 10

handlers:
- url: /.*
  script: auto
  secure: always
  redirect_http_response_code: 301

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/116fd608-d67f-4ed7-8316-d82f05532425%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Postinstall script not receiving env_variables

[Ryan Sacha]

Just to add - unrelated to the above issue - the handlers part also doesn't 
work, it's supposed to redirect to https but it doesn't.

I have checked config on the console and it looks like it does upload the 
config in app.yaml just fine:

[image: 08-16_16-31-23.png] 



On Thursday, August 16, 2018 at 4:23:33 PM UTC+1, Ryan Sacha wrote:
>
> I have an issue with a node js app engine project, where the main 
> script/server.js receives the environment variables just fine. but the 
> "postinstall" doesn't.
>
> {
>   "name": "citation-generator",
>   "version": "4.1.0",
>   "main": "server.js",
>   "scripts": {
> "start": "node server.js",
> "postinstall": "gulp --production"
>   },
> ...
> }
>
>
> Gulp doesn't receive the custom env variables i set on app.yaml, in fact i 
> tested it by logging process.env from gulp.js and it's just the generic 
> variables on a linux environment.
>
> my app.yaml:
>
>
>
>
> runtime: nodejs
> env: flex
>
>
> manual_scaling:
>   instances: 1
> resources:
>   cpu: 1
>   memory_gb: 0.5
>   disk_size_gb: 10
>
>
> env_variables:
>   FOO: "BAR"
>
>
> handlers:
> - url: /.*
>   script: auto
>   secure: always
>   redirect_http_response_code: 301
>
>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/29ae8985-5ac1-47f9-8e8c-b905fd81b70d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Postinstall script not receiving env_variables

[Ryan Sacha]

I have an issue with a node js app engine project, where the main 
script/server.js receives the environment variables just fine. but the 
"postinstall" doesn't.

{
  "name": "citation-generator",
  "version": "4.1.0",
  "main": "server.js",
  "scripts": {
"start": "node server.js",
"postinstall": "gulp --production"
  },
...
}


Gulp doesn't receive the custom env variables i set on app.yaml, in fact i 
tested it by logging process.env from gulp.js and it's just the generic 
variables on a linux environment.

my app.yaml:




runtime: nodejs
env: flex


manual_scaling:
  instances: 1
resources:
  cpu: 1
  memory_gb: 0.5
  disk_size_gb: 10


env_variables:
  FOO: "BAR"


handlers:
- url: /.*
  script: auto
  secure: always
  redirect_http_response_code: 301


-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/46e733ba-c2bf-4e83-8b19-760bb4503104%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: URLFetch adds gzip,deflate,br to outbound requests' Accept-Encoding?

[Ryan B]

i've filed https://issuetracker.google.com/issues/112277350 for this.

On Thursday, August 2, 2018 at 10:50:51 AM UTC-7, Ryan B wrote:
>
> hi all! i had to debug a URLFetch problem recently, and the root cause 
> turned out to be that i was unexpectedly receiving a brotli-compressed 
> response. it took me a while to figure out why: evidently URLFetch is 
> adding gzip,deflate,br to outbound requests' Accept-Encoding HTTP header.
>
> is this expected? it's not documented on 
> https://cloud.google.com/appengine/docs/standard/python/outbound-requests#request_headers
>  
> , and brotli support isn't built into many common HTTP libraries, e.g. 
> python requests, so this will usually be an unpleasant surprise when 
> talking to a server that supports brotli. is it unintentional? should i 
> file a bug?
>
> here's a snippet that reproduces this on https://shell-hrd.appspot.com/ :
>
> >>> from google.appengine.api import urlfetch
> >>> resp = urlfetch.fetch('https://httpbin.org/headers', 
> >>> headers={'Accept-Encoding': 'foo'})
> >>> resp.status_code
> 200
> >>> print(resp.content)
> {
>   "headers": {
> "Accept-Encoding": "foo,gzip,deflate,br",
> "Connection": "close",
> "Host": "httpbin.org",
> "User-Agent": "AppEngine-Google; (+http://code.google.com/appengine; 
> appid: s~shell-hrd)",
> "X-Cloud-Trace-Context": 
> "795505ff8141cf535fa9cf33afe59daa/1604381323415253803;o=1"
>   }
> }
>
>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/752ee899-07fb-491a-b8b3-83f6b3c5a270%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Google app engine creating instances not in 'default internal' ip ranges?

[Ryan Barker]

I am having issues that some of the instances that are being automatically 
spun up by google app engine are not able to connect to my database. I have 
a hunch the issue is that the problem relates to ip addresses outside of 
the range of ip addresses that should be set up for internal machines.  
Unfortunately (or fortunately) the problem resolved itself before I could 
get the ip address of the machines that could not connect.

1) How can I find the logs of internal ip addresses that are being created?
2) What should the internal firewall ip range be set to? It is currently 
set to 10.128.0.0/9 


Thanks

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/ab336c33-f0fa-4add-9d29-9dcb18d007d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] URLFetch adds gzip,deflate,br to outbound requests' Accept-Encoding?

[Ryan B]

hi all! i had to debug a URLFetch problem recently, and the root cause 
turned out to be that i was unexpectedly receiving a brotli-compressed 
response. it took me a while to figure out why: evidently URLFetch is 
adding gzip,deflate,br to outbound requests' Accept-Encoding HTTP header.

is this expected? it's not documented on 
https://cloud.google.com/appengine/docs/standard/python/outbound-requests#request_headers
 
, and brotli support isn't built into many common HTTP libraries, e.g. 
python requests, so this will usually be an unpleasant surprise when 
talking to a server that supports brotli. is it unintentional? should i 
file a bug?

here's a snippet that reproduces this on https://shell-hrd.appspot.com/ :

>>> from google.appengine.api import urlfetch
>>> resp = urlfetch.fetch('https://httpbin.org/headers', 
>>> headers={'Accept-Encoding': 'foo'})
>>> resp.status_code
200
>>> print(resp.content)
{
  "headers": {
"Accept-Encoding": "foo,gzip,deflate,br",
"Connection": "close",
"Host": "httpbin.org",
"User-Agent": "AppEngine-Google; (+http://code.google.com/appengine; appid: 
s~shell-hrd)",
"X-Cloud-Trace-Context": 
"795505ff8141cf535fa9cf33afe59daa/1604381323415253803;o=1"
  }
}


-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/193794a4-4cda-4a2b-a5f8-0e0e69b64cd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Is it even possible to host magento on app engine?

['Ryan Sun' via Google App Engine]

So there is this 
post https://cloud.google.com/solutions/architecture/magento-deployment
descried that you can deploy magento to app engine, but magento itself has 
14000+ files, how would it be possible to deploy with the 1 files limit 
on app engine? 

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/1f0f317c-7603-4e5f-96dd-ed7876c27f22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Run Node app locally and serve static file handlers from app.yaml?

[Ryan B]

thanks, steren! makes sense.

i'm actually trying the Node runtime for the first time, on a small 
personal project, so i don't actually have the "lots of static file 
handlers in Node" use case yet. i'm just sensitive to DRY and seeing 
duplicated things skew over time.

thanks again!

On Thursday, July 12, 2018 at 1:39:26 PM UTC-7, Steren Giannini wrote:
>
> Hi Ryan,
>
> The feedback we receive was that Node.js developers expect to start their 
> application with "npm start" more than with "dev_appserver.py".
>
> Replicating the handlers in your web framework is indeed the 
> recommendation that we give in our static handler documentation 
> <https://cloud.google.com/appengine/docs/standard/nodejs/serving-static-files#serving_files_for_local_development>
> .
>
> That being said, we are currently exploring an optional solution to run 
> your Node.js App Engine app in a local emulator that would emulate the 
> static handlers.
>
> In am curious, can you share more about why your application uses many 
> different static handlers?
>
> Steren
>
> On Thu, Jul 12, 2018 at 10:28 AM Ryan B > 
> wrote:
>
>> thanks, kenworth!
>>
>> looks like the key part of that example is these lines in app.js:
>>
>> // Use the built-in express middleware for serving static files from 
>> './public'
>> app.use('/static', express.static('public'));
>>
>> that does indeed get the static files serving. it still ignores the 
>> static file handlers in app.yaml, though, and just duplicates them via 
>> express in app.js instead. that's ok, but it's unfortunate for larger 
>> applications with many different static file handlers in app.yaml, since 
>> you have to duplicate them all, and they'll inevitably skew when you change 
>> them.
>>
>> if this is expected, i'm happy to file a feature request on the issue 
>> tracker! just let me know.
>>
>> On Thursday, July 12, 2018 at 9:20:30 AM UTC-7, Kenworth (Google Cloud 
>> Platform) wrote:
>>>
>>> This is currently possible. Here is an example to help you get started:
>>>
>>> https://github.com/
>>> GoogleCloudPlatform/nodejs-docs-samples/tree/master/appengine/static-files
>>>
>>> npm start app.standard.yaml
>>>
>>>
>>>
>>> -- 
>> 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-appengi...@googlegroups.com .
>> To post to this group, send email to google-a...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/google-appengine.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-appengine/60e8d17a-61b1-4bf7-aced-f669092fcbf6%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/google-appengine/60e8d17a-61b1-4bf7-aced-f669092fcbf6%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/ba590bf6-8a1e-4468-a262-129244fefe44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Run Node app locally and serve static file handlers from app.yaml?

[Ryan B]

thanks, kenworth!

looks like the key part of that example is these lines in app.js:

// Use the built-in express middleware for serving static files from 
'./public'
app.use('/static', express.static('public'));

that does indeed get the static files serving. it still ignores the static 
file handlers in app.yaml, though, and just duplicates them via express in 
app.js instead. that's ok, but it's unfortunate for larger applications 
with many different static file handlers in app.yaml, since you have to 
duplicate them all, and they'll inevitably skew when you change them.

if this is expected, i'm happy to file a feature request on the issue 
tracker! just let me know.

On Thursday, July 12, 2018 at 9:20:30 AM UTC-7, Kenworth (Google Cloud 
Platform) wrote:
>
> This is currently possible. Here is an example to help you get started:
>
>
> https://github.com/GoogleCloudPlatform/nodejs-docs-samples/tree/master/appengine/static-files
>
> npm start app.standard.yaml
>
>
>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/60e8d17a-61b1-4bf7-aced-f669092fcbf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Run Node app locally and serve static file handlers from app.yaml?

[Ryan B]

hi all! the docs for Node currently say use to npm start, ie "your local 
environment with the development tools that you usually use," to run an app 
locally:

https://cloud.google.com/appengine/docs/standard/nodejs/testing-and-deploying-your-app#running_locally

this works fine for URLs handled by Node, but it doesn't serve static files 
handled by app.yaml, so testing an app manually locally is difficult (or 
impossible) since it won't have static HTML, CSS, JS, etc.

other language runtimes use eg dev_appserver to serve both dynamic and 
static file handlers. are there plans for anything similar for Node?

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/cf83608f-e409-4d42-a4fa-8d2d2f080c5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Can app engine host a Node JS worker?

[Ryan Sacha]

I came across the recent launch of Node JS serverless option on google app 
engine.

My question is, would it be safe to host a Node JS worker app (like Kue or 
Bull) without app engine killing a running job midway to conserve server 
cost?

I'm wary of Cloud functions because they seem to be for lighter, fast 
startup scripts, not full fledged apps.

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/cbed8552-2f38-4732-a0c5-8edc0ffa74bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Connection Issues with AppEngine and app built for Salesforce AppExchange

[Ryan Lallier]

Does anyone here have an app they built on the appexchange? We are having 
multiple connection errors and cannot figure out why. 

Thank you - Ryan

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/9dc34db7-1669-420f-8902-e13cbce0dbcb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Doubt about "Frontend Instance hours"

[Ryan B]

On Wednesday, September 6, 2017 at 6:08:33 AM UTC-7, Diego Barreiro wrote:
>
>
> I have my application, with only one service ("default") and only one 
> version reciving all traffic ("2-0-0"). If two users use my app for an 
> hour, that quota increases by two hours or only one hour?
>

only one hour. instance hours are unrelated to number of users.

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/dbc7a279-e295-4c18-8282-c0d464bda96d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Billed Instance Estimate noticeably wrong: shows 2 instances, actually billed for almost 3

[Ryan B]

hi all! i have an app engine project that consistently uses 2 frontend 
instances, based on cloud console's "Billed Instance Estimate," but has 
consistently been billed for almost 3 instances, for at least the last few 
months. screenshots below for august: 1980h / 29 days = ~2.83 instances.


any idea what's going on? is "Billed Instance Estimate" known to be wrong 
in some cases? i have a dozen or so other apps that generally run on just 1 
instance each according to "Billed Instance Estimate," occasionally over, 
and their actual billed instance hours all match correctly.

thanks in advance!








-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/64c3ae42-3eda-44f6-b49d-80152482cdb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Django, App Engine Flexible and Cloud SQL: OperationalError 2002, Can't connect to local MySQL server through socket

['Ryan Matsumoto' via Google App Engine]

For Django you should not need to set SQLALCHEMY_DATABASE_URI in app.yaml. 
This is just used in the Python Google Cloud SQL on Flask code sampl 
<https://github.com/GoogleCloudPlatform/python-docs-samples/tree/master/appengine/flexible/cloudsql>e
 
to set that environment variable that the sample code uses when deployed. 
The app.yaml in the Django code sample 
<https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/appengine/flexible/django_cloudsql/app.yaml>
 
does not set this environment variable.

I'd recommend following the Django on Flex 
<https://cloud.google.com/python/django/flexible-environment> tutorial 
end-to-end and see what happens. You'll be able to see if the CloudSQL 
connection works properly by going to the admin part of the deployed web 
app at [YOUR_PROJECT_ID].appspot.com/admin, logging in with the superuser 
you define, and adding a question or two.

Good luck, and let us me know if you have any more issues!

Best,
Ryan Matsumoto
Developer Programs Engineer, Google Cloud (Python)


On Wednesday, April 12, 2017 at 11:33:53 AM UTC-7, Tas Sóti wrote:
>
> Hello George,
>
> Thank you for the quick response. I was following the Running Django in 
> the App Engine Flexible Environment 
> <https://cloud.google.com/python/django/flexible-environment> tutorial 
> and it does not say anything about the SQLALCHEMY_DATABASE_URI environment 
> variable. Is it not meant for SQLAlchemy only? I am using Django's ORM. I 
> actually have another instance running with the same app.yaml as described 
> above and it is working. The difference is that that project (including 
> both the App Engine and SQL instance) is in the us-central region and I 
> deployed it a couple of months ago, when the App Engine Flexible was still 
> in beta.
>
> So is now the SQLALCHEMY_DATABASE_URI variable meant for using with the 
> Django ORM, too, and the old beta_settings is deprecated?
> I'll give it a try, it is just not very logical (at least for me), why the 
> variable name includes "SQLAlchemy" if it is meant for any kind of 
> python<->sql connection.
>
> Thank you in advance,
>  Tas
>
> On Wednesday, April 12, 2017 at 8:08:24 PM UTC+2, George (Cloud Platform 
> Support) wrote:
>>
>> Hello Tas, 
>>
>> To allow your app to connect to your Cloud SQL instance when the app is 
>> deployed, add the user, password, database, and instance connection name 
>> variables from Cloud SQL to the related environment variables in the 
>> app.yaml file: 
>>
>> env_variables:
>>
>># Replace user, password, database, and instance connection name with 
>> the values obtained
>>
>># when configuring your Cloud SQL instance.
>>
>>SQLALCHEMY_DATABASE_URI: >-
>>
>>
>>  
>> mysql+pymysql://USER:PASSWORD@/DATABASE?unix_socket=/cloudsql/INSTANCE_CONNECTION_NAME
>>
>> It may be worthwhile to check in detail this information and the other 
>> related steps in the “Using Cloud SQL for MySQL” document 
>> <https://cloud.google.com/appengine/docs/flexible/python/using-cloud-sql>. 
>> This solution, with relevant detail, is given in the “cloudsql databases 
>> with django on 'new' flexible google app engine” question 
>> <http://stackoverflow.com/questions/39034250/cloudsql-databases-with-django-on-new-flexible-google-app-engine>
>>  
>> on Stackoverflow.  
>>
>> The “Running Django in the App Engine Flexible Environment” documentation 
>> page <https://cloud.google.com/python/django/flexible-environment> might 
>> prove quite helpful for related details. 
>>
>>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/72c666af-3dd2-4f1b-a99c-21cd4cc6dc9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: NDB dictionary

[Ryan Ang Wei En]

Thank you for the help, I am learning a lot today!

If I delete the entity 'West Coast' station entity, will all existing 
shifts with "ancestor == ndb.Key(Station, 'West Coast')" automatically get 
deleted?

I want to prevent data store leaks.

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/f8deaf49-6808-4335-b00b-4a46268c1459%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: NDB dictionary

[Ryan Ang Wei En]

Dear Anons,

First of all thank you for the replies, your care is greatly, greatly 
appreciated!

> # one item into ndb
> apple_count = len(Fruit.query().fetch(100))
> self.assertEqual(apple_count, 1)
>
 
After reading this, I've realised that fruits analogy is a wrong example of 
the actual issue I am facing.
I would like to kindly request for some time to read this post.

I'm working on a server project for a petrol station company.
I have this station class.

class Station(modelpy.Model):
shifts = ndb.JsonProperty()

The Station's key's id is the name of a station.
Here are the names of the actual stations: "West Coast", "Woodlands", 
"South View".
I use these station names in get_by_id() to get the station entity.
As you can see, Station consists of a JsonProperty called "shifts".
The "shifts" consists of the data as follows (shown in a json format):
{
  "South View": {
"shifts": {
  "Full Day": {
"start": "7am",
"end": "7pm"
  }
}
  },
  "West Coast": {
"shifts": {
  "Morning Shift": {
"start": "10am",
"end": "10pm"
  },
  "Night Shift": {
"start": "10pm",
"end": "10am"
  }
}
  },
  "Woodlands": {
"shifts": {
  "Morning Shift": {
"start": "8am",
"end": "8pm"
  },
  "Night Shift": {
"start": "8pm",
"end": "8am"
  }
}
  }
}
I need a solution for these 3:
1) Ndb must not be allowed to store more than 1 shift (e.g. key.put() 
replaces any (if existing) entity with equal id).
2) Ndb must contain the "start" and "end" required property for every shift 
(e.g. required=True).
3) Most IMPORTANT: A MAINTAINTABLE solution that does not need to be 
re-implemented for other similar examples. (e.g. NOT write custom assertion 
every single time!)

JsonProperty demands a crap-ton of maintainability
I don't want to write a custom assertion every time, instead I want a 
generic solution (dictionary).

Don't mind the caps, I'm not shouting at anyone, just emphasis.

Love,
Ryan

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/d877b6c6-c7ed-412c-924b-c68759a6f8f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] NDB dictionary

[Ryan Ang Wei En]

I have this sample json of a list of "Fruit":
{
  "apple":{
"color":red"
"taste":"sweet"
  }
  "pineapple":{
"color":yellow"
"taste":"sour"
  }
}
I want to use a very object oriented approach to retrieve a property of my 
entity using a string key.
The requirements:
1) NDB must not be able to store any "Fruit" without the "color" or "taste" 
fields. (JsonProperty does not meet this requirement)
2) "apple" and "pineapple" are unique identifiers, used to retrieve it's 
corresponding fruit data, NDB must not be able to store multiple fruit 
objects containing the same unique identifier.

class Fruit(ndb.Model):
  name = ndb.StringProperty(required=True)
  color = ndb.StringProperty(required=True)
  taste = ndb.StringProperty(required=True)

class Person(ndb.Model):
  favoritefruits = ndb.StructuredProperty(required=True,repeated=true)

Then to find apple,
person = Person.get_by_id("Johnathan").favouritefruits
for fruit in person.favoritefruits:
  if fruit.name == "apple"
# found apple!

The problem:
Multiple "Fruit" objects containing the same "name" property can exist in 
the "favoritefruits" property.

What solutions are there that will fulfil both requirements 1) and 2)?

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/a6c7c7f1-d150-4a97-b0f3-639558fedc07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Instagram blocking App Engine's urlfetch/sockets IP block

[Ryan B]

just to follow up, instagram has evidently stopped blocking/throttling
app engine's IPs, or whatever else was happening here. i can now
successfully fetch www.instagram.com profile and photo pages from a
few different app engine apps.

On Fri, May 6, 2016 at 1:25 PM, 'Nick (Cloud Platform Support)' via
Google App Engine <google-appengine@googlegroups.com> wrote:
> Thanks for the details! Hopefully this thread is useful to future users.
>
>
> On Friday, May 6, 2016 at 2:57:49 PM UTC-4, Ryan Barrett wrote:
>>
>> On Fri, May 6, 2016 at 9:47 AM, 'Nick (Cloud Platform Support)' via
>> Google App Engine <google-appengine@googlegroups.com> wrote:
>> > Hey Ryan,
>> >
>> > Glad to be of assistance, and I really want to get to the bottom of
>> > this.
>> > Reviewing the infrastructure used by UrlFetch, this absolutely does make
>> > sense, when we consider this tantalizing detail from the documentation:
>> >
>> >> The URL Fetch service uses an HTTP/1.1 compliant proxy to fetch the
>> >> result.
>>
>> yup. if urlfetch is behind a small or even medium sized set of VIPs or
>> IP blocks, and instagram rate limits their www based on IP (individual
>> or block), that's it. you could data mine urlfetch's logs and find the
>> offending app(s), if any, and play the abuse whack-a-mole game,
>> but...meh.
>>
>> > which sort of proxy configuration you're using, the type of proxy, the
>> > average
>> > request load, etc.?
>>
>> sure! it's dirt simple, just apache mod_proxy with these lines in
>> httpd.conf:
>>
>> SSLProxyEngine on
>> 
>> ProxyPass "https://www.instagram.com/;
>> 
>>
>> my load is miniscule and pretty constant, roughly 1-2qm on average.
>> most of that is to profile URLs (evenly spread across ~500 users), the
>> rest to individual photo URLs like eg
>> https://www.instagram.com/p/BE4xLpmABFz/.
>>
>> i used to do 3-5x that much before i throttled down recently. i
>> haven't tried, but i expect i could ramp back up to that on the
>> reverse proxy and not get 429ed.
>>
>>
>> > On Thursday, May 5, 2016 at 6:36:12 PM UTC-4, Ryan Barrett wrote:
>> >>
>> >> thanks for going above and beyond, nick! much appreciated. i'm
>> >> currently working around it by using a reverse proxy outside of app
>> >> engine, so that my requests are charged to a different IP and isolated
>> >> from other app engine apps. glad this info is here now for other
>> >> people too.
>> >>
>> >>
>> >> On Thu, May 5, 2016 at 2:13 PM, 'Nick (Cloud Platform Support)' via
>> >> Google App Engine <google-appengine@googlegroups.com> wrote:
>> >> >
>> >> > After some extensive testing, I've determined that the 429 you're
>> >> > receiving
>> >> > is expected behaviour from instagram, and it does relate to a
>> >> > windowing
>> >> > average, although it may not be the same as that published in their
>> >> > documentation for APIs. After sending a few thousand requests in a
>> >> > span
>> >> > of
>> >> > ~15 seconds, I began to receive 429 responses, with some 200's
>> >> > intermixed.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Nick
>> >> > Cloud Platform Community Support
>> >> >
>> >> > On Wednesday, May 4, 2016 at 3:21:46 PM UTC-4, Ryan Barrett wrote:
>> >> >>
>> >> >> On Wed, May 4, 2016 at 12:02 PM, 'Nick (Cloud Platform Support)' via
>> >> >> Google App Engine <google-appengine@googlegroups.com> wrote:
>> >> >> > So, you're attempting merely to fetch http://www.instagram.com/,
>> >> >> > and
>> >> >> > you
>> >> >> > receive 429 on the first request, and you're not launching many
>> >> >> > other
>> >> >> > requests at the same time? It seems odd that a rate-limit response
>> >> >> > would
>> >> >> > come without a condition being reached requiring rate-limiting...
>> >> >> > Let
>> >> >> > me
>> >> >>
>> >> >> i'm actually fetching profile URLs, not the front page. eg `import
>> >> >> urllib2; urllib2.urlopen('https://www.instagram.com/kevin/')` in
>> >> >> https://shell-hrd.appspot.com/ gets 42

Re: [google-appengine] Instagram blocking App Engine's urlfetch/sockets IP block

[Ryan Barrett]

On Fri, May 6, 2016 at 9:47 AM, 'Nick (Cloud Platform Support)' via
Google App Engine <google-appengine@googlegroups.com> wrote:
> Hey Ryan,
>
> Glad to be of assistance, and I really want to get to the bottom of this.
> Reviewing the infrastructure used by UrlFetch, this absolutely does make
> sense, when we consider this tantalizing detail from the documentation:
>
>> The URL Fetch service uses an HTTP/1.1 compliant proxy to fetch the
>> result.

yup. if urlfetch is behind a small or even medium sized set of VIPs or
IP blocks, and instagram rate limits their www based on IP (individual
or block), that's it. you could data mine urlfetch's logs and find the
offending app(s), if any, and play the abuse whack-a-mole game,
but...meh.

> which sort of proxy configuration you're using, the type of proxy, the average
> request load, etc.?

sure! it's dirt simple, just apache mod_proxy with these lines in httpd.conf:

SSLProxyEngine on

ProxyPass "https://www.instagram.com/;


my load is miniscule and pretty constant, roughly 1-2qm on average.
most of that is to profile URLs (evenly spread across ~500 users), the
rest to individual photo URLs like eg
https://www.instagram.com/p/BE4xLpmABFz/.

i used to do 3-5x that much before i throttled down recently. i
haven't tried, but i expect i could ramp back up to that on the
reverse proxy and not get 429ed.


> On Thursday, May 5, 2016 at 6:36:12 PM UTC-4, Ryan Barrett wrote:
>>
>> thanks for going above and beyond, nick! much appreciated. i'm
>> currently working around it by using a reverse proxy outside of app
>> engine, so that my requests are charged to a different IP and isolated
>> from other app engine apps. glad this info is here now for other
>> people too.
>>
>>
>> On Thu, May 5, 2016 at 2:13 PM, 'Nick (Cloud Platform Support)' via
>> Google App Engine <google-appengine@googlegroups.com> wrote:
>> >
>> > After some extensive testing, I've determined that the 429 you're
>> > receiving
>> > is expected behaviour from instagram, and it does relate to a windowing
>> > average, although it may not be the same as that published in their
>> > documentation for APIs. After sending a few thousand requests in a span
>> > of
>> > ~15 seconds, I began to receive 429 responses, with some 200's
>> > intermixed.
>> >
>> > Cheers,
>> >
>> > Nick
>> > Cloud Platform Community Support
>> >
>> > On Wednesday, May 4, 2016 at 3:21:46 PM UTC-4, Ryan Barrett wrote:
>> >>
>> >> On Wed, May 4, 2016 at 12:02 PM, 'Nick (Cloud Platform Support)' via
>> >> Google App Engine <google-appengine@googlegroups.com> wrote:
>> >> > So, you're attempting merely to fetch http://www.instagram.com/, and
>> >> > you
>> >> > receive 429 on the first request, and you're not launching many other
>> >> > requests at the same time? It seems odd that a rate-limit response
>> >> > would
>> >> > come without a condition being reached requiring rate-limiting... Let
>> >> > me
>> >>
>> >> i'm actually fetching profile URLs, not the front page. eg `import
>> >> urllib2; urllib2.urlopen('https://www.instagram.com/kevin/')` in
>> >> https://shell-hrd.appspot.com/ gets 429ed even though i'm not fetching
>> >> that particular URL in any of my apps.
>> >>
>> >> it definitely seems odd, agreed. i only suspect rate limiting/blocking
>> >> at the IP level because i exhaused the other obvious causes. i'd be
>> >> happy to be proven wrong!
>> >>
>> >>
>> >> > know what you think in your reply.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Nick
>> >> > Cloud Platform Community Support
>> >> >
>> >> > On Wednesday, May 4, 2016 at 1:09:35 PM UTC-4, Ryan Barrett wrote:
>> >> >>
>> >> >> thanks for the replies! i should have emphasized that this is for
>> >> >> www.instagram.com, not the API. API requests are working fine.
>> >> >>
>> >> >> you're right that IP blocking wouldn't usually be the first culprit
>> >> >> in
>> >> >> general, especially for 429s. i tried from a few different apps,
>> >> >> though,
>> >> >> including shell-hrd (log in my first post), which pretty much never
>> >> >> uses
>> >> >> urlfetch otherwise based on its quota numbers, so i doubt it's
>> >> 

Re: [google-appengine] Instagram blocking App Engine's urlfetch/sockets IP block

[Ryan B]

thanks for going above and beyond, nick! much appreciated. i'm
currently working around it by using a reverse proxy outside of app
engine, so that my requests are charged to a different IP and isolated
from other app engine apps. glad this info is here now for other
people too.


On Thu, May 5, 2016 at 2:13 PM, 'Nick (Cloud Platform Support)' via
Google App Engine <google-appengine@googlegroups.com> wrote:
>
> After some extensive testing, I've determined that the 429 you're receiving
> is expected behaviour from instagram, and it does relate to a windowing
> average, although it may not be the same as that published in their
> documentation for APIs. After sending a few thousand requests in a span of
> ~15 seconds, I began to receive 429 responses, with some 200's intermixed.
>
> Cheers,
>
> Nick
> Cloud Platform Community Support
>
> On Wednesday, May 4, 2016 at 3:21:46 PM UTC-4, Ryan Barrett wrote:
>>
>> On Wed, May 4, 2016 at 12:02 PM, 'Nick (Cloud Platform Support)' via
>> Google App Engine <google-appengine@googlegroups.com> wrote:
>> > So, you're attempting merely to fetch http://www.instagram.com/, and you
>> > receive 429 on the first request, and you're not launching many other
>> > requests at the same time? It seems odd that a rate-limit response would
>> > come without a condition being reached requiring rate-limiting... Let me
>>
>> i'm actually fetching profile URLs, not the front page. eg `import
>> urllib2; urllib2.urlopen('https://www.instagram.com/kevin/')` in
>> https://shell-hrd.appspot.com/ gets 429ed even though i'm not fetching
>> that particular URL in any of my apps.
>>
>> it definitely seems odd, agreed. i only suspect rate limiting/blocking
>> at the IP level because i exhaused the other obvious causes. i'd be
>> happy to be proven wrong!
>>
>>
>> > know what you think in your reply.
>> >
>> > Cheers,
>> >
>> > Nick
>> > Cloud Platform Community Support
>> >
>> > On Wednesday, May 4, 2016 at 1:09:35 PM UTC-4, Ryan Barrett wrote:
>> >>
>> >> thanks for the replies! i should have emphasized that this is for
>> >> www.instagram.com, not the API. API requests are working fine.
>> >>
>> >> you're right that IP blocking wouldn't usually be the first culprit in
>> >> general, especially for 429s. i tried from a few different apps,
>> >> though,
>> >> including shell-hrd (log in my first post), which pretty much never
>> >> uses
>> >> urlfetch otherwise based on its quota numbers, so i doubt it's
>> >> User-Agent
>> >> blocking. i tried an entirely new www.instagram.com URL and still got a
>> >> 429,
>> >> so it's probably not specific URLs, at least due to my own traffic. and
>> >> i
>> >> can fetch the same URL fine from my local machine. hence my IP
>> >> suspicion.
>> >>
>> >> i've already worked around this, so it's not urgent. just figured you
>> >> all
>> >> might want to know. thanks again!
>> >>
>> >> On Monday, May 2, 2016 at 10:52:11 AM UTC-7, Nick (Cloud Platform
>> >> Support)
>> >> wrote:
>> >>>
>> >>> Hey Ryan,
>> >>>
>> >>> I'm unsure that this indicates that App Engine specifically is being
>> >>> rate-limited. It's likely that the 429 response is directly related to
>> >>> the
>> >>> frequency with which you're making requests, regardless of the origin
>> >>> of
>> >>> those requests. While not impossible, I suppose, it would be
>> >>> surprising if
>> >>> they were keeping track of App Engine IP ranges and applying a
>> >>> different
>> >>> rate-limit, and would require some thorough A/B testing to prove. So,
>> >>> I
>> >>> recommend just checking their documentation or, if the rate-limit is
>> >>> undocumented, benchmarking to attempt to determine it, and try to fly
>> >>> under
>> >>> it. Generally, exponential-backoff is a good tactic when dealing with
>> >>> rate-limiting.
>> >>>
>> >>> Sincerely,
>> >>>
>> >>> Nick
>> >>> Cloud Platform Community Support
>> >>>
>> >>> On Monday, May 2, 2016 at 11:57:15 AM UTC-4, Nickolas Daskalou wrote:
>> >>>>
>> >>>> Hi Ryan,
>> >>>>
>> >>>

Re: [google-appengine] Instagram blocking App Engine's urlfetch/sockets IP block

[Ryan B]

On Wed, May 4, 2016 at 12:02 PM, 'Nick (Cloud Platform Support)' via
Google App Engine <google-appengine@googlegroups.com> wrote:
> So, you're attempting merely to fetch http://www.instagram.com/, and you
> receive 429 on the first request, and you're not launching many other
> requests at the same time? It seems odd that a rate-limit response would
> come without a condition being reached requiring rate-limiting... Let me

i'm actually fetching profile URLs, not the front page. eg `import
urllib2; urllib2.urlopen('https://www.instagram.com/kevin/')` in
https://shell-hrd.appspot.com/ gets 429ed even though i'm not fetching
that particular URL in any of my apps.

it definitely seems odd, agreed. i only suspect rate limiting/blocking
at the IP level because i exhaused the other obvious causes. i'd be
happy to be proven wrong!


> know what you think in your reply.
>
> Cheers,
>
> Nick
> Cloud Platform Community Support
>
> On Wednesday, May 4, 2016 at 1:09:35 PM UTC-4, Ryan Barrett wrote:
>>
>> thanks for the replies! i should have emphasized that this is for
>> www.instagram.com, not the API. API requests are working fine.
>>
>> you're right that IP blocking wouldn't usually be the first culprit in
>> general, especially for 429s. i tried from a few different apps, though,
>> including shell-hrd (log in my first post), which pretty much never uses
>> urlfetch otherwise based on its quota numbers, so i doubt it's User-Agent
>> blocking. i tried an entirely new www.instagram.com URL and still got a 429,
>> so it's probably not specific URLs, at least due to my own traffic. and i
>> can fetch the same URL fine from my local machine. hence my IP suspicion.
>>
>> i've already worked around this, so it's not urgent. just figured you all
>> might want to know. thanks again!
>>
>> On Monday, May 2, 2016 at 10:52:11 AM UTC-7, Nick (Cloud Platform Support)
>> wrote:
>>>
>>> Hey Ryan,
>>>
>>> I'm unsure that this indicates that App Engine specifically is being
>>> rate-limited. It's likely that the 429 response is directly related to the
>>> frequency with which you're making requests, regardless of the origin of
>>> those requests. While not impossible, I suppose, it would be surprising if
>>> they were keeping track of App Engine IP ranges and applying a different
>>> rate-limit, and would require some thorough A/B testing to prove. So, I
>>> recommend just checking their documentation or, if the rate-limit is
>>> undocumented, benchmarking to attempt to determine it, and try to fly under
>>> it. Generally, exponential-backoff is a good tactic when dealing with
>>> rate-limiting.
>>>
>>> Sincerely,
>>>
>>> Nick
>>> Cloud Platform Community Support
>>>
>>> On Monday, May 2, 2016 at 11:57:15 AM UTC-4, Nickolas Daskalou wrote:
>>>>
>>>> Hi Ryan,
>>>>
>>>> It seems to be working fine for us (SocialPage.me).
>>>>
>>>> Are you accessing their API using separate access tokens for each user?
>>>>
>>>> Nick
>>>>
>>>>
>>>> On 2 May 2016 at 14:30, Ryan Barrett <goo...@ryanb.org> wrote:
>>>>>
>>>>> hi all! just FYI, it looks like Instagram is blocking/rate limiting App
>>>>> Engine's IPs from fetching www.instagram.com, both urlfetch and sockets,
>>>>> across apps. e.g. this session from https://shell-hrd.appspot.com/ :
>>>>>
>>>>> >>> urllib2.urlopen('https://www.instagram.com/snarfed/')
>>>>> Traceback (most recent call last):
>>>>> ...
>>>>>   File
>>>>> "/base/data/home/runtimes/python/python_dist/lib/python2.5/urllib2.py", 
>>>>> line
>>>>> 506, in http_error_default
>>>>> raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
>>>>> HTTPError: HTTP Error 429: Unknown
>>>>>
>>>>> it's not 100% consistent - i occasionally see requests make it through
>>>>> - but the majority get 429ed.
>>>>>
>>>>> not holding my breath, but i figured you all might want to know,
>>>>> especially in case cloud support people have lines of communication open
>>>>> with instagram/facebook for this kind of thing.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Google App Engine" group.
>>>>> To unsubscribe from thi

Re: [google-appengine] Instagram blocking App Engine's urlfetch/sockets IP block

[Ryan Barrett]

thanks for the replies! i should have emphasized that this is for 
www.instagram.com, not the API. API requests are working fine.

you're right that IP blocking wouldn't usually be the first culprit in 
general, especially for 429s. i tried from a few different apps, though, 
including shell-hrd (log in my first post), which pretty much never uses 
urlfetch otherwise based on its quota numbers, so i doubt it's User-Agent 
blocking. i tried an entirely new www.instagram.com URL and still got a 
429, so it's probably not specific URLs, at least due to my own traffic. 
and i can fetch the same URL fine from my local machine. hence my IP 
suspicion.

i've already worked around this, so it's not urgent. just figured you all 
might want to know. thanks again!

On Monday, May 2, 2016 at 10:52:11 AM UTC-7, Nick (Cloud Platform Support) 
wrote:
>
> Hey Ryan,
>
> I'm unsure that this indicates that App Engine specifically is being 
> rate-limited. It's likely that the 429 response is directly related to the 
> frequency with which you're making requests, regardless of the origin of 
> those requests. While not impossible, I suppose, it would be surprising if 
> they were keeping track of App Engine IP ranges and applying a different 
> rate-limit, and would require some thorough A/B testing to prove. So, I 
> recommend just checking their documentation 
> <https://www.instagram.com/developer/limits/> or, if the rate-limit is 
> undocumented, benchmarking to attempt to determine it, and try to fly under 
> it. Generally, exponential-backoff 
> <https://en.wikipedia.org/wiki/Exponential_backoff> is a good tactic when 
> dealing with rate-limiting.
>
> Sincerely,
>
> Nick
> Cloud Platform Community Support
>
> On Monday, May 2, 2016 at 11:57:15 AM UTC-4, Nickolas Daskalou wrote:
>>
>> Hi Ryan,
>>
>> It seems to be working fine for us (SocialPage.me 
>> <https://socialpage.me/>).
>>
>> Are you accessing their API using separate access tokens for each user?
>>
>> Nick
>>
>>
>> On 2 May 2016 at 14:30, Ryan Barrett <goo...@ryanb.org > 
>> wrote:
>>
>>> hi all! just FYI, it looks like Instagram is blocking/rate limiting App 
>>> Engine's IPs from fetching www.instagram.com, both urlfetch and 
>>> sockets, across apps. e.g. this session from 
>>> https://shell-hrd.appspot.com/ :
>>>
>>> >>> urllib2.urlopen('https://www.instagram.com/snarfed/')
>>> Traceback (most recent call last):
>>> ...
>>>   File 
>>> "/base/data/home/runtimes/python/python_dist/lib/python2.5/urllib2.py", 
>>> line 506, in http_error_default
>>> raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
>>> HTTPError: HTTP Error 429: Unknown
>>>
>>> it's not 100% consistent - i occasionally see requests make it through - 
>>> but the majority get 429ed.
>>>
>>> not holding my breath, but i figured you all might want to know, 
>>> especially in case cloud support people have lines of communication open 
>>> with instagram/facebook for this kind of thing.
>>>
>>> -- 
>>> 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-appengi...@googlegroups.com .
>>> To post to this group, send email to google-a...@googlegroups.com 
>>> .
>>> Visit this group at https://groups.google.com/group/google-appengine.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/google-appengine/be7f6ead-fe34-45c4-9ee0-00956b5f89de%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/google-appengine/be7f6ead-fe34-45c4-9ee0-00956b5f89de%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/df130e09-f87b-40a7-bd4c-9ab0dc6fad0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Instagram blocking App Engine's urlfetch/sockets IP block

[Ryan Barrett]

hi all! just FYI, it looks like Instagram is blocking/rate limiting App 
Engine's IPs from fetching www.instagram.com, both urlfetch and sockets, 
across apps. e.g. this session from https://shell-hrd.appspot.com/ :

>>> urllib2.urlopen('https://www.instagram.com/snarfed/')
Traceback (most recent call last):
...
  File 
"/base/data/home/runtimes/python/python_dist/lib/python2.5/urllib2.py", 
line 506, in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 429: Unknown

it's not 100% consistent - i occasionally see requests make it through - 
but the majority get 429ed.

not holding my breath, but i figured you all might want to know, especially 
in case cloud support people have lines of communication open with 
instagram/facebook for this kind of thing.

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/be7f6ead-fe34-45c4-9ee0-00956b5f89de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Google Cloud -- Good for small programmes?

[ryan broman]

Thank you! All the libraries I need are pure Python, so the GAE shouldn't have 
any problem downloading them if I put it in the requirements.txt

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/ee51489d-fb95-4d36-a852-8b9a904ee831%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Google Cloud -- Good for small programmes?

[ryan broman]

I have a Python 3 programme that forms semicoherent sentences via Markov chains 
every 6 minutes and posts these sentences to a social network, and also 
sometimes interacts with its "friend"'s posts as well. It's small code and and 
it doesn't use much storage, maybe 10MB at max. 

Would Google Cloud be a good host for me to run my code on? All I need it to do 
is run my code as I would at home. 

Also, do you think this would remain under Google's free hosting cap?

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/a5d21dd5-0799-464f-99bc-b60ad794f4e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Recent Increase of 403 Errors

[Ryan Fagan]

We are seeing the 403 on all sites on every request to cloud endpoints at 
this time.

On Tuesday, February 9, 2016 at 3:23:35 AM UTC-7, Saket Kumar wrote:
>
> Hi,
>
> We are aware of an increase in 403 errors for Cloud Endpoints starting 
> 1300 (US/Pacific), 02/08. We are currently rolling out a fix that should be 
> available in next few hours.
>
>
> Thanks!
> Saket Kumar
> Google Cloud Platform Support.
>
>
>
> On Tuesday, 9 February 2016 03:29:53 UTC+1, John White wrote:
>>
>> The last two weeks I've seen an uptick of 403 responses come back from my 
>> endpoint.  It's been random.  At first it was only every once every hour or 
>> so.  Then over the last two weeks the 403 responses increased more and more 
>> until tonight things are almost unusable.  I can't get through to my 
>> endpoint and the data within datastore at all.
>>
>> Two different apps access the same endpoint.  One is a JavaFX app (JDK 8) 
>> developed in NetBeans.  The other is an Android app (JDK 7) being developed 
>> in Android Studio.  Here's the specifics of the GAE and endpoints version 
>> I'm using, taken from my build.gradle file of the endpoint backend within 
>> Android Studio:
>>
>> com.google.appengine:appengine-java-sdk:1.9.14
>>
>> com.google.appengine:appengine-endpoints:1.9.14
>>
>> com.google.appengine:appengine-endpoints-deps:1.9.14
>>
>>
>> Like I said, the 403 has been happening intermittently and increasing in 
>> volume, and it's happening during both read and write operations.  The 
>> response I get is very generic.  I read somewhere in the help docs here that 
>> the returned errors from the endpoint can sometimes return more detail.  
>> Would any one know how to capture that?  This is all I'm getting in my 
>> console:
>>
>>
>> com.google.api.client.googleapis.json.GoogleJsonResponseException: 403 
>> Forbidden
>> 
>> 
>> Forbidden
>> 
>> 
>> Forbidden
>> Error 403
>> 
>> 
>>
>>  at 
>> com.google.api.client.googleapis.json.GoogleJsonResponseException.from(GoogleJsonResponseException.java:145)
>>  at 
>> com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:113)
>>  at 
>> com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:40)
>>  at 
>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest$1.interceptResponse(AbstractGoogleClientRequest.java:312)
>>  at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1056)
>>  at 
>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:410)
>>  at 
>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:343)
>>  at 
>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:460)
>>  at 
>> com.white.chordkendev.services.PlayFieldViewService$1.call(PlayFieldViewService.java:46)
>>
>>
>> or, something like
>>
>>
>> 02-08 20:45:51.8776296-6596/com.nessylum.sudochord E/PlayFieldService﹕ 
>> findPlayFieldViews
>> com.google.api.client.googleapis.json.GoogleJsonResponseException: 403 
>> Forbidden
>> 
>> 
>> Forbidden
>> 
>> 
>> Forbidden
>> Error 403
>> 
>> 
>> at 
>> com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:113)
>> at 
>> com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:40)
>> at 
>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest$1.interceptResponse(AbstractGoogleClientRequest.java:312)
>> at 
>> com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1049)
>> at 
>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:410)
>> at 
>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:343)
>> at 
>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:460)
>> at 
>> com.nessylum.sudochord.service.PlayFieldServiceImpl.findPlayFieldViews(PlayFieldServiceImpl.java:123)
>>
>>
>> I had absolutely no problems of this kind before a couple weeks ago.  I 
>> haven't changed anything in the endpoint code within that time, nor anything 
>> in the JavaFX app's code.  Things are working fine when I debug against the 
>> endpoint deployed locally.  Sorry if I didn't provide enough detail, this is 
>> all I've been able to find so far.  Is anyone else having this problem?  
>>
>>

-- 
You received this message because you are 

Re: [google-appengine] Re: Recent Increase of 403 Errors

[Ryan Fagan]

This appears resolved for us at this time.

On Tuesday, February 9, 2016 at 8:11:38 AM UTC-7, Saket Kumar wrote:
>
> Hi Ryan,
>
> Can you please send me the App Id privately? This would let us verify if 
> these 403s are related.
>
> On 9 February 2016 at 16:07, Ryan Fagan <ry...@gannettpeaktech.com 
> > wrote:
>
>> We are seeing the 403 on all sites on every request to cloud endpoints at 
>> this time.
>>
>>
>> On Tuesday, February 9, 2016 at 3:23:35 AM UTC-7, Saket Kumar wrote:
>>>
>>> Hi,
>>>
>>> We are aware of an increase in 403 errors for Cloud Endpoints starting 
>>> 1300 (US/Pacific), 02/08. We are currently rolling out a fix that should be 
>>> available in next few hours.
>>>
>>>
>>> Thanks!
>>> Saket Kumar
>>> Google Cloud Platform Support.
>>>
>>>
>>>
>>> On Tuesday, 9 February 2016 03:29:53 UTC+1, John White wrote:
>>>>
>>>> The last two weeks I've seen an uptick of 403 responses come back from 
>>>> my endpoint.  It's been random.  At first it was only every once every 
>>>> hour 
>>>> or so.  Then over the last two weeks the 403 responses increased more and 
>>>> more until tonight things are almost unusable.  I can't get through to my 
>>>> endpoint and the data within datastore at all.
>>>>
>>>> Two different apps access the same endpoint.  One is a JavaFX app (JDK 
>>>> 8) developed in NetBeans.  The other is an Android app (JDK 7) being 
>>>> developed in Android Studio.  Here's the specifics of the GAE and 
>>>> endpoints 
>>>> version I'm using, taken from my build.gradle file of the endpoint backend 
>>>> within Android Studio:
>>>>
>>>> com.google.appengine:appengine-java-sdk:1.9.14
>>>>
>>>> com.google.appengine:appengine-endpoints:1.9.14
>>>>
>>>> com.google.appengine:appengine-endpoints-deps:1.9.14
>>>>
>>>>
>>>> Like I said, the 403 has been happening intermittently and increasing in 
>>>> volume, and it's happening during both read and write operations.  The 
>>>> response I get is very generic.  I read somewhere in the help docs here 
>>>> that the returned errors from the endpoint can sometimes return more 
>>>> detail.  Would any one know how to capture that?  This is all I'm getting 
>>>> in my console:
>>>>
>>>>
>>>> com.google.api.client.googleapis.json.GoogleJsonResponseException: 403 
>>>> Forbidden
>>>> 
>>>> 
>>>> Forbidden
>>>> 
>>>> 
>>>> Forbidden
>>>> Error 403
>>>> 
>>>> 
>>>>
>>>>at 
>>>> com.google.api.client.googleapis.json.GoogleJsonResponseException.from(GoogleJsonResponseException.java:145)
>>>>at 
>>>> com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:113)
>>>>at 
>>>> com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:40)
>>>>at 
>>>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest$1.interceptResponse(AbstractGoogleClientRequest.java:312)
>>>>at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1056)
>>>>at 
>>>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:410)
>>>>at 
>>>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:343)
>>>>at 
>>>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:460)
>>>>at 
>>>> com.white.chordkendev.services.PlayFieldViewService$1.call(PlayFieldViewService.java:46)
>>>>
>>>>
>>>> or, something like
>>>>
>>>>
>>>> 02-08 20:45:51.8776296-6596/com.nessylum.sudochord E/PlayFieldService﹕ 
>>>> findPlayFieldViews
>>>> com.google.api.client.googleapis.json.GoogleJsonResponseException: 403 
>>>> Forbidden
>>>> 
>>>> 
>>>> Forbidden
>>>> 
>>>> 
>>

Re: [google-appengine] Re: Recent Increase of 403 Errors

[Ryan Fagan]

Agreed, thank you.

Ryan

On Tuesday, February 9, 2016 at 10:20:10 AM UTC-7, Saket Kumar wrote:
>
> Thanks. This problem should have been resolved ~30 mins ago.
>
> On 9 February 2016 at 16:50, Ryan Fagan <ry...@gannettpeaktech.com 
> > wrote:
>
>> This appears resolved for us at this time.
>>
>> On Tuesday, February 9, 2016 at 8:11:38 AM UTC-7, Saket Kumar wrote:
>>>
>>> Hi Ryan,
>>>
>>> Can you please send me the App Id privately? This would let us verify if 
>>> these 403s are related.
>>>
>>> On 9 February 2016 at 16:07, Ryan Fagan <ry...@gannettpeaktech.com> 
>>> wrote:
>>>
>>>> We are seeing the 403 on all sites on every request to cloud endpoints 
>>>> at this time.
>>>>
>>>>
>>>> On Tuesday, February 9, 2016 at 3:23:35 AM UTC-7, Saket Kumar wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> We are aware of an increase in 403 errors for Cloud Endpoints starting 
>>>>> 1300 (US/Pacific), 02/08. We are currently rolling out a fix that should 
>>>>> be 
>>>>> available in next few hours.
>>>>>
>>>>>
>>>>> Thanks!
>>>>> Saket Kumar
>>>>> Google Cloud Platform Support.
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, 9 February 2016 03:29:53 UTC+1, John White wrote:
>>>>>>
>>>>>> The last two weeks I've seen an uptick of 403 responses come back 
>>>>>> from my endpoint.  It's been random.  At first it was only every once 
>>>>>> every 
>>>>>> hour or so.  Then over the last two weeks the 403 responses increased 
>>>>>> more 
>>>>>> and more until tonight things are almost unusable.  I can't get through 
>>>>>> to 
>>>>>> my endpoint and the data within datastore at all.
>>>>>>
>>>>>> Two different apps access the same endpoint.  One is a JavaFX app 
>>>>>> (JDK 8) developed in NetBeans.  The other is an Android app (JDK 7) 
>>>>>> being 
>>>>>> developed in Android Studio.  Here's the specifics of the GAE and 
>>>>>> endpoints 
>>>>>> version I'm using, taken from my build.gradle file of the endpoint 
>>>>>> backend 
>>>>>> within Android Studio:
>>>>>>
>>>>>> com.google.appengine:appengine-java-sdk:1.9.14
>>>>>>
>>>>>> com.google.appengine:appengine-endpoints:1.9.14
>>>>>>
>>>>>> com.google.appengine:appengine-endpoints-deps:1.9.14
>>>>>>
>>>>>>
>>>>>> Like I said, the 403 has been happening intermittently and increasing in 
>>>>>> volume, and it's happening during both read and write operations.  The 
>>>>>> response I get is very generic.  I read somewhere in the help docs here 
>>>>>> that the returned errors from the endpoint can sometimes return more 
>>>>>> detail.  Would any one know how to capture that?  This is all I'm 
>>>>>> getting in my console:
>>>>>>
>>>>>>
>>>>>> com.google.api.client.googleapis.json.GoogleJsonResponseException: 403 
>>>>>> Forbidden
>>>>>> 
>>>>>> 
>>>>>> Forbidden
>>>>>> 
>>>>>> 
>>>>>> Forbidden
>>>>>> Error 403
>>>>>> 
>>>>>> 
>>>>>>
>>>>>>  at 
>>>>>> com.google.api.client.googleapis.json.GoogleJsonResponseException.from(GoogleJsonResponseException.java:145)
>>>>>>  at 
>>>>>> com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:113)
>>>>>>  at 
>>>>>> com.google.api.client.googleapis.services.json.AbstractGoogleJsonClientRequest.newExceptionOnError(AbstractGoogleJsonClientRequest.java:40)
>>>>>>  at 
>>>>>> com.google.api.client.googleapis.services.AbstractGoogleClientRequest$1.interceptResponse(AbstractGoogleClientRequest.java:312)
>>>>>>  at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1056)
>>>>>>  at 
>>>>>> com.google.api.client.googleapis.services.AbstractGoo

[google-appengine] Virtual Staff 4U

[Ryan Down]

Virtual staff 4U will provide you with the best Starting a business is the 
most challenging part since this is where you make decisions on many 
factors.We at Virtual staff 4u can supply your company with the right 
candidate for your needs at the most competitive cost.

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/e1a066ee-d62b-4bcd-8695-6796256fff4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: I am not able to quantify what are App Engine Frontend Instance Hours

[Ryan (Cloud Platform Support)]

Anastasios hit the nail square on the head. Idle instances are instance 
that are doing nothing. When a request comes in it will start a 4th. With 
your setup it will be more aggressive in shutting down the spare instances 
that's all. They are meant to have instances always ready to take requests. 
Depending on the language you are using it is more or less important to 
have these. Python is the fastest to boot, so you don't need as many, Java 
is the longest to boot so you need more idle. If Anastasios assumptions are 
correct and there are no end user interactions you can leave it at 0 and 
just take a slight hit when you send your first request.

It looks like you want to only ever have 3 instances. You should use Manual 
scaling with instances set to 3.
If you have no need for instant response you can use basic 
with max_instances set to 3, this will scale down the number when they are 
not needed but cap at 3.

@Anastasios be careful using daily budget to limit the number of instances. 
When you reach the cap it will stop all traffic request and not do any work 
until it resets.

On Friday, October 23, 2015 at 1:41:00 AM UTC-4, Naresh Pokuri wrote:
>
> I have started my GAE app with *Auto-scaling* having *min-idle-instances 
> 3*, each with 1GB RAM and 2.4GHz processor(i.e *F4_1G*). And I have a 
> cron job which runs on every 5 minutes. With this setup keeping application 
> idle for one day should equal to 72 instance hours. But I see that it 
> already reached 428 instance hours. So, I am clueless here how GAE 
> calculates instance hours, with this alone I can keep my budget in control. 
> Can someone help me in this *instance hours*
>

-- 
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/27eb091a-b210-4d1c-86e2-1d38a143ac65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: referer spam, relentless!

[Ryan (Cloud Platform Support)]

Salutations EJ,

I will need some more information to investigate this. In the mean time 301 
redirect your site to a file that can be cached. This way it will stop 
hammering your site. I will then need the following information (feel free 
to private message me with the details):

App ID:
Full URL that is being hit:
Log sample showing the hits, more the better.

On Thursday, October 22, 2015 at 7:32:37 PM UTC-4, EJ Kowal wrote:
>
> I have an website I recently ported to GAE and we have an spammer hitting 
> us every .10 of a second with back_url=(url) spam. Looks like the previous 
> site may have been misconfigured.
>
> Anyways, the spammer is hitting the same page over and over again, just 
> with different back_url=(url). I checked and they are using quite an 
> extensive list of IP's so the Ddos won't work. Any other suggestions? 
>

-- 
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/3e3bc2b2-c080-4db8-91db-88e0590ef465%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Availability of Managed VM scale to zero

[Ryan (Cloud Platform Support)]

Salutations David,

Currently Managed VM's cannot scale to 0. It is mentioned in the docs under 
'Automatic scaling 
'. 

On Tuesday, October 20, 2015 at 7:30:17 PM UTC-4, David Cohen wrote:
>
> Hi,
>
> Would Managed VM instances be able to scale to zero? Any timeline for this?
>

-- 
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/e405eef5-47b0-406b-a760-2d27d4fbbc6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Availability of Managed VM scale to zero

[Ryan (Cloud Platform Support)]

If this something you feel we should do I would recommend filling out a 
Feature Request. When you do fill it out link it here and I will process it 
for you.


On Tuesday, October 20, 2015 at 7:30:17 PM UTC-4, David Cohen wrote:
>
> Hi,
>
> Would Managed VM instances be able to scale to zero? Any timeline for this?
>

-- 
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/f269b97c-d74b-4d48-a72f-caa5d354e603%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: New Console : Showing error "This operation is not possible because no App Engine application was found for this project." while opening controls under "Compute -> App Engine"

[Ryan (Cloud Platform Support)]

Salutations Edunext,

Can you send me a private message with the following information:

- App ID
- Screenshot of the error (I need the whole page)
- HAR file when clicking on Compute -> App Engine

Something to make sure of is the App ID at the top center. Make sure it is 
the proper project.

On Wednesday, October 7, 2015 at 6:00:53 AM UTC-4, Edunext Jain wrote:
>
>
> Dear Concern,
>
> I am getting subjected error while opening any of the menu under Compute 
> -> Appengine.
>
> This is an Appengine Project. Couldn't get any resolution.
>

-- 
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/322a4181-b355-4f4b-8115-5b465f4b30ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Bravo on very easy ssl integration!

[Ryan (Cloud Platform Support)]

Thank you Richard! There were/are many people who worked on it and I will 
relay your thanks to them.

On Sunday, October 4, 2015 at 11:19:56 AM UTC-4, Richard Cheesmar wrote:
>
> Well, it's hats off time to Google for the introduction of such simple SSL 
> integration. It really was very simple!
>
> A big well done! Bravo!
>

-- 
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/cc17a48e-8b03-4cd8-ba19-ce6413d2c240%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Custom Domains (and SSL)

[Ryan (Cloud Platform Support)]

Glad to hear your good to go!

On Tuesday, September 29, 2015 at 10:24:49 AM UTC-4, Jay wrote:
>
> I'm not sure if this question is best here or Stackoverflow. 
> I am looking to use the feature recently moved to the google cloud console 
> to add an SSL certificate. We are already using a custom domain.
> Here is the new thing I ran into. When I log in and look at a particular 
> project, on which we already have a custom domain setup, I see nothing. It 
> looks like we have not set anything up. A colleague of mine logs in and 
> does the same thing, on the same project, and he sees a custom domain 
> already configured. This is before we get to the stage of setting up the 
> SSL.
>
> So we are seeing two different things. This makes me nervous. It also 
> means that I can't, apparently, setup the SSL, he would have to do that. 
> Surely, the configuration here is not tied to the user in some way. I must 
> be missing something.
>
> Thanks for any insight or suggestions.
>
> -- Jay
>

-- 
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/abc01a30-5ea2-4837-aa4c-3a473f2b5df8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Post on Google plus Wall

[Ryan (Cloud Platform Support)]

Salutations,

Is this what you are looking for?  


On Monday, September 28, 2015 at 8:01:34 PM UTC-4, kcc pac wrote:
>
> hi all,
>
> I had tried using gplus.moment.insert to put a post on Google Plus Wall. 
> But, I got HTTP code of 500. After I further investigate on the API, I 
> found that moment api is no longer supported. Just wonder if there are 
> other means to post message on Google Plus Wall programmatically.
>
> Thanks.
>
> Colin
>

-- 
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/103fa37f-b024-4347-b556-5884a7446751%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Custom Domains (and SSL)

[Ryan (Cloud Platform Support)]

Salutations Jay, 

You may need to verify the domain yourself. You should see a banner at the 
top of the Customer domain page:

The custom domain feature has been migrated here from Google Apps. To get 
started, verify ownership of your domains by completing step 1.

Let me know if this helps.

On Tuesday, September 29, 2015 at 10:24:49 AM UTC-4, Jay wrote:
>
> I'm not sure if this question is best here or Stackoverflow. 
> I am looking to use the feature recently moved to the google cloud console 
> to add an SSL certificate. We are already using a custom domain.
> Here is the new thing I ran into. When I log in and look at a particular 
> project, on which we already have a custom domain setup, I see nothing. It 
> looks like we have not set anything up. A colleague of mine logs in and 
> does the same thing, on the same project, and he sees a custom domain 
> already configured. This is before we get to the stage of setting up the 
> SSL.
>
> So we are seeing two different things. This makes me nervous. It also 
> means that I can't, apparently, setup the SSL, he would have to do that. 
> Surely, the configuration here is not tied to the user in some way. I must 
> be missing something.
>
> Thanks for any insight or suggestions.
>
> -- Jay
>

-- 
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/28dbaaba-1c43-40c6-ad0f-df6ad579a40e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Are blob keys guessable?

[Ryan (Cloud Platform Support)]

I can't speak to how the keys are generated but take a look at the bellow 
keys. They are all the same file uploaded with the same code within a few 
moments of each other. They are unique enough it would take a bruit force 
attack to find a key that could be used:

AMIfv951k5FTlQxC-6nljafbiyiRJvWkcVhbuCbBvFcSu6cuf_IV2x1f_OIhkQ-Q1OnPp0HN6hKKbXMS4S_C3dgt5zGhQcWKHOZy2ALjOXVr20o9PhPWT8Wmbu4oxJU7gmAXfVQtttYBheQvpJFbOkH_qnilNdWmh_UYNiZjy_O9ioV_SJnH-PM

AMIfv954myPMnDkCeYlHSMUj2noCiBqD-BtaxwZw7Raf_LGg62IOlgOK44PpysRDX5BWEQE5NfzvtS-xVV4BL9kh1eH2lx7l5fWQWJSEQR8vL8JCAOq12A2LuzvUdLK3e9jwXNwx7UCVI1EeUipVXUvABT9tauNJ_DRBBlL8bqNE99QzfXijCFQ

AMIfv97UzePJVVqYjnxkAf5d_-tG88gzxp9DcttAeUdZ10NUpMTVmYG2QttDDOSNzztFzHVnRa4rcy-BWeLlN9ZRZzEEXI2TXWUIxn1tzwW_QgYSJP60YWb5bt_khIPnUAWIbij-FQEdMycGDada_it6WoPky5hCS0cjVtAJ4tr2p7NuRxIo2_c

AMIfv97MrdriwZpoTkLGxc2sEFwfXIMXwz7Dt3f7IH9Iljb9S57f6amI8ZB8H70VwfkLVOnPvhoDNW7iyTUhiqtafSsFu7L6w3U_qxqzaGJNez8XGLLYeZCwBUWRre-6eeodyTzzohB7zgrEvTp4j9B1K99HU5Secp2cZNW0VW4i9co-o352eqw

AMIfv95anW6Qio_APu5La6ZBAs9ZUvaXcO5x8JeN0CW0knMnLtCFSWiAFe0laElTfbguW71WPO7UpKtFK_ijUTSNOgvT6w2T-0YWKawlHaBvyVnDFRZAcdsbGdIeBAcQOnXsJ6D_dDkKLBi73SHTIXB9LTr_oZUbpVOxiLHQOZa8h58ubozYu0E

On Sunday, September 27, 2015 at 3:23:50 PM UTC-4, Rob Curtis wrote:
>
> Hi, 
>
> I can't find any information on this in the documentation;
> Are blob keys guessable? 
> Is it safe to expose stringified blob key to a user?
>
> Thanks
> Rob
>
>

-- 
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/160a6d4a-427d-4fba-83c6-c32d98f2d47d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Post on Google plus Wall

[Ryan (Cloud Platform Support)]

I do not *believe* there is. You might want to post on their Groups 
 or Issue Tracker 

 
to get more information.

On Monday, September 28, 2015 at 8:01:34 PM UTC-4, kcc pac wrote:
>
> hi all,
>
> I had tried using gplus.moment.insert to put a post on Google Plus Wall. 
> But, I got HTTP code of 500. After I further investigate on the API, I 
> found that moment api is no longer supported. Just wonder if there are 
> other means to post message on Google Plus Wall programmatically.
>
> Thanks.
>
> Colin
>

-- 
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/fa497eb2-19d5-40d1-bbff-a256399c1cff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Are blob keys guessable?

[Ryan (Cloud Platform Support)]

Salutations Rob

"The Blobstore value is assigned a unique, randomly generated key." [1]

The book was written by a Googler and is a good read.

[1] http://ae-book.appspot.com/chapters/blobstore

On Sunday, September 27, 2015 at 3:23:50 PM UTC-4, Rob Curtis wrote:
>
> Hi, 
>
> I can't find any information on this in the documentation;
> Are blob keys guessable? 
> Is it safe to expose stringified blob key to a user?
>
> Thanks
> Rob
>
>

-- 
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/f5615b93-9c7d-4494-bf4e-17bc4e72f242%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Upload .mp3 file in Google Cloud Storage using Java client JSON API.

[Ryan (Cloud Platform Support)]

Salutations Uttam,

Without knowing more about what you are trying to do high level and what 
errors you have it is difficult to help. From what I understand you need:

- The example you linked you can set the content type for the uploadStream
- You should use 'audio/mpeg'  

- To create a file stream on an mp3 you should read Jon Skeet's post. 


On Friday, September 25, 2015 at 10:09:14 AM UTC-4, Uttam Agarwal wrote:
>
>
> Thanks Les for reply.
>
> I found a link (
> https://cloud.google.com/storage/docs/json_api/v1/json-api-java-samples) 
> where it shows how to upload file in my bucket in Google Cloud Storage.
>
> But problem is in this example they show how to upload txt file 
> (content-type=text/plain) in bucket. 
>
> I found that for mp3 file, content type is audio/mpeg. But i can't 
> understand how i read mp3 file for InputStreamContent ?
> Can you please give me a soultion?
>
> Thanks
>
> Uttam
>

-- 
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/9abc8732-8d26-4451-ad19-d9ba3b4dd40f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Not able to see apps on Mangement console

[Ryan (Cloud Platform Support)]

Salutations Bina,

If you don't see them on the Developer Console 
 that generally means you are not 
listed on the project. If you PM me the app id's and a screenshot of the 
projects list  I can see if 
you are listed on them. Keep in mind for security reasons I cannot reveal 
who is listed on them.

On Thursday, September 24, 2015 at 11:38:38 PM UTC-4, Bina Ramamurthy wrote:
>
>
> I had some old apps on Google App Engine. I am able to access thru an URL, 
> but not able to see them on management console.
> I would like to enable billing on these apps.
>
> Bina
>

-- 
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/76052746-6204-4a53-a0db-54359272983a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Failure to set daily budget

[Ryan (Cloud Platform Support)]

Salutations Michael,

If you have already read this page 
 I would 
recommend contacting our Billing Experts 
.
 
They will be able to help you get up and running in no time.

On Thursday, September 24, 2015 at 1:54:22 AM UTC-4, Michael Wong wrote:
>
> Hi,
>
> Error occured when I tried to set daily quota. 'Failed to save settings. 
> An error occurred. Some settings may not have been updated successfully'. 
> The app is now running out of quotas.
>
> The same issue is reported before but not sure why it's fixed.
>
> https://groups.google.com/forum/#!msg/google-appengine/aSRCjOqzygI/ZEB0feGkMQAJ
>
>
> Thanks,
> Michael
>

-- 
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/e4f27c31-1d14-47ea-bc6a-47f2a38560ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Cloud Storage getImageServingUrl questions

['Ryan Bruyere' via Google App Engine]

Not with the getImageServingUrl. As you can see in the demo you don't lose
much. There might be other PHP tools out there to do what you need.

Google | Ryan Bruyere | GAE TSR | Prime | Vendor | rbruy...@google.com

[image: Cloud BigTable logo_1]

On Wed, Sep 23, 2015 at 10:32 AM, Paul Canning <p...@drawandcode.com> wrote:

> I'm guessing then there is no way to do this without cropping?
>
> On 23 September 2015 at 15:21, Ryan (Cloud Platform Support) <
> rbruy...@google.com> wrote:
>
>> Salutations Paul,
>>
>> Have you looked at the crop flag
>> <https://cloud.google.com/appengine/docs/php/refdocs/classes/google.appengine.api.cloud_storage.CloudStorageTools#method_getImageServingUrl>
>> ?
>>
>>
>> Original[image: OriginalImage]
>> Cropped[image: Image]
>> Not Cropped[image: Image]
>>
>>
>> On Wednesday, September 23, 2015 at 9:58:28 AM UTC-4, Paul Canning wrote:
>>>
>>> I have a page that loads in a lot of different sized images via AJAX,
>>> some "landscape" (1280x720) and some "portrait" (720x1280).
>>>
>>> I'd like to display them in Bootstrap 3, using the responsive image
>>> class.
>>>
>>> Ideally it'd be good to show all images using a max height limit, say
>>> 200px.
>>>
>>> Using getImageServingUrl's size option doesn't really do what I want, as
>>> this only serves a version where the dimension with the highest value is
>>> used.
>>>
>>> E.g a 1280x720 image sized to say 320, would have a width of 320 and a
>>> height of 180
>>>
>>> But a 720x1280 image has its height changed, to 320, with the wdith
>>> being 180.
>>>
>>> So I have two images, with heights of 180 and 320, which doesn't look
>>> right.
>>>
>>> Add in loads more images and the grid starts to look ugly.
>>>
>>> So is there a way to achieve a uniform grid where portrait and landscape
>>> images are resized to fit the grid better?
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Google App Engine" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/google-appengine/zOsPCICZQqo/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/ffc41374-38a7-4377-a56e-7c394043bed3%40googlegroups.com
>> <https://groups.google.com/d/msgid/google-appengine/ffc41374-38a7-4377-a56e-7c394043bed3%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> -
> Paul Canning
> [ software artist ]
> -
> [draw]
> digital creative studio
>
> +44 (0)151 329 0900
> Website <http://www.drawandcode.com/> / Twitter
> <https://twitter.com/DrawAndCode> / Facebook
> <https://www.facebook.com/drawandcode> / Vimeo
> <https://vimeo.com/drawandcode>
> -
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google App Engine" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-appengine/zOsPCICZQqo/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAH%2B40aPaDHUsUxbj1r%2BHhUh-ZLmd-S9T_ubUt0mrSdUSrXcfFA%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-appengine/CAH%2B40aPaDHUsUxbj1r%2BHhUh-ZLmd-S9T_ubUt0mrSdUSrXcfFA%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAJMgmtPTBAOhjijpegeU1QHTvKS7n4S90NwWE6Jt2Z1Uqn1aSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Transaction Failed Exception from a non-transactional .put()

[Ryan (Cloud Platform Support)]

Salutations Kartik,

Contention happens when you are doing to many writes per second. This is a 
great article on avoiding it. 
 If 
you give some more details as to what you are doing I might be able to give 
some more specific advice.

On Thursday, August 4, 2011 at 9:48:37 AM UTC-4, Joshua Smith wrote:
>
> This is a weird one.
>
> I have a cron that rolls up some data every few minutes.  Nothing too 
> complicated:
>
> class CollectStatsHandler(webapp.RequestHandler):
>   def get(self):
> nodes = NodeModel.gql("WHERE online = :1 and procs > :2", True, 
> 0).fetch(1000)
> sum = 0
> for n in nodes:
>   sum = sum + n.procs
> now = datetime.datetime.now().timetuple()
> hour = datetime.datetime(now[0], now[1], now[2], now[3])
> hourly = HourlyStatsModel.gql("WHERE hour = :1", hour).get()
> if not hourly:
>   hourly = HourlyStatsModel()
>   hourly.hour = hour
>   hourly.stats = str(sum)
> else:
>   hourly.stats = hourly.stats + "," + str(sum)
> hourly.put()
>
> I'm running on M/S, so every now and then I'll get timeouts or whatever, 
> but that's OK because this is really just for my internal "app health" 
> dashboard.
>
> Anyway, yesterday I got this exception:
>
> google.appengine.api.datastore_errors.TransactionFailedError@/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py:1074
>  
> (at least 2 occurrences)Handler:main.pyURL:
> http://mesonstreaming.appspot.com/admin/collectStatsStacktrace:
>
> Traceback (most recent call last):
>   File 
> "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py",
>  line 700, in __call__
> handler.get(*groups)
>   File "/base/data/home/apps/mesonstreaming/51.352130110004909428/main.py", 
> line 1677, in get
> hourly.put()
>   File 
> "/base/python_runtime/python_lib/versions/1/google/appengine/ext/db/__init__.py",
>  line 1006, in put
> return datastore.Put(self._entity, config=config)
>   File 
> "/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py",
>  line 467, in Put
> return PutAsync(entities, **kwargs).get_result()
>   File 
> "/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py",
>  line 658, in get_result
> results = self.__rpcs[0].get_result()
>   File 
> "/base/python_runtime/python_lib/versions/1/google/appengine/api/apiproxy_stub_map.py",
>  line 592, in get_result
> return self.__get_result_hook(self)
>   File 
> "/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py",
>  line 1385, in __put_hook
> self.check_rpc_success(rpc)
>   File 
> "/base/python_runtime/python_lib/versions/1/google/appengine/datastore/datastore_rpc.py",
>  line 1074, in check_rpc_success
> raise _ToDatastoreError(err)
> TransactionFailedError: too much contention on these datastore entities. 
> please try again.
>
>
> So we have a transaction failed error on a put which is NOT a transaction.
>
> And we have too much contention on an entity which is written once every 5 
> minutes by a cron.
>
> Huh?
>
> -Joshua
>
>

-- 
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/9e5c32f0-8d99-4d6a-b56e-1c6dba9e25c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Cloud Storage getImageServingUrl questions

[Ryan (Cloud Platform Support)]

Salutations Paul,

Have you looked at the crop flag 

? 


Original[image: OriginalImage]
Cropped[image: Image]
Not Cropped[image: Image]


On Wednesday, September 23, 2015 at 9:58:28 AM UTC-4, Paul Canning wrote:
>
> I have a page that loads in a lot of different sized images via AJAX, some 
> "landscape" (1280x720) and some "portrait" (720x1280).
>
> I'd like to display them in Bootstrap 3, using the responsive image class.
>
> Ideally it'd be good to show all images using a max height limit, say 
> 200px.
>
> Using getImageServingUrl's size option doesn't really do what I want, as 
> this only serves a version where the dimension with the highest value is 
> used.
>
> E.g a 1280x720 image sized to say 320, would have a width of 320 and a 
> height of 180
>
> But a 720x1280 image has its height changed, to 320, with the wdith being 
> 180.
>
> So I have two images, with heights of 180 and 320, which doesn't look 
> right.
>
> Add in loads more images and the grid starts to look ugly.
>
> So is there a way to achieve a uniform grid where portrait and landscape 
> images are resized to fit the grid better?
>

-- 
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/ffc41374-38a7-4377-a56e-7c394043bed3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Tutorial removed?

[Ryan (Cloud Platform Support)]

My pleasure! 

Happy Coding!


On Monday, September 21, 2015 at 3:44:50 AM UTC-4, Siyanda Simelane wrote:
>
> Hi Everyone
>  
> Just a question. Has the tutorial (see link below) removed from the 
> Internet? I am using this tutorial with my students and we really 
> appreciate if someone can point me to soemthing similar?
>  
> URL:  *http://googcloudlabs.appspot.com/whatgae.html* 
>  
>  
> Any assistance will be appreciated :)
>  
> Siyanda
>

-- 
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/b9866c03-a19f-402f-be47-8d74730fb363%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Tutorial removed?

[Ryan (Cloud Platform Support)]

Salutations Siyanda,

Without knowing what was in the tutorial you linked it is hard to give 
something similar. You can look at the standard tutorials for Python 
, Java 
 
or other common languages.

On Monday, September 21, 2015 at 3:44:50 AM UTC-4, Siyanda Simelane wrote:
>
> Hi Everyone
>  
> Just a question. Has the tutorial (see link below) removed from the 
> Internet? I am using this tutorial with my students and we really 
> appreciate if someone can point me to soemthing similar?
>  
> URL:  *http://googcloudlabs.appspot.com/whatgae.html* 
>  
>  
> Any assistance will be appreciated :)
>  
> Siyanda
>

-- 
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/b1bafad9-10cd-43c8-85d5-6266c83f7b48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Unable to get my new course online with CB 1.9

[Ryan (Cloud Platform Support)]

Salutations Cristián,

These kind of questions are best asked on Stack Overflow 
. It will hit 
a much larger audience and increase the chance of getting an answer. You 
should include more such as what you have tried, what you see in the 
console, what errors you see.

Generally when we see such issues it has to do with versions. I would 
recommend going to the console 

 and 
make sure the version you just deployed is the default. 

On Monday, September 21, 2015 at 12:30:22 AM UTC-4, Cristián Rizzi 
Iribarren wrote:
>
> I'm using the local dashboard to create a new course (besides the Power 
> Searching sample). Everything works fine with the local ports, I'm able to 
> add lessons, units, etc.
> When I deploy my app (using the "appcfg.py update ." command) the process 
> goes perfectly but when I access* myapp*.appspot.com I don't see my 
> course.
> Where do I find the course that I have created locally and deployed to 
> myapp domain?
> Because when I access my course locally it is on 
> locahost:8080/my_new_course, I expected that after the deployment my course 
> will be at: *myapp*.appspot.com/my_new_course (but it's not)
>
> I spent literally two entire days trying to know how to create a new 
> course locally using the dashboard and deploy it to my app domain and see 
> it online.
>
> Please help!!
> Kind regards,
>
> Cristián
>
>

-- 
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/bf7ecca9-87fd-4c65-969c-e6a6e7f24955%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Task Queue Rest API v1beta2 "you are not allowed to make this api call"

[Ryan (Cloud Platform Support)]

Lorenz is correct. e~ is for EU projects while s~ is for US projects.

On Thursday, August 20, 2015 at 10:42:31 AM UTC-4, paolo francia wrote:
>
> I'm trying to use the Google Task Queue Rest API from:
> https://developers.google.com/apis-explorer/#p/taskqueue/v1beta2/
> I'm directly trying to use in the above link the "Try It" function that 
> use my google account to test the call on the API.
>
> The API call "Lease" and "Get" of the task workfs fine and the response is 
> 200.
> But when I try to use the "Delete" tas I get:
>
> 403 OK
> - Show headers - 
>
> {
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "forbidden",
> "message": "you are not allowed to make this api call"
>}
>   ],
>   "code": 403,
>   "message": "you are not allowed to make this api call"
>  }
> }
>
>
>
> In my app engine java project I setup the pull queue to enable my google 
> user to access the queue
>
> myem...@gmail.com  
> myem...@gmail.com
>
>
> To get the 403 error message I had to use the prefix "s~" on the 
> projectname because if I try whitout this I get:"code": 400, "message": " 
> project name is invalid"
> I think it is not a permission issue, because if so, why the GET and LEASE 
> call works fine?
>
>
> Can anyone please help me to solve this issue?
>
> Thanks
> Paolo
>

-- 
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/3c04756b-c808-41c4-be8d-750c0d603af6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Rabbit hole of bugs with billing

['Ryan Bruyere' via Google App Engine]

Go to this link <https://console.developers.google.com/project>. It will
have a list of projects ids you are part of.

Google | Ryan Bruyere | GAE TSR | TELUS Prime | TELUS Vendor |
rbruy...@google.com



On Fri, Sep 4, 2015 at 9:06 PM, Richard Baron Penman <richar...@gmail.com>
wrote:

> Hello,
> that is the contact form I tried previously but the instructions to find
> the required ID's appears out of date.
>
>
> On Fri, Sep 4, 2015 at 10:06 PM, Ryan (Cloud Platform Support) <
> rbruy...@google.com> wrote:
>
>> Salutations Plumo,
>>
>> This is best way to contact sales
>> <https://support.google.com/cloud/contact/cloud_platform_billing?vid=1-635769722940788025-4287989966>.
>> Let me now if you have any issues.
>>
>> On Friday, September 4, 2015 at 4:42:52 AM UTC-4, Plumo wrote:
>>>
>>> Hello,
>>>
>>> I started being charged for an old app with $0 quota. Tried disabling
>>> billing but get a server error. Then tried contacting support but the
>>> instructions to fill in fields for the support ticket are out of date - no
>>> longer match the billing interface.
>>> Is there a direct email for billing support?
>>>
>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Google App Engine" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/google-appengine/bscHmCastcI/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/cadfcab5-b9ca-4978-a43a-59e22a82b99f%40googlegroups.com
>> <https://groups.google.com/d/msgid/google-appengine/cadfcab5-b9ca-4978-a43a-59e22a82b99f%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google App Engine" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-appengine/bscHmCastcI/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAOV1wRVnmaRnxOWgC-2F%2B6ZJqMqPGq%2BuzjzgBrCev9bnEeLcxw%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-appengine/CAOV1wRVnmaRnxOWgC-2F%2B6ZJqMqPGq%2BuzjzgBrCev9bnEeLcxw%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAJMgmtMhn%3DzjA_M0mYYZf5ntX800DZpxURq%2B5jFmXWsxHZLavw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Re: Rabbit hole of bugs with billing

['Ryan Bruyere' via Google App Engine]

To get the Billing ID click the 'cog' in the top right corner and click
'Billing accounts'. I will look into getting the page updated.

Google | Ryan Bruyere | GAE TSR | TELUS Prime | TELUS Vendor |
rbruy...@google.com



On Tue, Sep 8, 2015 at 10:09 AM, Ryan Bruyere <rbruy...@google.com> wrote:

> Go to this link <https://console.developers.google.com/project>. It will
> have a list of projects ids you are part of.
>
> Google | Ryan Bruyere | GAE TSR | TELUS Prime | TELUS Vendor |
> rbruy...@google.com
>
>
>
> On Fri, Sep 4, 2015 at 9:06 PM, Richard Baron Penman <richar...@gmail.com>
> wrote:
>
>> Hello,
>> that is the contact form I tried previously but the instructions to find
>> the required ID's appears out of date.
>>
>>
>> On Fri, Sep 4, 2015 at 10:06 PM, Ryan (Cloud Platform Support) <
>> rbruy...@google.com> wrote:
>>
>>> Salutations Plumo,
>>>
>>> This is best way to contact sales
>>> <https://support.google.com/cloud/contact/cloud_platform_billing?vid=1-635769722940788025-4287989966>.
>>> Let me now if you have any issues.
>>>
>>> On Friday, September 4, 2015 at 4:42:52 AM UTC-4, Plumo wrote:
>>>>
>>>> Hello,
>>>>
>>>> I started being charged for an old app with $0 quota. Tried disabling
>>>> billing but get a server error. Then tried contacting support but the
>>>> instructions to fill in fields for the support ticket are out of date - no
>>>> longer match the billing interface.
>>>> Is there a direct email for billing support?
>>>>
>>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Google App Engine" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/google-appengine/bscHmCastcI/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, 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/cadfcab5-b9ca-4978-a43a-59e22a82b99f%40googlegroups.com
>>> <https://groups.google.com/d/msgid/google-appengine/cadfcab5-b9ca-4978-a43a-59e22a82b99f%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Google App Engine" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/google-appengine/bscHmCastcI/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CAOV1wRVnmaRnxOWgC-2F%2B6ZJqMqPGq%2BuzjzgBrCev9bnEeLcxw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/google-appengine/CAOV1wRVnmaRnxOWgC-2F%2B6ZJqMqPGq%2BuzjzgBrCev9bnEeLcxw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/CAJMgmtPrnf20YoFcd8AWo_-4gBBOGPf%3DCEiHhRwMn7FdeO%3DWgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Rabbit hole of bugs with billing

[Ryan (Cloud Platform Support)]

Salutations Plumo,

This is best way to contact sales 
.
 
Let me now if you have any issues.

On Friday, September 4, 2015 at 4:42:52 AM UTC-4, Plumo wrote:
>
> Hello,
>
> I started being charged for an old app with $0 quota. Tried disabling 
> billing but get a server error. Then tried contacting support but the 
> instructions to fill in fields for the support ticket are out of date - no 
> longer match the billing interface.
> Is there a direct email for billing support?
>
>

-- 
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/cadfcab5-b9ca-4978-a43a-59e22a82b99f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Error message - Managed VMs can not be hosted in Europe

[Ryan (Cloud Platform Support)]

Salutations Michel,

As you discovered Managed VM's cannot be deployed to EU while it is in Beta 

. 


On Wednesday, September 2, 2015 at 8:48:09 PM UTC-4, Michel Pereira wrote:
>
> Hi.
>
> I'm doing some tests with Managed VMs following this [1] tutorial.
>
> But when I'm execute the command: gcloud preview app deploy ./app.yaml 
> --set-default --version demo
>
> I got this error:
>
> ERROR: (gcloud.preview.app.deploy) Server responded with code [400]:
>
>   Bad Request Unexpected HTTP status 400.
>
>   Managed VMs can not be hosted in Europe.
>
> Deleted [
> https://www.googleapis.com/compute/v1/projects/nerdao-managed/zones/us-central1-f/instances/gae-builder-vm-demo
> ].
>
> [1] https://cloud.google.com/appengine/docs/managed-vms/tutorial/step1
>

-- 
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/9caca3ed-8b32-4352-b00b-97611ba95023%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: The API call urlfetch.Fetch() was explicitly cancelled

[Ryan (Cloud Platform Support)]

Salutations,

You will see this error when there is a async urlfetch call (could be 
warped in another call) that is not done when the page is finished loading. 
You need to make sure any async calls are completed before finishing your 
load.

On Monday, August 31, 2015 at 10:08:36 PM UTC-4, 한우람 wrote:
>
> I am using the Spring scheduler.
>
> GCS file was deleted by the scheduler is running.
>
> "The API call urlfetch.Fetch () was explicitly cancelled." error occurred.
>
> I want to know why.
>

-- 
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/022025a5-198b-4de1-8771-95a9f39a0361%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: what is the gae api to retrieve the project number

[Ryan (Cloud Platform Support)]

Salutations James,

You should file a Feature Request 

 
to add that functionality. Be sure to include why you need the project 
number over the project id 

.

On Sunday, August 30, 2015 at 4:01:04 PM UTC-4, James Gilliam wrote:
>
> been googling for how to obtain the project number via a gae api and 
> cannot find it
>
> the number is located on the dashboard but i wanted to get it 
> programmatically
>
> thanks
>
>
>

-- 
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/7adb250e-525b-4423-92b0-e85832ca084f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Cant create Project on Cloud Console (Rate Limit Exceeded)

[Ryan (Cloud Platform Support)]

Salutations,

I took a look and the reason you cannot create a new project is that you 
have reached a limit of how many projects are allowed per user. To request 
that this limit is increased please fill out the form at:

https://support.google.com/code/contact/project_quota_increase 

To other users reading this thread, if you get a similar error with only a 
few projects, you may have reached a limit of how many projects are allowed 
per billing account. To request that this limit is increased please fill 
out the form at:

https://support.google.com/code/contact/billing_quota_increase

After filling out this form you will get a response within 48 hours. You 
may be asked for further details or changes if necessary.

On Monday, August 31, 2015 at 8:32:25 AM UTC-4, Oyewale Oyediran wrote:
>
>
> I cant seem to create a new project on the Google Cloud console.
> I have tried over several days but i keep getting the Rate Limit errors.
>
> Is there a limit to the amount of project one can create? I have deleted a 
> few projects, just in case.
> I have about 30 projects setup
>

-- 
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/62198c27-3df3-458a-b90a-9d5de5f7469e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Native access to Search API from PHP on App Engine - Get it here!

[Ryan (Cloud Platform Support)]

Salutations Tom, 

Thank you for your work!

On Thursday, August 27, 2015 at 5:42:24 PM UTC-4, Tom Walder wrote:

 Hi all,

 For anyone that's interested, I've published an alpha version of a library 
 for accessing the App Engine Search API.

 At the time of writing, this is only available from Python/Java/Go with 
 the SDK's provided by Google.

 So, here it is for those of us using PHP.

 https://github.com/tomwalder/php-appengine-search

 It uses the low-level Protocol Buffer access - just like the 
 Python/Java/Go implementations.

 Enjoy - feedback appreciated!!

 Tom


-- 
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/518d987a-a3af-4c1b-9817-d7f7bd44bc2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: [PHP] Datastore.php / Windows Dev AppEngine produces CGI/FastCGI

[Ryan (Cloud Platform Support)]

Salutations Markus,

We are currently investigating this. I have created a Issue Tracker 
https://code.google.com/p/googleappengine/issues/detail?id=12287 and I 
recommended 'Staring' the issue so you can get updates.

On Thursday, August 20, 2015 at 5:50:01 AM UTC-4, Markus Frosch wrote:

 I'm using AppEngine under Windows for development. I've tried to create 
 data in Datastore.

 Unfortunately CGI/FastCGI will gone every time I call the demo script 

 https://github.com/amygdala/appengine_php_datastore_example/blob/master/datastore_connect.php


 https://cloud.githubusercontent.com/assets/1529283/9351156/5c24848a-4657-11e5-91e1-43a3e0631f98.png


 I've found that this line is producing the issue.

 $service_dataset-commit($dataset_id, $req, []);


 After looking to the Datastore.php from this lib I've replaced return 
 value by a simple return.

   /**

* Commit a transaction, optionally creating, deleting or modifying some
* entities. (datasets.commit)
*
* @param string $datasetId Identifies the dataset.
* @param Google_CommitRequest $postBody
* @param array $optParams Optional parameters.
* @return Google_Service_Datastore_CommitResponse
*/
   public function commit($datasetId, 
 Google_Service_Datastore_CommitRequest $postBody, $optParams = array())
   {
 $params = array('datasetId' = $datasetId, 'postBody' = $postBody);
 $params = array_merge($params, $optParams);
 return;
 return $this-call('commit', array($params), 
 Google_Service_Datastore_CommitResponse);
   }

 The issue was gone. As expected without data in the Google Datastore.

 After deploying this to the cloud the script is working well. So I think 
 it's only a local issue.
 Is there anybody who have/has the same issue?




-- 
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/da8eed80-4563-4251-90dc-62bce71dfaeb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.