This question already has an answer here:
MEAN development stack failed to deploy
(1 answer)
Closed 7 years ago.
I tried to deploy MEAN stack using Google Developers Console, and failed after trying several times, the error is always the same. Is there any fix around this other than deploying the whole stack manually ?
Your MEAN development stack failed to deploy
Dec 1, 2014, 3:12:51 PM
meanStackBox: DEPLOYMENT_FAILED
Replica mean-zeuw failed with status PERMANENTLY_FAILING: Replica State changed to PERMANENTLY_FAILING. Replica was unhealthy 2 consecutive times.
What to do next:
Review the troubleshooting guide
Delete stack
I am getting the same error as well. Tried changing the Zone as well as other variables under the Advanced options but nothing is working so far. Googling shows the last time this happened a fix was needed to be deployed by Google - MEAN development stack failed to deploy. It took 2 days for that question to be posted and the reply from Brian who I assume must be working for Google in some capacity. So if this started to happen from yesterday then hopefully the fix will come tomorrow :)
It seems like this issue could be related to the zone/region settings in your instance.
Take a look at this answer, where my colleague found a successful workaround.
Related
Over the past few weeks my gcloud app deploy has been failing regularly, today it fails even after attempting 10 times so far. According to the google cloud web interface, it is failing after build in the exporting phase:
7: exporter
/cnb/lifecycle/exporter asia.gcr.io/<project>/app-engine-tmp/app/ttl-2h:<uuid>
Is there anything we can do about this at all?
(The build itself takes just a few minutes, then this exporter phase runs until the 10m mark and is killed.)
Perhaps there is a way to make gcloud app deploy do the build in the asia region?
I deleted everything in the Google Cloud Console under the "Container Registry" menu option. Not sure why that helps, but builds now average 2 minutes instead of the historical 9-11 minutes for the past year or so.
(Although this technically doesn't answer why behind the question, this does solve the strange delays in building on appengine (standard). I am going to mark it as solved and leave this question here in case others encounter the error message above.)
In past 3 - 4 days, I have been getting 503 whenever I deploy in Standard Environment. This happens very frequently, usually about 3 hours after new deployment
I checked https://status.cloud.google.com/ and there doesn't seem to be known incident. However, on October 6th, there seems to be an incident that sounds like the issue I'm facing right now https://status.cloud.google.com/incident/appengine/20007
Can somebody help guide us what to do?
I have not been using Azure Machine Learning service (preview) for too long. To my knowledge it only has been released since the last Microsoft Ignite conference. That's why I think I can not find my question on StackOverflow or any other forum for that matter.
It is as follows:
With help of the Azure Machine Learning service SDK in Python I created my experiment in a Jupyter Notebook locally.
I then configured it to run a Hyper Drive config,
The results came in one by one (as I had a total of 50 runs and 4 simultaneously). It took 7 hours to complete the Hyper Drive run in total.
The next day I went to portal.azure.com to view the results and that worked. I was able to see every run of the hyperdrive and could even compare results.
But then....
I have no clue to as what could have happened, but when I tried to navigate to the experiment again I got a blank white screen. When opening the dev console via F12 I got so see a lot of red errors. All from react. I have zero experience with react, but I am quiet sure that this is the error. React errors when viewing experiment
Hope someone can help. Thanks in advance.
Thanks for reporting this! It's a known issue and a fix is being rolled out.
I was running two different versions of my app with the same api_version number, and I started receiving Database locked exception. I've closed both apps, removed both from the app engine launcher, and then reloaded the one i'm currently working on; and I'm still getting the same error.
I've been googling it for 30 minutes, and it doesn't seem like there is a lot of information on this topic specifically related to GAE.
I would like to know how to go about fixing the issue, but more than that, I'd like to know what's causing it in the first place.
I gave to 2 api versions different version numbers but the same api number with the hope that I'd be able to run them concurrently and have them share a datastore instance, but if its displaying this behavior locally, I'm sure its not going to work when deployed. I suppose I have less of an understanding of the versioning than I thought. If anyone has a brief explanation of that process, what causes locking and how to fix that would be great. Thanks!
EDIT:
'api_version' refers to google's api for app engine; nothing to do with one's personal application. still trying to figure out how to deal with 'version' and #endpoints.api. What's the diff?
App engine (python 2.7, Mac OS X, latest version as of today) deployment seems to go fine (compilation completed) but deployment is stuck repeating "Will check again in 60 seconds" every 60 seconds until it finally fails, saying :
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/appcfg.py", line 2025, in Commit
raise Exception('Version not ready.')
Exception: Version not ready.
I've checked appengine status on code.google.com and nothing seems to go wrong.
Any idea if rollback is compulsory ? I had the same problem a couple of hours ago, but after a couple of tries it worked. This time it seems more serious, as i've been stuck in that state for a couple a hours now. Any advice ?
As mentioned in the comments, these types of issues are best served on the mailing list or issue tracker. However, for the particular issue you mentioned, a production issue was filed and resolved. You shouldn't be seeing this issue any longer.