IssueTracker

This doesn't repro for me. Steps:
(1) Create new C++ project
(2) Run the app (this create's the binary directories
(3) Do something to cause a gradle Sync
(4) Look for files under .externalNativeBuild. They're there:
    jomof@jomof:~/projects/client/src/android/MyApplication4/app$ find "." -name "*.o"
    ./.externalNativeBuild/cmake/debug/x86/CMakeFiles/native-lib.dir/src/main/cpp/native-lib.cpp.o

Please add repro steps so I can get a better idea of what's happening.

>>  It should only delete the CMake binary directories *if and only if* parameters change in Gradle that cause cmake toolchain parameters to change (such as platform version, abi, toolchain) or parameters passed to CMake to change.
This is the way it's design to work and it is working that way for the cases I know

I realized that there were a few things we were doing that were questionable. Specifically, we set up our CMake command line params in a variable at the root build.gradle script. We were generating build dates and such in gradle and passing those down to CMake. I think things like this may be causing the CMake args to change too often, possibly resulting in this behavior. I'm in the process of eliminating a lot of this, so I'll make sure to report back the results.

So even after making my changes, I still see this behavior. My repro steps:

1. Make a change to a CMake script
2. Switch to Android Studio. I am prompted to do gradle sync, and so I do it.

On next build, a full rebuild is performed. For some reason it is not performing a delta build. Some libraries are rebuilding that should not be rebuilt. So obviously a "ninja clean" is happening somewhere. There's simply no other explanation for this.

Jomo, can you please reopen? This is still a very real problem.

Hey Robert,
From what you wrote I think this is intended behavior. If you change the CMake script then the CMake-generated Ninja project must be regenerated. Since there's a new Ninja project there needs to be a full build. There's no concept of delta build that survives changes to build command files (CMakeLists.txt or ninja build files) because any behavior difference is possible.

Most of the time, a CMakeLists.txt is modified to add, remove, or rename source files. CMake uses this list of source files as a way to know if it should regenerate to update its ninja scripts to build the new files, if new files were added.

If you do a traditional CMake build from the command line, CMake will regenerate but it will not clean your previously compiled translation units (the object files). Those remain in-place. This allows you to perform another build (e.g. execute "ninja" command) and the build tool and compiler working together will be smart enough to know which files need to be rebuilt.

From this standpoint, I disagree with your assertions. There's no functional reason AFAIC to "clean" build every time a CMake script changes. If command line parameters to CMake change in such a way that it would completely invalidate previously compiled translation units outside of the knowledge of ninja and the toolchain programs, such as changing the Android ABI via toolchain arguments, then yes you would need to clean everything and rebuild. However, beyond that, you should be relying on ninja and the compiler to perform delta builds on previously compiled translation units.

As you have it now, I am unable to do a simple task like add new CPP files without having to rebuild my entire project. This wastes about 15-20 minutes of my time (that's how long a full rebuild takes), versus less than 60 seconds to just build the new file.

I think you should aim for smarter introspection into how this mechanism works. I see two very simple scenarios:

1) A build & sync was triggered due to parameter changes from gradle (those that affect the externalNativeBuild configuration, such as native ABI changes and custom user arguments)
2) A build was triggered because CMake.exe told you that a regeneration was needed since it detected a CMakeLists.txt changed

#1 should perform a clean & rebuild
#2 should not require any special action from you; you should simply run "ninja" command as if the scripts hadn't changed at all, and let Ninja run CMake to regenerate as needed

I feel like #2 is being treated as #1 right now. Also I noticed that Android Studio wants to re-sync Gradle when a CMakeLists.txt file changed. I do not think Android Studio should be "watching" CMake scripts. It should only resync if gradle scripts changed. If a CMake script changes, let your "ninja" command handle it.

As a final note, I realize I'm probably oversimplifying this a little. I'm sure there's reasons and edge cases as to why you need that level of control over CMake. However, at some point the full clean build has to be triggered in a smarter way to avoid these giant productivity problems. You obviously know much more about how CMake integrates with Android Studio than I do; I can only offer feedback based on my direct usage of CMake outside of AS. However, I hope my feedback makes sense and is agreeable.

