Security group is one such feature as you have mentioned. Vm sync may get
impacted if VM internal names are changed. Once all integration/regression
tests are run additional things may come up.
I think it will be a good idea to have a wiki document describing all resource
types that are impacted. Something like
Resource type | Existing naming convention | New naming policy/customization |
features impacted
VM | i-xx-yy-VM | <new naming
policy> | SG, Vmsync...
Volume | ... | ...
| ...
Also there are display names and internal names. It will be good to call out
what all can be customised and what cannot be with some justification.
-Koushik
________________________________________
From: Jeff Hair <j...@greenqloud.com>
Sent: Thursday, April 14, 2016 9:40 PM
To: dev@cloudstack.apache.org
Subject: Re: Feature proposal: Resource naming policies
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.
>
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.
