With this feature, it is possible to change the names that get sent to the hypervisor, yes. In 4.2 we actually had to fix an issue with the security groups because they weren't parsing properly. That isn't in the commit yet. We will put it in.
It would be useful to have a list of all the places that rely on the internal naming convention. security_groups.py and friends is the only one i know of off the top of my head. On Thu, Apr 14, 2016 at 4:01 PM, Koushik Das <koushik....@accelerite.com> wrote: > Are these the names that are sent to HV? For e.g. VM name in the format > i-xx-yy-VM. Currently there are functionalities that rely on the internal > naming convention. All such functionalities needs to be handled > appropriately. > > -Koushik > > ________________________________________ > From: Jeff Hair <j...@greenqloud.com> > Sent: Thursday, April 14, 2016 5:10 PM > To: dev@cloudstack.apache.org > Subject: Feature proposal: Resource naming policies > > Yesterday, we submitted this pull request: > https://github.com/apache/cloudstack/pull/1492 > > This originally grew out of making the VirtualMachineName class non-static > (original PR is mentioned in the above link). We're presenting this as a > refactoring of the existing code to enable more extensibility and > flexibility, make unit testing easier, and unify the way CloudStack > generates resource names. > > There is an associated JIRA ticket at CLOUDSTACK-9003. I will be writing up > a design document for the CS wiki in the next few days. > > jburwell wanted me to open a discussion on the developer list about the PR > and how it is implemented: > > There is now a ResourceNamingPolicyManager and a bunch of > ResourceNamingPolicies. The manager exposes a method to get a policy for a > type of resource, and the naming policies generate UUIDs + resource names. > > The default naming policies generate names exactly the same way as they are > created now. This is in a new module called default-naming-policies. By > excluding this module and loading our own naming policies, we gain the > ability to change how names are generated. > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is > the property of Accelerite, a Persistent Systems business. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Accelerite, a Persistent Systems business does not accept any > liability for virus infected mails. >