Just to clarify, in the logs this is the exact problem:

External native generate JSON x86Debug: - dependent build file missing or changed
External native generate JSON x86Debug: removing stale contents from 'E:\code\frontend\source\Applications\zPayService\TestTool\.externalNativeBuild\cmake\x86Debug\x86'

The "removing stale contents"... those contents aren't stale at all. A build could be executed that reuses those existing object files if all I did was modify the cmake script to add new files to compile.

Also CMake will think CMake scripts changed if you swap between git branches:

1. Go from branch A to branch B
2. Go from branch B back to A

Cmake script is still physically the same, but because you swapped branches around, the timestamp of the Cmake script changed so this triggers a full rebuild.

At this point I'd say this is our biggest issue at Ziosk and the one causing the most productivity problems. Our team of about 15 engineers is constantly complaining. There's concern on how long Google will take to address these issues, some have proposed rolling back to Eclipse + ANT. If we're a year out from any improvements I may have to consider it.

I'm prototyping a change to address this. There is a concern that CMake doesn't operate incrementally under certain circumstances. For example, changing the compiler. I think Refresh Linked C++ Projects should be enough to cover this case. I'm still looking for other cases that would be more concerning

Another kind of change to CMakeLists.txt is affected. If a build target is removed then CMake won't delete the .so and related .o files. Gradle packages *.so rather than the explicit list of .so files because build systems sometimes copy extra .so files into the output folder to be packaged.
I think I can cover this case by specific removing only unrecognized .so files during sync.

To your example: Changing compiler means changing command line arguments (e.g. `-G Ninja`) or alternatively, changing environment such as C and CXX variables. In the latter case, normal CMake does not watch for changes to environment variables, so it's the responsibility of the user (or in your case, the IDE) to monitor changes to environment and control CMake accordingly.

However, this still falls into the pattern of behavior I've outlined previously. Indirect or direct changes to Gradle or Gradle scripts that result in a different command line invocation of CMake should result in a full clean (delete binary dir + regenerate using CMake). Changes to the CMake scripts themselves shouldn't be monitored by Android Studio at all. If you have weird cases where CMake is doing work the NDK toolchain should be doing, such as lots of system introspection and runtime changes to toolchain, I'd simply document that Google does not support that usage of CMake, and all changes should go through Gradle instead (or file a bug with the NDK team and have them fix the toolchain file).

Concerning stale *.so files: What I did for my ANT integration custom targets in CMake was to delete all *.so files before running a build, that way when a build is finished, you're left with only *.so files that were copied to that destination by custom commands tied to real targets. So if a target was completely removed, its corresponding *.so file would not make it to the temporary/intermediate copy destination where you look for *.so files to package into the APK.

This solution is simple and doesn't require introspection into CMake targets. If you have more direct access to targets defined by CMake, you could keep track a list of targets found during configuration and query the OUTPUT property on each of them and correlate that to files you find in your CMake output directory. Not sure if this has much benefit over the idea above, though.

I've submitted a fix for this. Unless we find a problem the fix will appear in the next 3.1 canary

Could you explain the fix here so I (and others) can get a good understanding of how the behavior is changing as well as what the root cause (original behavior) was?

It's absolutely incredible that such a basic and important feature doesn't exist. I'm baffled !

I'm also in need of this feature. With the recent opening of new region I wish to move to one of those and without the feature to change region, this has a big impact on our development pipeline.
Is there an ETA for that feature ?

Can someone from Google comment on this?

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.

I think overall the region handling is relatively obscure and inconsistent. It's straightforward to change it in certain products (e.g. Cloud SQL) it's impossible in others (App Engine), it's irrelevant in others (Cloud Functions). There needs to be some consistency or at the very least some clarification.

We're in the same situation as all other comments here.
The fact we need to create a new project to change app engine's zone just makes us not use it.
Truly baffling.

