Hey after two days I get a message the I cannot deploy my appengine becuase I already got too many version.

165 views
Skip to first unread message

Guy Dviri

unread,
Jun 27, 2018, 3:37:08 PM6/27/18
to Google App Engine
so i go to the console and delete 200+ version.

what I want to ask is , I work on the google cloud more then 3 years and deploy countless of time... and never had this message , what change?

Kenworth (Google Cloud Platform)

unread,
Jun 28, 2018, 4:30:30 PM6/28/18
to Google App Engine
We do enforce a limit of 15 (free app) and 200 (paid app) maximum versions per app. See article

Out of curiosity, does your business/application model require you to have ~200 running versions or are majority of these non-serving versions?

Guy Dviri

unread,
Jun 28, 2018, 4:38:46 PM6/28/18
to Google App Engine
no it's just a small app ,not even up to the air  ,  i don't know why i have 200 version i only need one..
what could i doing wrong..

i using endpoint + sql + bigstore .
i deploy my module using :

console : appenginedeploy

what do you think could trigger this behavior ? 

Ani Hatzis

unread,
Jun 29, 2018, 11:29:04 AM6/29/18
to google-a...@googlegroups.com
Hello,

when you deploy a new App Engine app version and do not specify a specific version, App Engine will create a new version automatically. You can see them in the Web UI under App Engine > Versions or in the shell:  gcloud app versions list  

Many users utilize versions using traffic split to perform A/B testing or soft migrations. If something goes wrong during the rollout of a new feature, they can easily direct traffic back to an older version.

If you do not want to utilize versions, you could just specify the same version at every deployment of your App Engine app, for example:
gcloud app deploy --version=v123 . 

If version v123 already exists, App Engine will replace it, and you will not see a growing list of versions. However, if you care for availability of your app, I would recommend to deploy into separate versions and make use of this feature.

--
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/17eec7eb-5203-4c27-bee0-e922010d38b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Guy Dviri

unread,
Jun 29, 2018, 3:06:29 PM6/29/18
to Google App Engine
I reply thanks you 2 hours ago , but I don't see the reply in the thread , google groups UI must change their layout in my opinion , 
any way I like to ask @Ani one more thing ,  is it possible to block version from updating , let's say that it will be update only with special key,, or something like that , to prevent update by mistake.. 
do you know some way to do it?
 

Ani Hatzis

unread,
Jun 30, 2018, 4:35:02 AM6/30/18
to Google App Engine
There is no particular write-protection for a given version. I can think of two solutions in your case:

You could use two user accounts, where only one of them has the permission to upload new versions, and normally you would use the other (restricted) account for your day-to-day work between deployments. In Google Cloud Platform you would use roles to manage access, where a role is like a list of permissions, that can be assigned to individual user accounts, Google groups, all users in a G Suite domain or Cloud Identity domain, or service accounts. The pre-defined roles with App Engine already provide a separation, see "App Engine Deployer" and also the additional information later on that page regarding deployment and traffic management.

If you don't want to handle two accounts, but have some kind of an additional step after an (accidental) deployment, then I suggest to utilize App Engine's version management and the gcloud app deploy options "--no-promote" flag and not to stop the previous version. 

Set default config settings:
As you might know, you can manage SDK configurations in Cloud SDK  where you can store default settings, even multiple configurations. But I assume you only have one project and thus only one configuration (the DEFAULT configuration). You can just store the defaults in your gcloud configuration.

In gcloud app deploy, --promote or --no-promote flag tells App Engine whether traffic should be automatically migrated from the previous version to the new version. Turn the promote off by default for all your gcloud app deploy commands in this config: 

$ gcloud config set app/promote_by_default false

Updated property [app/promote_by_default].


The next option will prevent that a previous version is automatically stopped when you deploy a new version:

$ gcloud config set app/stop_previous_version false

Updated property [app/stop_previous_version].


Verify that your configuration is correctly set under the [app] section (that's the one for App Engine specific configurations):

$ gcloud config list

[app]

promote_by_default = False

stop_previous_version = False


You only need to repeat these steps, if you have a new gcloud installation or if you want to create a new gcloud configuration.

Future Deployments in two steps:

Step 1: From now on, only use gcoud app deploy without specifying a version (--version), without the --pomote flag, and without the --stop-previous-version. Just something like this:

gcloud app deploy .


As no --version is provided, App Engine will create a new version and give it an automatically created version name (looks like an ISO timestamp starting with the year, e.g. 20180630....). The new version will not be the new default version, and the previous version will not stop to serve traffic. So the deployment has no effect to your users until now.

Step 2: Next in gcloud or in the Web UI:
  • The deployment was accidental: just delete the accidentally created version (typically the newest one)
  • The deployment was intentional: migrate traffic to the new version or make it the new default version
You can occasionally delete very old versions, so you won't hit the 200 versions limit per app again.

Best regards,
Ani

Guy Dviri

unread,
Jun 30, 2018, 5:10:47 PM6/30/18
to google-a...@googlegroups.com
Thanks Ani ,its alot to deigust  ,would much easier just to put a password on the version within the cloud console.

--
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/oK_RMcpR0CM/unsubscribe.
To unsubscribe from this group and all its topics, 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.

Kenworth (Google Cloud Platform)

unread,
Jul 2, 2018, 1:24:45 PM7/2/18
to Google App Engine
The feature to write-protect / password-protect a version is not yet currently supported. In that regard, I encourage you to submit that feature request here as described in this article so that proper attention and weight will be given to it. You can also refer on this thread as background to the request.






Reply all
Reply to author
Forward
0 new messages