[google-appengine] App Engine PHP developers… the Google Cloud team needs you!

[wesley chun]

Six weeks ago, the Google Cloud serverless team released many of the
original App Engine APIs/bundled services

for most of the second-generation runtimes (Python 3, Java 11, Go 1.12+),
and PHP 7 is next! To ensure product readiness for customer workloads,
we're seeking App Engine app developers ready to upgrade their apps to PHP
7. Here is a chart illustrating the available services (Datastore,
Memcache, Task Queues, URLfetch, Mail, Users):


Please sign-up at this form  to
request access to the private preview program. After registering, we will
grant access to the private preview, its documentation, and the
announcements mailing list. For more information, see this thread
 in the App Engine Subreddit.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A computer never does what you want... only what you tell it."
wesley chun :: @wescpy  :: Software
Architect & Engineer
Developer Advocate at Google
 by day; at
night: Core Python 

-- 
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/CAB6eaA7do5GqLRr6K9e6%3DgieByBT%3DeRj%2BxyfkfTDkjmJMz2BvA%40mail.gmail.com.

[google-appengine] Re: App Engine Flex ERROR: (gcloud.beta.app.deploy) NOT_FOUND

['wokmou' via Google App Engine]

Could you also execute your command with --verbosity to debug it. As it 
appears there is a missing file during you deployment.

On Wednesday, November 10, 2021 at 11:15:28 AM UTC-5 
matt.lo...@googlemail.com wrote:

