Status Update
Comments
gs...@google.com <gs...@google.com> #2
You are not the only one requesting a procedure to easily move a project from a region to another. Unfortunately, this is not possible at the moment, as indicated on the “Managing Cloud Platform Projects, App Engine Applications, and Billing” page. [1] 'Note the following limitations: You cannot change the location after the project has been created.'
Developers are aware of the feature requests for changing the sole-region rule, and this situation might change in future, but no clear plans have been disclosed as yet.
[1]
je...@gmail.com <je...@gmail.com> #3
This was actually meant as a "feature request". I just did not see any option to mark it as such.
Thanks.
ng...@google.com <ng...@google.com> #4
I will change this to a feature request and forward your report to the engineering team. Any questions, comments and updates they may have will be posted here.
ng...@google.com <ng...@google.com> #5
ju...@google.com <ju...@google.com>
ng...@google.com <ng...@google.com> #6
gs...@google.com <gs...@google.com>
ng...@google.com <ng...@google.com>
el...@gmail.com <el...@gmail.com> #7
i find absolutely incredible that i would have to delete all VM, GKE clusters, buckets, container registries,etc,etc in a project to just delete a google appengine project.
je...@gmail.com <je...@gmail.com> #8
ge...@geoloeg.world <ge...@geoloeg.world> #9
bo...@cbn-it.ro <bo...@cbn-it.ro> #10
sb...@gmail.com <sb...@gmail.com> #11
as...@gmail.com <as...@gmail.com> #12
[Deleted User] <[Deleted User]> #13
de...@gmail.com <de...@gmail.com> #14
It seems that the only way now is to migrate the DB in a new project, isn't it?
jo...@gmail.com <jo...@gmail.com> #15
[Deleted User] <[Deleted User]> #16
Is there an ETA for that feature ?
ke...@gmail.com <ke...@gmail.com> #17
Not being able to change the region of an App Engine app after creation is reasonable in and of itself - just as you can’t change the location of a GCS bucket or BigQuery dataset after creation.
However, only one app per project is a crazy restriction in the context of Google Cloud Platform in 2018. If one of our users creates an app with the wrong region, we then need to go through the whole project provisioning lifecycle again, and using some contrived project ID - the original project ID being written off, never to be used again.
While fixing this may seem like a lower priority than shiny new features, it creates a lot of negative goodwill about GCP and feels indefensibly legacy.
[Deleted User] <[Deleted User]> #18
[Deleted User] <[Deleted User]> #19
The fact we need to create a new project to change app engine's zone just makes us not use it.
Truly baffling.
si...@gmail.com <si...@gmail.com> #20
[Deleted User] <[Deleted User]> #21
ir...@hotmail.com <ir...@hotmail.com> #22
At least let us create more than one app in a project.
ro...@gmail.com <ro...@gmail.com> #23
xt...@gmail.com <xt...@gmail.com> #24
moving out inspite of spending around 50,000USD on a monthly basis on
appengine.
On Sun, Oct 14, 2018, 6:47 AM <buganizer-system@google.com> wrote:
mp...@google.com <mp...@google.com> #25
First off, we understand how painful this is. Short term I don't have any good answers. Long term we're aiming for something better.
I will (briefly) argue rationale: Doing so would require moving all the data and metadata on your behalf, which is likely to be expensive and time consuming. Making it easy is therefore not desirable from a platform perspective.
App Engine in particular would require migration of the compute (and all the app metadata) as well as all the data and metadata associated with all the component services (datastore, blobstore/GCS, memcache, tasks, scheduler, etc.).
In this respect, GAE is consistent with all other GCP products, which is consistent with other public cloud infrastructure. I don't know of an example of a product that lets you do seamless regional migrations (if someone does, please link it, I'd love to find out how they do it).
Most of the time the answer is: create a new resource in the desired region, migrate data. If you want the same name, you might need to delete the existing resource after saving the data to a temp location before re-creating the resource in the desired region and importing data.
That all said, it's clearly not consistent with customer desire. There are a few things that make location restriction more painful than it needs to be:
1. Restriction of one app per project
2. It's too easy to accidentally create a GAE app in your project (likely in the wrong region)
3. Lack of easy ability to do cross-project load balancing/traffic splitting
4. Highly bundled services mean that migration involves N resources
Let's tackle these one by one:
1. At present, you can only have one GAE app per project. This is inconsistent with much of GCP that allows you to have multiple resources (in different regions). I believe Datastore is the exception here (due to GAE heritage). At present we don't have a plan to remove this restriction (it's baked into 10 years of legacy), but are making sure we don't make the same choice with new products (e.g. GCF).
2. There are lots of ways to "accidentally" create a GAE app in one region (e.g. via Firebase) and be locked into that region in the project. We likely still have work to do making these restrictions clear.
3. GAE isn't integrated with GCLB, so you can't have multiple GAE backends on a single custom domain and migrate via traffic splitting. We are working on GCLB integration, which will hopefully make this possible in the future.
4. Our long term goal involves unbundling App Engine compute from the various services (Datastore, Blobstore/GCS, Memcache, etc.), which might make it easier to offer single migrations (like what Datastore and GCS offer today).
So, what can you do:
- GCF doesn't have these restrictions, so you can create N functions in M regions in a single project
- Our new serverless containers offering (currently in Alpha, sign up at
- Migration of data services:
- Datastore has managed import/export:
- GCS offers the transfer service:
For those migrating to other solutions: are they actually offering this feature? Or do the restrictions above not exist thus it's easier to stomach region lock?
ke...@gmail.com <ke...@gmail.com> #26
In my view, this issue only exists because of the 1 GAE app per project limitation. As you say, there are few if any public cloud services that offer free, on-the-fly location moves for existing resources (G Suite may actually be one recent exception?), and I don’t think this expectation would exist if it wasn’t for the aforementioned limitation.
The legacy is what it is (and I guess made more sense in a world where a GCP project was a GAE app and nothing more). However, would a pragmatic compromise be to add logic to at least allow for the teardown of the GAE app and corresponding location setting in a project? It would then be up to your customers to preserve state and/or redeploy as necessary, but at least they would have that possibility without being forced to create a new project.
mp...@google.com <mp...@google.com> #27
dp...@onekingslane.com <dp...@onekingslane.com> #28
[Deleted User] <[Deleted User]> #29
yd...@shaderlab.com <yd...@shaderlab.com> #30
mp...@google.com <mp...@google.com> #31
#29: I just walked through the in-console tutorial, and it looks like `gcloud app create` provides an interactive "choose the region where you want your App Engine application" picker. It's also got the warning about region permanence. Or am I looking at the wrong tutorial?
#30: Like Flex, serverless containers will let you deploy a container in a fully managed environment. Unlike Flex, we'll scale it down to zero (so the billing model is different). We'll also give you multiple containers per project, and the ability to have containers in different regions within the same project. Global load balancing is a feature that will come through GCLB integration (
le...@settle.eu <le...@settle.eu> #32
mp...@google.com <mp...@google.com> #33
ke...@gmail.com <ke...@gmail.com> #34
bo...@cbn-it.ro <bo...@cbn-it.ro> #35
mp...@google.com <mp...@google.com> #36
ke...@gmail.com <ke...@gmail.com> #37
It seems strange given this limitation that you continue to build new services on top of this architecture - eg, Cloud Scheduler announced today.
mp...@google.com <mp...@google.com> #38
[Deleted User] <[Deleted User]> #39
Looking forward to being able to delete & recreate our GAE app!
mp...@google.com <mp...@google.com> #40
Yeah, there's a lot of work that needs to be done to decouple those products (as well as Datastore) from GAE infra. We're working on it, but they're unfortunately pretty deep in the stack so it's taking a long time.
st...@gmail.com <st...@gmail.com> #41
The majority of App Engine tutorials don't mention the "gloud app create" step, but simply skip straight to "gcloud app deploy". The same is the case of the web console.
Would it be possible to present the region picker when running "gcloud app deploy" for the first time?
mp...@google.com <mp...@google.com> #42
mp...@google.com <mp...@google.com>
je...@jefflaplante.com <je...@jefflaplante.com> #43
no...@homedepot.com <no...@homedepot.com> #44
pe...@gmail.com <pe...@gmail.com> #45
cm...@gmail.com <cm...@gmail.com> #46
[Deleted User] <[Deleted User]> #47
ka...@xsimple.org <ka...@xsimple.org> #48
ka...@gmail.com <ka...@gmail.com> #49
ke...@gmail.com <ke...@gmail.com> #50
If so, that is understandable, but how do we get features that engineers/developers want and would make them more productive prioritised, even if they’re not sexy features for marketing purposes?
va...@gmail.com <va...@gmail.com> #51
yo...@gmail.com <yo...@gmail.com> #52
el...@gmail.com <el...@gmail.com> #53
ro...@gmail.com <ro...@gmail.com> #54
kw...@cei.ventures <kw...@cei.ventures> #55
ni...@gmail.com <ni...@gmail.com> #56
sa...@connectedjourneys.co.nz <sa...@connectedjourneys.co.nz> #57
dp...@onekingslane.com <dp...@onekingslane.com> #58
Also, my apologies for spamming you all with this email, but I'm hoping that it saves us at least a few spam messages in the future.
[Deleted User] <[Deleted User]> #59
It's critical for many projects, and it would give a ton of value even being able to just delete and recreate GAE.
ke...@gmail.com <ke...@gmail.com> #60
I suspect this is rarely an issue which will mean GCP loses a multi-million dollar deal to another public cloud provider, but among existing users of GCP it creates huge negative sentiment, and just feels a bit rubbish and hard to defend. Does Google have a budget to chip away at some things in that category? This issue is in the top 15 App Engine issues on the Issue Tracker after all.
[Deleted User] <[Deleted User]> #61
Thats really the only information we need.
[Deleted User] <[Deleted User]> #62
er...@gmail.com <er...@gmail.com> #63
Now it's very hard to explain to the same business people that they cannot move their GAE app into Europe to meet their GDPR obligations !
Eric
is...@google.com <is...@google.com>
ni...@conrad.de <ni...@conrad.de> #64
We want to use shared VPC with AppEngine but some of our AppEngines are in a other region than our shared VPC so we have to move them.
Regards, Nico
ol...@gmail.com <ol...@gmail.com> #65
This functionality is really required as even new products (Cloud Scheduler, that came GA at May 31, 2019) highly depended on GAE's region. Scheduler even silently create GAE Application if it was enabled that makes things worse...
[Deleted User] <[Deleted User]> #66
PS: My first GAE application was deployed in 2010....9 years after we still fight with this issue....
ha...@gmail.com <ha...@gmail.com> #67
because of change th region you have to create new Project is not acceptable.
+2 ..."Minimal viable solution would be just allow to delete GAE Application (as all associated resources in the project) to allow creation it in new region. "
ma...@sap.com <ma...@sap.com> #68
+3 ..."Minimal viable solution would be just allow to delete GAE Application (as all associated resources in the project) to allow creation it in new region. "
wy...@gmail.com <wy...@gmail.com> #69
"#28: I chatted with eng and it looks like we might be able to delete the app (and all the associated data, e.g. blobstore, datastore, etc.) and let you create an app in a new region relatively quickly. The caveat would be that you couldn't re-create the app in the same region for a period of time (data has been replicated and needs to be wiped out). Would this work for folks?"
"Quickly" is apparently a very relative term. Is this deletion something we can get or not? Like many people here my team has been bitten by inadvertently created GAE projects in the wrong zone, in our case because of Firestore, and we need to tear it down and set in a different region to match the rest of the deployed system.
di...@grupotagle.com.ar <di...@grupotagle.com.ar> #70
fe...@bakian.io <fe...@bakian.io> #72
se...@io42.com <se...@io42.com> #73
ev...@busy.no <ev...@busy.no> #74
ke...@gmail.com <ke...@gmail.com> #75
This is now the #9 App Engine issue. Can the Google PMs at least tell us what features they are prioritizing above this one and then we can give an open and honest view on whether we agree with that prioritization. Maybe we do!
pi...@google.com <pi...@google.com> #76
Although we appreciate your comments, we would recommend to review this comment [5] and the mitigation approaches described.
[1]
[2]
[3]
[4]
[5]
[Deleted User] <[Deleted User]> #77
Could you please provide some information on the comment made by MpMcdonald on the 22nd of October 2018?
#28: I chatted with eng and it looks like we might be able to delete the app (and all the associated data, e.g. blobstore, datastore, etc.) and let you create an app in a new region relatively quickly. The caveat would be that you couldn't re-create the app in the same region for a period of time (data has been replicated and needs to be wiped out). Would this work for folks?
or...@gmail.com <or...@gmail.com> #78
How can I change the region the scheduler runs on? Deleting the project is
a bloodbath.
On Thu, 26 Mar 2020, 19:43 , <buganizer-system@google.com> wrote:
pa...@gmail.com <pa...@gmail.com> #79
de...@cmsmastercloud.ca <de...@cmsmastercloud.ca> #80
er...@gmail.com <er...@gmail.com> #81
[Deleted User] <[Deleted User]> #82
ju...@otto.de <ju...@otto.de> #83
- deleting the project and wait 30 days before creating a new one with the same name
- creating and setting up a project with a different name
Both are unsatisfactory options. The possibility to change the appengine's region would make developer's life much easier.
er...@gmail.com <er...@gmail.com> #84
First of all, it's ridiculous that Cloud Scheduler is tied to App Engine at all. Who thought that _that_ was a good idea in 2019/2020? Feels like someone's pet project got promoted to prod.
Second, I'm 99% confident I will never use App Engine, and still the only truly serverless database on GCP (Cloud Firestore) is also inexplicably tied to the App Engine region, and that is the US as explained above. I should be able to provision Cloud Firestore in however many regions I like?
As someone above said migrating to another project truly is either a blood bath, or I need to set up cross-project permissions and remember what is provisioned where. Ridiculous.
Get your act together!
Unbundle Cloud Scheduler & Cloud Firestore from App Engine!
P.S.
I'm sorry for using such harsh words but I have been actively using GCP for more than 3 years, promoting it to other companies and saying what a delight it is to use compared to AWS. I really like GCP and I will stay as a customer because of many great solutions but App Engine should either be fixed (remove region lock) and unbundled (from CSch/CFs) or deprecated and forgotten.
P.P.S.
Ceterum censeo App Engine esse delendam.
ke...@gmail.com <ke...@gmail.com> #85
I also echo the request in
As of today, this is the 8th most popular App Engine issue on the Issue Tracker, and also one of only 8 App Engine issues with over 200 votes.
If this was an exclusively App Engine issue, one might grudgingly accept that one just has to live with it and that one should consider moving to Cloud Run instead - but it impacts both Cloud Firestore and Cloud Scheduler as well, products which Google continues to promote heavily.
It's really strange that this issue doesn't get more traction.
ku...@gmail.com <ku...@gmail.com> #86
But I also understand why it's not being done. App Engine is probably one of the oldest service in GCP and there might have been poor design decision made which makes it really hard for the region to be changed afterwards.
For the Cloud Scheduler part: I guess it is basically just the App Engine Scheduler (which existed long before) with some fancy API and UI on top, so it's understandable that the region can't be changed. And this was probably the easiest way to implement it.
I guess I know why Firebase uses the App Engine for security rule evaluation and other stuff, but if there is such a restriction, it would be cool if Firebase would migrate away from App Engine, so this restriction won't be there in the long term.
[Deleted User] <[Deleted User]> #87
pe...@gmail.com <pe...@gmail.com> #88
Still, maybe simply updating all the documentation saying that failure to select the correct region for a service may lead to unforeseeable, irrevocable project losses and unemployment would be a satisfactory mitigation for this issue.
gi...@gmail.com <gi...@gmail.com> #89
ve...@g-experts.net <ve...@g-experts.net> #90
Can we get a rough estimation if this feature request will be considered at all in the coming years?
an...@gmail.com <an...@gmail.com> #91
ji...@au.pwc.com <ji...@au.pwc.com> #92
[Deleted User] <[Deleted User]> #93
Just adding another +1 on this feature request. We accidentally chose the wrong region for our staging project when setting up app engine 2 years ago. Now when starting to use Cloud scheduler we have to make exceptions for this one project in our deployment pipeline just because of that mistake. We are not going to migrate our entire staging environment because of it but it would have been super nice to avoid workarounds. We would have been ok with some app engine downtime for the switch.
sa...@gmail.com <sa...@gmail.com> #94
be...@scitis.io <be...@scitis.io> #95
be...@scitis.io <be...@scitis.io> #96
m....@sotec.eu <m....@sotec.eu> #97
[Deleted User] <[Deleted User]> #98
[Deleted User] <[Deleted User]> #99
ed...@gmail.com <ed...@gmail.com> #100
ju...@linkconsulting.com <ju...@linkconsulting.com> #101
br...@gmail.com <br...@gmail.com> #102
an...@getflex.com <an...@getflex.com> #103
ka...@gmail.com <ka...@gmail.com> #104
di...@viralbamboo.com <di...@viralbamboo.com> #105
on...@gmail.com <on...@gmail.com> #106
[Deleted User] <[Deleted User]> #107
ka...@gmail.com <ka...@gmail.com> #108
su...@gmail.com <su...@gmail.com> #109
jo...@joonix.se <jo...@joonix.se> #110
ke...@gmail.com <ke...@gmail.com> #111
To everyone:
- If all you want to do is register your support for the issue, just star it. Don't comment with "+1".
- If you have something more thoughtful to add, write a comment too!
fe...@googlemail.com <fe...@googlemail.com> #112
Is there any commercial option to transfer a google app engine standard application to another region?
Downtime is not acceptable unfortunately
I was thinking of doing it this way, what do you think about that?
[Deleted User] <[Deleted User]> #113
[Deleted User] <[Deleted User]> #114
+1
de...@google.com <de...@google.com> #115
de...@gmail.com <de...@gmail.com> #116
so...@morrisonsplc.co.uk <so...@morrisonsplc.co.uk> #117
ka...@searce.com <ka...@searce.com> #118
an...@dmvdesk.com <an...@dmvdesk.com> #119
Please at least let us disable the service and re-enable in a different region. This is costing me so much headache I can't explain.
[Deleted User] <[Deleted User]> #120
m....@w3b.eu <m....@w3b.eu> #121
ke...@gmail.com <ke...@gmail.com> #122
As a Googler said on this thread back in 2018, almost three years ago:
"We definitely should allow the deletion of all information about a GAE app and creation of a new one. I'll chat with the team and understand this more."
Can't you at least prioritise the work to allow for the tearing down of an existing App Engine app, so that a new one can be deployed in a different GCP region?
pa...@weduu.com <pa...@weduu.com> #123
ke...@gmail.com <ke...@gmail.com> #124
th...@americanas.io <th...@americanas.io> #125
ru...@gmail.com <ru...@gmail.com> #126
ni...@letoile.in <ni...@letoile.in> #127
sh...@google.com <sh...@google.com>
pa...@gmail.com <pa...@gmail.com> #128
No solution after almost four years.. for something that shouldn't even be discussed due to limitations on new project IDs and the remaining tied services
na...@google.com <na...@google.com> #129
sa...@cvshealth.com <sa...@cvshealth.com> #130
ae...@arsen.co <ae...@arsen.co> #131
vi...@gmail.com <vi...@gmail.com> #132
le...@monks.com <le...@monks.com> #133
el...@gmail.com <el...@gmail.com> #134
ca...@gmail.com <ca...@gmail.com> #135
bl...@agencyanalytics.com <bl...@agencyanalytics.com> #136
tr...@gmail.com <tr...@gmail.com> #137
ke...@gmail.com <ke...@gmail.com> #138
You have to star it though. A “+1” is nice, but it’s stars that count in the charts. 😉
[Deleted User] <[Deleted User]> #139
n....@soft-telecom.com <n....@soft-telecom.com> #140
[Deleted User] <[Deleted User]> #141
"We definitely should allow the deletion of all information about a GAE app and creation of a new one. I'll chat with the team and understand this more."
Can't you at least prioritise the work to allow for the tearing down of an existing App Engine app, so that a new one can be deployed in a different GCP region?
@Google: Would be super nice to have this, any plans to add this feature?
mo...@gmail.com <mo...@gmail.com> #142
ig...@gmail.com <ig...@gmail.com> #143
di...@gmail.com <di...@gmail.com> #144
ad...@aivie.ch <ad...@aivie.ch> #145
li...@gmail.com <li...@gmail.com> #146
bi...@gmail.com <bi...@gmail.com> #147
sh...@ex.mavenwave.com <sh...@ex.mavenwave.com> #148
er...@google.com <er...@google.com> #149
we...@crystalbays.com <we...@crystalbays.com> #150
st...@gmail.com <st...@gmail.com> #151
lo...@higallop.com <lo...@higallop.com> #152
do...@gmail.com <do...@gmail.com> #153
[Deleted User] <[Deleted User]> #155
[Deleted User] <[Deleted User]> #156
ry...@gmail.com <ry...@gmail.com> #157
la...@google.com <la...@google.com> #158
ey...@google.com <ey...@google.com> #159
[Deleted User] <[Deleted User]> #160
da...@propertytax.ca <da...@propertytax.ca> #161
+1
ma...@gmail.com <ma...@gmail.com> #162
+1
dp...@gmail.com <dp...@gmail.com> #163
ko...@flexpedia.nl <ko...@flexpedia.nl> #164
ds...@teksystems.com <ds...@teksystems.com> #165
pa...@thuma.co <pa...@thuma.co> #166
The ease of migration becomes even more important when the data center runs out of capacity (like it is right now), steals a running instance from you and then your app is stuck trying to auto scale to 1 instance (the configured minimum) and now you're busy scrambling to migrate a whole app to a new region. Meanwhile the status page doesn't mention this condition at all.
[Deleted User] <[Deleted User]> #167
fo...@gmail.com <fo...@gmail.com> #168
The same for me. My service was running on us-east-1 and went down almost 24h ago, because of lack of resources, and I'm trying the whole day to put my service up again, and I always receive the message: "An internal error occurred while processing task /app-engine-flex/flex_await_healthy/flex_await_healthy>2022-11-28T00:41:24.387Z123845.vt.1: The region us-east1 does not have enough resources available to fulfill the request. Please try again later."
Deleting a project and creating a new one would be very difficult as I have a lot of configuration and also a database in the same project. I can't change the zone of my app engine, neither delete it to create it again. What should I do?
I'm loosing many users because of that.
ra...@gmail.com <ra...@gmail.com> #169
On Mon, 28 Nov, 2022, 2:39 am , <buganizer-system@google.com> wrote:
jo...@elipia.com <jo...@elipia.com> #170
ni...@blossomcap.com <ni...@blossomcap.com> #171
[Deleted User] <[Deleted User]> #172
pr...@gmail.com <pr...@gmail.com> #173
+1
je...@metalgear.xyz <je...@metalgear.xyz> #174
+1
ek...@gmail.com <ek...@gmail.com> #175
ka...@gmail.com <ka...@gmail.com> #176
jo...@waitwhile.com <jo...@waitwhile.com> #177
Imagine having chosen the flooded europe-west9 region (
de...@cardrop.com <de...@cardrop.com> #178
ch...@unilever.com <ch...@unilever.com> #179
+1 for delete app please. I can't create a new project without approvals :( Also please allow delete of firebase identity so it can be rebuilt in another region.
cy...@celestica.com <cy...@celestica.com> #180
va...@google.com <va...@google.com>
ku...@google.com <ku...@google.com>
an...@cisco.com <an...@cisco.com> #181
mo...@subsbase.com <mo...@subsbase.com> #182
ke...@gmail.com <ke...@gmail.com> #183
If it’s because you have a plan to deprecate App Engine Standard, can you be honest about that and set a timeline? If you have no plans to deprecate App Engine Standard, can you keep investing in the product, including to implement the #2 most popular feature request?
Description