Just to add  - RBI in India has made it mandatory to store the payments data in India (https://www.rbi.org.in/scripts/NotificationUser.aspx?Id=11244&Mode=0). This is very problematic since we do use AppEngine and datastore in the US region and can't afford downtime to switch projects.  This should be of the highest priority to you guys.

Is there a solution to this? I was following the tutorial to setup the app engine instance and now I'm stuck with a region I didn't select and also can't delete the default service. I can't delete the project because I have all my other stuff in there.

Please provide a solution to this, unable to change region makes App Engine infeasible. Try to think if we want to change location because of the business strategy, but our data are all in the origin project, then what do we do?
At least let us create more than one app in a project.

This issue is the thing that makes us don't use GCP anymore.. Please provide a solution to this thing. We accidentally picked the wrong region and now we can't use it at all, we just simply migrate to another product rather than move to another GCP project from scratch..

This is truly a huge pain with AppEngine & the prime reason even we are
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:

(App Engine PM)

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 g.co/serverlesscontainers) also will allow N containers in M regions (though during Alpha we only offer one region)
 - Migration of data services:
   - Datastore has managed import/export: https://cloud.google.com/datastore/docs/export-import-entities
   - GCS offers the transfer service: https://cloud.google.com/storage-transfer/docs/

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?

Thanks very much for that full response.

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.

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.