> Hello,
>
> I have a collection of App Engine Flex services that are deployed using 
> `gcloud beta app deploy` due to needing the `beta_settings` app.yaml 
> property in order to connect to a Cloud SQL instance (
> https://cloud.google.com/sql/docs/mysql/connect-app-engine-flexible#public-ip-default_1
> ).
>
> These deployment processes are executed using GitLab's CI/CD and have been 
> untouched for around a year.
>
> Yesterday these deployments started failing with the following error (Both 
> as part of the GitLab pipeline and on my local machine):
>
> *Please bear in mind I've removed all of the account specific data.*
>
> gcloud beta app deploy app.yaml
> Services to deploy:
>
> descriptor:  [pathtoyaml\app.yaml]
> source:  [ pathtoyaml  ]
> target project:  []
> target service:  []
> target version:  []
> target url:  [https://appengineservice.appspot.com]
> target service account:  [App Engine default service account]
>
>
> Do you want to continue (Y/n)?  y
>
> Beginning deployment of service [ appengineservice  ]...
> ##
> #= Uploading 0 files to Google Cloud Storage=#
> ##
> File upload done.
> Updating service [ appengineservice  ] (this may take several 
> minutes)...done.
> ERROR: (gcloud.beta.app.deploy) NOT_FOUND: Requested entity was not found.
>
>
> *If I run the command with --log-http I can see the following request at 
> the bottom which returns the error in question*
>
> ===
>  request start 
> uri: 
> https://cloudbuild.googleapis.com/v1/projects/topsify-tools/locations/global/builds/ca6dfd3d-eeb4-4748-8fd5-930257e47b64?alt=json
> method: GET
> == headers start ==
> b'accept': b'application/json'
> b'accept-encoding': b'gzip, deflate'
> b'authorization': --- Token Redacted ---
> b'content-length': b'0'
> b'user-agent': b'google-cloud-sdk gcloud/364.0.0 
> command/gcloud.beta.app.deploy 
> invocation-id/d1f77d7d4a28468d91c14ca149993995 environment/None 
> environment-version/None interactive/True from-script/False python/3.8.10 
> term/ (Windows NT 10.0.19042)'
> == headers end ==
> == body start ==
>
> == body end ==
>  request end 
>  response start 
> status: 404
> -- headers start --
> -content-encoding: gzip
> alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; 
> ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; 
> ma=2592000,quic=":443"; ma=2592000; v="46,43"
> cache-control: private
> content-length: 114
> content-type: application/json; charset=UTF-8
> date: Wed, 10 Nov 2021 11:32:52 GMT
> server: ESF
> transfer-encoding: chunked
> vary: Origin, X-Origin, Referer
> x-content-type-options: nosniff
> x-frame-options: SAMEORIGIN
> x-xss-protection: 0
> -- headers end --
> -- body start --
> {
>   "error": {
> "code": 404,
> "message": "Requested entity was not found.",
> "status": "NOT_FOUND"
>   }
> }
>
> -- body end --
> total round trip time (request+response): 0.294 secs
>  response end 
> --
>
> Apologies if this is something that I'm doing from my end as I haven't 
> seen any other reports of this issue aside from a single thread on Stack 
> Overflow that was started yesterday.
>
> Thank you in advance & if you have any question please don't hesitate to 
> ask.
>
> Thanks,
> Matt.
>
>

-- 
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/cc3f55bf-a7f4-45eb-bb74-7e240648eba7n%40googlegroups.com.

[google-appengine] App Engine Flex ERROR: (gcloud.beta.app.deploy) NOT_FOUND

['Matt Lowden' via Google App Engine]

Hello,

I have a collection of App Engine Flex services that are deployed using 
`gcloud beta app deploy` due to needing the `beta_settings` app.yaml 
property in order to connect to a Cloud SQL instance 
(https://cloud.google.com/sql/docs/mysql/connect-app-engine-flexible#public-ip-default_1).

These deployment processes are executed using GitLab's CI/CD and have been 
untouched for around a year.

Yesterday these deployments started failing with the following error (Both 
as part of the GitLab pipeline and on my local machine):

*Please bear in mind I've removed all of the account specific data.*

gcloud beta app deploy app.yaml
Services to deploy:

descriptor:  [pathtoyaml\app.yaml]
source:  [ pathtoyaml  ]
target project:  []
target service:  []
target version:  []
target url:  [https://appengineservice.appspot.com]
target service account:  [App Engine default service account]


Do you want to continue (Y/n)?  y

Beginning deployment of service [ appengineservice  ]...
##
#= Uploading 0 files to Google Cloud Storage=#
##
File upload done.
Updating service [ appengineservice  ] (this may take several 
minutes)...done.
ERROR: (gcloud.beta.app.deploy) NOT_FOUND: Requested entity was not found.


*If I run the command with --log-http I can see the following request at 
the bottom which returns the error in question*

===
 request start 
uri: 
https://cloudbuild.googleapis.com/v1/projects/topsify-tools/locations/global/builds/ca6dfd3d-eeb4-4748-8fd5-930257e47b64?alt=json
method: GET
== headers start ==
b'accept': b'application/json'
b'accept-encoding': b'gzip, deflate'
b'authorization': --- Token Redacted ---
b'content-length': b'0'
b'user-agent': b'google-cloud-sdk gcloud/364.0.0 
command/gcloud.beta.app.deploy 
invocation-id/d1f77d7d4a28468d91c14ca149993995 environment/None 
environment-version/None interactive/True from-script/False python/3.8.10 
term/ (Windows NT 10.0.19042)'
== headers end ==
== body start ==

== body end ==
 request end 
 response start 
status: 404
-- headers start --
-content-encoding: gzip
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; 
ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; 
ma=2592000,quic=":443"; ma=2592000; v="46,43"
cache-control: private
content-length: 114
content-type: application/json; charset=UTF-8
date: Wed, 10 Nov 2021 11:32:52 GMT
server: ESF
transfer-encoding: chunked
vary: Origin, X-Origin, Referer
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 0
-- headers end --
-- body start --
{
  "error": {
"code": 404,
"message": "Requested entity was not found.",
"status": "NOT_FOUND"
  }
}

-- body end --
total round trip time (request+response): 0.294 secs
 response end 
--

Apologies if this is something that I'm doing from my end as I haven't seen 
any other reports of this issue aside from a single thread on Stack 
Overflow that was started yesterday.

Thank you in advance & if you have any question please don't hesitate to 
ask.

Thanks,
Matt.

-- 
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/40cfda3a-5a39-464b-8db3-06cd21a38832n%40googlegroups.com.

[google-appengine] Re: Updates from the Google App Engine team (Fall 2021)

['Matt Larkin' via Google App Engine]

>The new library still seems to be missing the BlobstoreDownloadHandler 
that would allow the end user to be redirected to download the file. This 
basically set a header and the platform would deliver the blob to the 
client.

Yes, the Public Preview 
 of 
the App Engine bundled services currently does not have the handlers 
implementation (for Blobstore, Mail, or Deferred).  Those handlers relied 
on the webapp framework, so we had to update them to allow use with 
idiomatic web frameworks (e.g., Flask, Django, etc.).  We are actually 
getting ready to launch the Blobstore & Mail handlers into the Private 
Preview (deferred is already available), so if you are interested in 
testing, please fill out this registration 
.  Once we have validated the updated 
design, we will be launching support for the handlers into Public Preview, 
so the more testing/feedback we get in Private Preview, the faster that can 
happen.

On Monday, November 8, 2021 at 4:53:27 PM UTC-8 will@friesenpress.com 
wrote:

> Hi,
>
> Thanks for the follow up. The articles detail the process fine if the 
> underlying blobs are "on" cloud storage. In my case I'm talking about 
> legacy blobs stored outside of the my visible buckets. They're not 
> represented in cloud storage and the python 3 runtime does not seem to have 
> a way to access them from what would be the remaining blobkey references. 
> From my understanding my legacy blobs would not have a corresponding 
> "gs_object_name" that would facilitate me accessing them. That is also very 
> much moot on the new runtime since it doesn't provide the BlobInfo api 
> where I would be able to access the gs_object_name property.
>
> I have a feeling the new "appengine-python-standard" library will provide 
> a partial answer as it looks like it will expose some of the old Blobstore 
> APIs that I would need to continue to access legacy blobs that are not 
> listed in an assessable bucket. 
>
> The new library still seems to be missing the BlobstoreDownloadHandler 
> that would allow the end user to be redirected to download the file. This 
> basically set a header and the platform would deliver the blob to the 
> client.
> On Monday, November 8, 2021 at 1:55:41 PM UTC-8 amit...@google.com wrote:
>
>> Hi,
>>
>> I believe you are referring to this 
>> 
>>  
>> for python 2. While taking a look into this , I have found two stack 
>> overflow posts recommending to use Cloud Storage here 
>> 
>>  
>> and here 
>> 
>>  while 
>> using python 3. You can check if any of those fits into your use case.
>> On Monday, November 8, 2021 at 12:38:40 PM UTC-5 
>> will@friesenpress.com wrote:
>>
>>> I'm slowly moving my way towards a migration path to the new Python 3 
>>> runtime. 2022 is the year. I've been a AppEngine customer since 2009 - so 
>>> I've already seen my share of smaller migrations as the oldest of the 
>>> services died off. 
>>>
>>> I currently have a question about Blobstore. As I'm planning to decouple 
>>> services in preparation for the first of many migrations I'm wondering 
>>> about all my old blobs. All my new blobstore files, as of summer of last 
>>> year, are in the default cloud storage bucket and I'm keeping track of the 
>>> "gs_object_name" 
>>> so that they'll continue to be easy to work with as I migrate which is nice.
>>>
>>> The real question is after I move my apps to the Python3 runtime how 
>>> will I access my legacy blobs? I see that cloud NDB "supports" blobkeys and 
>>> I currently I'd use "blobstore_handlers.BlobstoreDownloadHandler" and 
>>> "send_blob" to allow my users to download their files. I literally have a 
>>> decade of stored blobkeys that I would like to be able to service after I 
>>> move to the new runtime. I see that "send_bob" puts the blobkey in a header 
>>> which I assume is picked up by the platform to deliver the file to the end 
>>> user. Please point me in the right direction if you can!
>>>
>>> On Thursday, November 4, 2021 at 7:47:52 AM UTC-7 Wesley C (Google) 
>>> wrote:
>>>
 App Engine and Google Cloud serverless users:

 The App Engine  team at Google Cloud 
  had a flurry of announcements and product 
 updates over the past few months. In case you missed them, we've 
 summarized 
 them here with relevant links.


- 

New features to better secure your Google App Engine apps 

 
  

Re: [google-appengine] Re: Updates from the Google App Engine team (Fall 2021)

[Kaan]

Numbers aren't supporting me as well 
:D https://trends.google.com/trends/explore?date=all&q=python,javascript - 
somehow JS is dying while Python is thriving

But my point is, I loved App Engine because it was agile and practical, 
with JS and the new unleashed services, the experience is just incredible, 
apart from the regular flexibility, no more python platform-specific bugs 
and quirks to constantly chase, you have npm and your package.json and it 
just works anywhere!

However the new services aren't designed and documented as well, a concrete 
example is NodeJS datastore and the "Already Exists" exception, in the docs 
that I've read a while ago, there was no exception handling, it's not that 
hard to manually reproduce this exception and handle it, but still, it 
would be nice to have all the exception codes in one place, as the new JS 
library isn't really transactional like ndb was, it doesn't auto retry etc. 
- so most of the implementation is up to the user now - and after 
experiencing the Python2/NDB era and that masterpiece level design, the new 
JS counterparts just make you want to cry

On Tuesday, November 9, 2021 at 9:36:20 PM UTC+3 Alex Martelli wrote:

> On Mon, Nov 8, 2021 at 10:47 PM Kaan  wrote:
>...
>
>> And a plug: Python in my opinion is dying, while JS / NodeJS is thriving
>>
>
> According to TIOBE , in October 
> Python was language #3 in terms of popularity (behind Java and C); in 
> November, it vaulted to first place, "end[ing] C and Java's 20-year reign 
> atop the TIOBE index" as TechRepublic 
> 
>  
> titled their article -- "just one more feather in Python's ever-plumier 
> hat", as their subtitle has it, and "Python's latest win is just another in 
> its long line of toppling long-standing language leaders", as they write in 
> the body of the article (Python is also the most popular programming 
> language according to the IEEE study 
> , the most "wanted" 
> language according to StackOverflow's survey 
> ,
>  
> the "AI lingua franca" according to datanami 
> ,
>  
> and so forth). Javascript is #7 on TIOBE's list and #5 on the IEEE's, by 
> the way.
>
> Alex
>

-- 
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/7a5cd18a-ecc4-423b-9920-b78db019ac7bn%40googlegroups.com.