I also need to be able to do this. Time and again, we get new property capabilities with no update methods. It is frustrating.
If you can create it and set it... you have to be able to update it and destroy it!
I scoured through the IaaS DB to see if the property values were maintained there (as well as the "Deployment" construct). It doesn't appear to be there and I don't think the Model Manager Service would be used to update it (unless there is an entity set that is shimmed via VRA... and then we just need the entity set name).
I hope somebody has a workable answer to this.
It gets worse... I've just realised if you auto-scale an existing deployment the new machines don't inherit the properties set on the deployment. This breaks things for me as I am setting a Three-Letter Acronym on the deployment which represents the application which is used as part of the hostname. Also the Storage policy to be used for the entire application stack
I am in process of discussing with VMware improvements to deployment (composite object) information across the board. I am hoping we can get meaningful feature request(s) in soon.
I was also planning on relying on deployments as "containers of resources" covered by information (metadata, properties). I think you will agree that it is problematic when you cannot change the information in an existing deployment.
In addition, I would also want to be able to move an existing resource from one deployment instantiation into another. I think in the real world (for most vSphere technologists), we 1. deploy from a blueprint and 2. manage as an instance. That management includes day 2 variance which may be a departure from the blueprint construct. An "ideal" where blueprint-deployed instances never move through variance is better seen in containerized systems than the kinds of resources we deploy (virtual machines in vSphere primarily).
Having a change methodology doesn't prevent those who want fixed blueprints (which may vary only by scale) to KEEP their fixed blueprint methodology. However, having no change methodology affects those of us who want fixed blueprints with deployed instance flexibility.
From a properties perspective, we usually write our own cascade methodology when we want relational data integrity in vRA. Properties are only stamped on provision, and if we want a rigid relationship to exist when upstream properties change... we have to perform the update to the downstream, provisioned resources.
For example, for Business Groups... we use an event to update all machines for a Business Group when a cost center property changes in the business group. To us... this cascade methodology should be the default behavior. (It isn't.)
Per the image below, Deployments and Machines as Instantiated instances (Custom Resources) should be able to:
1. Have their names changed *.
2. Have their property "values" changed *.
3. Have an option for changed values to cascade *.
4. Have properties later added which can cascade -- key:value.
If we move a machine from one deployment to another, the cascading properties should accept the values for the other deployment (and Business Group as shown). There are a layer of properties that require relational integrity for their value even after the value changes.
At this point in time, we are unable to change any values in the Deployment... and certainly the values do not cascade to the machines. As you have noted... it appears that even a scale-up third machine doesn't take the property keys:values. I can accept writing my own referential integrity and validation, but for the time being this is not possible for Deployments.
Ideally, we wouldn't have to write our own referential integrity for property values that I believe should cascade into deployed instances (and resources).
For your particular instance with the three letter code in virtual machine properties... I do think you can (as part of your events for machine provisioning) apply the custom property to the machine resource yourself. I believe the storage policy can also be provided via property intercept on request. I have not performed either of these... but I think it to be possible based on other things I have done on provision.
I think you are following a logical use case with this approach.
Wow - great response - thanks Sean.
I assume there is no intention by VMware to release such functionality anytime soon. Probably a v8.x or v9.x release if they even agree to it.
You may have seen another post of mine about what use the Design Canvas actually is given these constraints. I cant do firewall rules, load balancers, auto-scaling, decent dynamic selection boxes for multi-machine blueprints, so I may as well stick with individual Iaas or Xaas forms for each component and co-ordinate assembly of these items into a service using something outside of vRealize. Whether simple scripts doing REST calls into VRA or something like Teradici.
I'll explore the option of updating properties at runtime using EBS subscriptions, but its starting to get so complicated I wonder about whether its worth it
Forward plans would be under NDA, but I can say that I would "want" Deployment update capability sooner than a major release. "Wanting" and "getting" do not always align.
Hang in there... it is complicated, but very powerful.
Just found this thread while searching for the same capabilities. Any progress you can report?
Deployment properties seems to be stored in psql table comp_deployment under eff_state column but found no way to manipulate yet.