Currently if one uses an immutable infrastructure approach where most parts are baked into images you cannot easily replace VMs that are deployed by the deployment manager.

If you update the source image field in the VM definition the API returns an error that this is not an update-able field.
So currently changing the image is two updates to the deployment manager. One without the VM in the spec which causes it to delete the VM and another one with the new VM in the spec.

It would be nice to have an option where I can update the field and the deployment manager just goes on and replaces the VM with a completely fresh one off of the new image.

Have a feature that would auto-generate the template for CDM from an existing VM. Extract startup tasks, cron jobs and the list of software and libraries installed, along with any customized configurations (MVP might only include common configs seen in a LAMP stack.)

Scenarios:
1) I have a brownfield project, it lives on a VM (created awhile ago) that I have imported from another host. My hope would be that this feature would help rebuild the environment onto one of Compute Engine's preconfigured operating system images.

2) Created instance, added to it over time, decided I want to start using Cloud Deployment manager.

While I assume one can use the remote APIs to query the contents of a deployment (e.g. find instances), a programmatic interface to at least read the structure of a deployment configuration would be great to write custom tooling. E.g. something that would for instance do a rolling update of GCE instances with some custom health checks in between.

The ability to mutate the structure would be a great addition to this, for use cases where the provided update is insufficient (doesn't support the intended intermediate steps). E.g if adding a new local-ssd to an existing instance, the current update functionality fails. If I could read and mutate the config, it would be trivial to write some functionality to remove the instance first, deploy that, then add the disk, then deploy again.