Please add support for managing Cloud DNS records from Deployment Manager. This would let us add external DNS records for deployed resources automatically.

The servicenetworking.googleapis.com is not currently supported by Deployment Manager nor is it a supported GCP-type so this can't be done through DM for now.

This becomes a blocker in trying to create private access to Cloud SQL via DM

If I delete or otherwise modify a resource outside of deployment manager, when I next perform a deployment update, then that resource should be returned to the state as defined in the deployment YAML/JSON.

Let's say I have a YAML defining a simple VM instance. When I perform the deployment create, then the instance is created.

If I then delete the instance via the console, and then perform a deployment update, it says success, but the instance is NOT restored.

For example, the following is not really useful:

• code: RESOURCEERROR location: /deployments/.../resources/... message: '{"ResourceType":"sqladmin.v1beta4.instance","ResourceErrorCode":"400","ResourceErrorMessage":{"code":400,"message":"Request contains an invalid argument.","status":"INVALIDARGUMENT","statusMessage":"Bad Request","requestPath":"https://www.googleapis.com/sql/v1beta4/projects/.../instances","httpMethod":"POST"}}'

It comes from one of Google's github examples. It would seem nicer if it could say what argument is the problem.

And in general error messages from jinja/yaml setup files are hard to read.

https://cloud.google.com/deployment-manager/docs/configuration/type-providers/process-adding-api seems really cool. Despite being beta, I'm missing concrete examples, preferably a well documented reference implementation of an API that could work with the Cloud Deployment Manager. Could that be added?

Currently, Deployment Manager only supports v1beta2 type (cloudfunctions.v1beta2.function). However, it has been out of beta, and we need to upgrade to V1 by December 4th 2018!

Templates only support Python 2.7 - https://cloud.google.com/deployment-manager/docs/configuration/templates/create-basic-template#template_syntax

Python 3 is the modern version of python and 2.7 will soon stop being maintained - https://pythonclock.org/.

https://cloud.google.com/deployment-manager/docs/configuration/type-providers/process-adding-api

Suppose I currently have a composite type but would like to override the default Update implementation? I believe creating a new type and implementing a Type Provider API would allow that. However, most behaviors of that API should be inherited from what is done today by the CDM for my composite type. Could you explain how the current behavior could be trivially extended for such a common use case?

Documentation of API are not that easy for a new comer to follow unlike the documentation of gcloud command prompt documentation. Also the examples of APIs are very less. Request you to kindly provide a step-by-step documentation on usage of APIs.

Please add support for Cloud Scheduler to Deployment Manager.

Currently it's very difficult to work out exactly why a deployment fails (See this Stack Overflow post: https://stackoverflow.com/questions/47335752/is-there-any-way-to-print-to-stdout-stderr-or-log-files-in-google-deployment-m and this issue https://issuetracker.google.com/issues/80368273)

This makes debugging take much longer than necessary and incredibly frustrating.

It'd be really nice to be able to get some idea of why a deployment is failing/ somehow improve the debuggability of deployment manager

Your "environment variables" turn out to not be what is normally meant by environment variables. This is misleading and time wasting. Call them something else (or make them actually work for real environment variables).

I don't see how network peerings can be defined:
- no peering listed in supported resources.
- https://cloud.google.com/compute/docs/reference/latest/networks shows peerings as output only.

How can I essentially include the following in my deployment?

gcloud compute networks peerings create peer-ab \
--network network-A \
--peer-project project-B \
--peer-network network-B \
--auto-create-routes

I am able to create spanner instances with cloud deployment manager. I would like to be able to specify my entire spanner setup including instance, database, tables, schemas, etc from my deployment manager template.

Please add support to remove resources like "default" network without adding to DM and then deleting that conf.

It would be great if we could use the SDK to view detailed differences between an update preview and the current deployment. Often, I'm finding that I am updating startup scripts for VMs, or even adding metadata to various components of the deployment.

In addition to using git diff, which I use to version control deployment scripts, it would be great to have diffs of the deployment from deployment manager to verify that the changes I intend to happen will indeed happen.