`gcloud app deploy` vs. `appcfg.py` [closed]

Question

I've been a long time user of appcfg.py and I even build some bash scripts on top of it.

1. Should we switch to gcloud app deploy? Will appcfg.py be deprecated? If yes what is the timeline?

2. Why isn't there a grace period for backward compatibility of the yaml file? Switching to gcloud app deploy I get:

The [application] field is specified in file [.../app.yaml]. This field is not used by gcloud and must be removed. Project name should instead be specified either by gcloud config set project MY_PROJECT or by setting the --project flag on individual command executions.

and

ERROR: The [version] field is specified in file [.../app.yaml]. This field is not used by gcloud and must be removed. Versions are generated automatically by default but can also be manually specified by setting the --version flag on individual command executions.

I am saying this as this was possible w/ the module/service field:

WARNING: The "module" parameter in application .yaml files is deprecated. Please use the "service" parameter instead.

3. How do you upload queue.yaml, dispatch.yaml and cron.yaml with gcloud app deploy?

4. What are the differences between the 2 ways of deploying an app?

   I'm interested in caveats & things to watch for like:

FLAGS --promote Promote the deployed version to receive all traffic. True by default.

That means w/ gcloud app deploy the app will be deployed and the new version will be set as the active one... this is exactly the reverse way appcfg.py did things as there you would have to call set_default_version to mark a version as active.

This raises my last question: if I opt to NOT make it active by using either

$ gcloud config set app/promote_by_default false

or

Use --no-promote to disable.

will I have to redeploy w/ default value so I can make it active?

Outport

a bit too many questions for a single post IMHO. Start here: #33770379 – Marquardt

Answer 1

Long story short:

1. gcloud app deploy is going to be the preferred path for deployments going forward, and is currently supported. You'll have about a year after we declare deprecation to transition.
2. Before we deprecate appcfg.py, we'll have a full migration guide with all of the changes. We don't want full backwards compatibility, because we're seizing this chance to fix some warts with the old tooling.
3. You can run gcloud app deploy cron.yaml and so on to deploy the alternate YAML files.
4. Again, we're planning on writing a migration guide before we want to force you over to the new tooling.

So I think you can punt on this until we've officially deprecated the appcfg tooling–gcloud app is really meant for brave explorers who want the newest and shiniest for now.

Meridel

One of the flags I regularly use in appcfg is the -A to deploy the same code base to multiple projects, e.g. dev/test/live projects... How do I do that with gcloud app deploy? There isn't a -A flag in the docs. – Thorazine

You're looking for --project – Meridel

Also you should look at gcloud config configurations list – Outport

@ZacharyNewman it appears to me that you have to have 'Project Editor' permissions in order to run `gcloud app deploy cron.yaml'. I've tried 'App Engine Admin, Deployer etc' but always get a 403 error. What permissions are necessary when deploying configuration files: queue.yaml and cron.yaml? I have seen the new Datastore Index Admin, so have no issue deploying index.yaml. – Sonora

Deploying cron.yaml currently hits the same API as appcfg.py used to, so the same permissions are necessary (and the old API was published before roles besides Editor/Owner/Viewer existed). If you have follow-up questions, please start a new thread. – Meridel

How do we set environment variables using gcloud app deploy ? – Neutretto