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

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?

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?

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.

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

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

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

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.

It seems you cannot upgrade versions of your deployments, we went through all the manual effort of upgrading our deployed mongo servers from 2.6 to 3.2 only to find after reboot they've all rolled back to 2.6 because of the mass of startup scripts =/

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

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.

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.

Like create/update operation, the delete operation should also have --preview flag to give an idea of what resources that will be destroyed.

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