Thanks @mp - not being able to do that now is possibly the most frustrating part of this, as I totally get that migrating everything automagically without downtime would be a tough endeavor with little ROI. But we have dev projects where total destruction of the AE 'instance' so we could switch to a new region would be no big deal and we'd be happy to do it. Especially since things like the Redis service are unavailable in the crummy region we accidentally picked. But making a whole new project and rebuilding the whole thing isn't even something our team CAN do (have to get higher up admins at the company and it'd be a whole "thing."

@mp it would be helpful to update the tutorial to make users choose a region instead of defaulting to a region during the first time creation of a GAE app.

@mp will serverless containers effectively operate like GAE flexible environment? Will one be able to load-balance across multiple regions on a custom hostname?

#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?

#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 (https://cloud.google.com/load-balancing/) which is unfortunately not likely to be present in near future. Long term, we do aim to enable global load balancing in a single project through that mechanism though.

Deleting the app and re-creating it in a different region would solve our current use cases, yes. During what kind of timescale would re-creation be blocked — hours, days, weeks? If it's less than a day that would be fine. Thanks for the comprehensive response!

The current thought is re-creation in a different region would be ~immediate, while re-creation in the same region would likely be weeks.

Re #28, I think that is a reasonable compromise. The caveat I would add is that it should be explained very well in the UI/CLI and the documentation that deleting an app will prevent you from creating a new app in the same region until all data associated with the app has been purged, which could be O(weeks). I don’t think it’s a big deal, but, at the margin, accidents here could leave you in a worse position than you were in before this change.

Is this something we can test/do now? If not, is there a timeframe when this could be implemented (days/weeks/months) ? GDPR is really pushing us to migrate data into Europe

Unfortunately not, the current strategy is still "create a new project and migrate." It may be possible to migrate to datastore/GCS in another project and move customer data to the second project, but still access from the first project (grant the project A runtime service account access to buckets/databases in project B), in case you need to keep the URL from the first project in place.

In your comment on 22 October, I understood that you were planning to allow for app deletion in the relatively near term. Did I misinterpret that?

It seems strange given this limitation that you continue to build new services on top of this architecture - eg, Cloud Scheduler announced today.

Sorry about the confusion: I think I was referring to the developer experience of "deleting an app and re-creating it quickly", rather than the eng effort we'd need to implement this. It's currently not scheduled, so I can't give a timeline on if/when it'll be implemented.

Experiencing this pain now as I wanted to try the "new" Google Cloud Scheduler. It seems like underneath it's still tied to our initial (wrong) choice for the App Engine region (that we don't use at all in our project, we're using GKE). It would be great if those spin-off products from GAE could really live outside GAE without inheriting its legacy.

Looking forward to being able to delete & recreate our GAE app!

+vinod (PM for Scheduler and Tasks)

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.

#31 The interactive "choose the region where you want your App Engine application" picker is only shown when typing "gcloud app create". However if the first command you type is "gcloud app deploy", then it will default to us-central.

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?

I just tried `gcloud app deploy` without `gcloud app create` and it seems to prompt me for the region. Have you set a region in gcloud config maybe?

I too have been bitten by this bug. I had a gcloud config with us-central1 set for region but on a new project I wished to deploy to us-east1. I even have a VPC all setup in us-east1 but now you're telling me I need to delete the entire project, including the VPC I setup, to fix a dumb mistake of setting an immutable region for the one and only GAE app? This seems unreasonable. With compute you simply delete the VM and create a new one. Why is this not the same for GAE?

This continues to be a large problem for many of our users as well. Many have taken a good bit of time to make NP and PR projects the same, and today one person was deploying to prod for the first time and realized that the initial app engine app was deployed to the wrong region. If we could delete the entire thing and set it up again from scratch it would get us out of a bind that we hit quite often. I am very interested in the latest status of this, and would like to see what we can do to encourage it being added to the roadmap for a fix. Willing to discuss it on our next customer call.

+1 for ability to delete an app and recreate it in a different region. I have an app in development which I would eventually like to be in Europe, but for some reason or another it is in us-central.

+1 for the region change feature if that would be possible.

+1 for app recreation

+1

+1 Region Change.

Is it fair to assume that it is hard to prioritise the limited/compromise solution discussed above (ie, of being able to tear down the existing App Engine app in a project) because, to the Google marketeer, or the customer C-level you might be pitching to, this is hard to sell as a great value-adding feature - especially since doing so may effectively involve conceding a current weakness in the product?

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?

+1 for region change of an existing app – it would be awesome!

+1

+1

for sure would be great

+1

+1

+1 for region change

Please refrain from posting "+1" or "Me too" or "I also need this" comments: This doesn't get the ticket addressed sooner, instead it just spams 110 of your fellow sufferers of this defect with a useless email. The way to show your support for this issue is to STAR the issue (see the top of the issue screen). This shows how many people are affected by this issue. If people keep posting +1s, people who are affected, like me, may actually UNSTAR the issue to avoid being spammed, which is bad. We want that number of stars as big as possible so that the ticket will be prominent, so please star, and keep comments only to what is necessary. At this point I think the issue is well-documented and well-understood.

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.

#40 is there any updates? Can we expect to be able to recreate a GAE within the next month? Year? Decade? Changing GAE zone has been a need for over a decade now, and it's ridiculous - almost embarrassing - that you still cannot do something as relatively simple as this. I understand it's a complicated process, but you've had over a decade to figure it out (as per issue 35874988).
It's critical for many projects, and it would give a ton of value even being able to just delete and recreate GAE.

I fully concur with our friends at SharkCell.

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.

"Can we expect to be able to recreate a GAE within the next month? Year? Decade?"

Thats really the only information we need.

#60 Actually, our project may or may not be in the millions (I can't tell publicly). Either way, the amount of users that are having this problem quickly amounts to millions over time.

Agree - we have been telling business people that moving to the cloud gives your business flexibility.

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

We are also affected.

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

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.

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...

+1 ..."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. "
PS: My first GAE application was deployed in 2010....9 years after we still fight with this issue....

exactly that I need this minimal solutin.
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. "

Also needed for the shared VPC usage problem.

+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. "

It has been a year of near silence since this statement

"#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.

My SQL in a region I cannot change, and my AppEngine in a region I cannot change! Sadly different regions both!!! Whats the solution to this problem?

Eleven and a half years. https://issuetracker.google.com/issues/35874988

no news?

Shame

+1  Just need the "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. "

+1 (again)

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!

Please note that our documentation [1] is clear about an app’s region being immutable after it is set, and there is no plan on engineering’s side to change this. The more modern serverless offering, “Cloud Run” [2], solves this issue by allowing to deploy multiple services [3] that are region-independent within the same project. Here is documentation about Cloud Run locations [4].

Although we appreciate your comments, we would recommend to review this comment [5] and the mitigation approaches described.

[1] https://cloud.google.com/appengine/docs/locations
[2] https://cloud.google.com/run 
[3] https://cloud.google.com/run/docs/deploying#service
[4] https://cloud.google.com/run/docs/locations
[5] https://issuetracker.google.com/issues/36878762#comment25

Ok but cloud scheduler runs on app engine, not cloud run.
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:

In case someone needs migrate NodeJS App engine code to CloudRun-> https://codelabs.developers.google.com/codelabs/cloud-run-hello

+1

+1

:( +1

I see the same issue as mentioned by comment #78. Once the app engine is configured in the wrong region there is no developer friendly way to change this. There is no way to "reset" the project. I see two options:
- 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.

Same here - want to use Cloud Scheduler in the Europe region but have created a completely unused app engine app in the US region by accident.

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.

I agree with the sentiments mentioned in comment #84.

I also echo the request in comment #77 for Google to provide an update on the suggestion originally made in comment #31. Why bother suggesting this if, according to comment #76, Engineering have no plans to do anything here? And where does Product and the voice of the customer come into this?

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.

First of all I do also want the App Engine/Firestore project to be changeable and I would like if this would be addressed especially if Firebase and other services still rely on it!

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.

+1

Look, obviously Europe-West-6 and Europe-West-3 are incredibly descriptive and I must have been on drugs to substitute the six for the three. I live so much closer to 3!

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.

+1

#90 I think it's more likely that GAE will be discontinued tbh

Allow changing region for existing GAE is desirable. Currently, after the creation, if we want to change the region of GAE, we have to create a new project, then set up permissions in the existing project or transferring depended infrastructure to the new project. Please consider this. Thanks.

Hello,
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.

Adding my +1 to this. Would love to migrate to closer data centers over time.

+1 because of brexit

+1 because of brexit

+1 as well because of Brexit! We need this now, Google!

+1 - as it appeared chose a farther region from our user-base location than optimal

+1 pretty important feature to have

+1 brexit too.

+1

+1

+1

+1 this is an insane restriction. At least bring out the importance of this choice when creating the initial App Engine. Atm out the entire project is disrupted because of a single poor choice by a single engineer.

+1

+100 app engine should be made more flexible

+1

+1

+1

Now how do you unsubscribe from this issue tracker. I’ve selected muted and still I get these +1 spam

In fairness, I wouldn't say the +1s are spam, but I agree they are unnecessary.

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!

We also need this feature!

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?
https://stackoverflow.com/q/65965810/1619545

+1

+1

+1

+1

+1

+1
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.

+1

+1

@Google: This is now the #4 top App Engine issue, and the #1 unassigned App Engine issue. Your customers want you to do something about this - why do you continue to not do so?

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?

+1

I hope everyone who is +1-ing this has also starred it. It’s stars that count as ‘votes’!

+1

+1

+1

+1

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

+1

+1

+1

+1

+1

+1

+1 - A complete farce that this issue still hasn't been addressed.

+1

I like the +1s, really. Like little pats on the back, sympathetic camaraderie for the hours of frustration that irretrievably mark each of our pasts.

6 more votes and we’ll make this the #2 open App Engine issue.

You have to star it though. A “+1” is nice, but it’s stars that count in the charts. 😉

+1

+1

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?

@Google: Would be super nice to have this, any plans to add this feature?

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

++++++1

Please refer to comment#111  https://issuetracker.google.com/issues/36878762#comment111
before commenting +1

+1

+1

+1

+1

 +1

+1

+1

+1 ...

+1

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.

How is it that my application is completely down and because the data center is out of capacity and there is no way to spin up my servers in a new region. At this point I think it might be easier to migrate to AWS.

+1

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.