[
https://issues.apache.org/jira/browse/CLOUDSTACK-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241656#comment-15241656
]
ASF GitHub Bot commented on CLOUDSTACK-9003:
--------------------------------------------
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1492#issuecomment-210081172
np, imagined that
> Make VM naming services injectable and in their own module
> ----------------------------------------------------------
>
> Key: CLOUDSTACK-9003
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9003
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Reporter: Jeffrey Hair
> Priority: Minor
>
> Proposal: Make the various classes/code that give VMs and other resources
> hostnames, hypervisor guest names, and UUIDs into their classes as injectable
> dependencies in their own module under the core or backend module.
> This proposal originally only concerned the VirtualMachineName class and can
> be broken down into several parts:
> * Make the VirtualMachineName class an injectable dependency instead of being
> full of static methods.
> * Refactor the generateHostName method in UserVmManagerImpl to be backed by
> an injectable service which generates host names.
> * Move the UUIDManagerImpl from the core module to a new module (grouped with
> the other 2 ideally).
> Rationale:
> * VirtualMachineName is one of the few remaining classes that has static
> methods tangled like spaghetti throughout the code. This change will put it
> in line with the rest of the management server codebase and opens the door to
> extensibility. Which brings us to...
> * Extensibility: The ultimate goal of this feature is to provide 3rd party
> developers the option of changing default instance/resource naming policies.
> Currently this is possible in a very limited fashion with the instance.name
> global setting, but this proposal makes it much more extensible.
> By moving the naming-related services (VirtualMachineName, UUIDManager, and
> more as added/discovered) to their own module, the module can be excluded by
> modules.properties and different ones substituted in. Alternatively, it could
> use the adapter model that other classes use, and the user can configure
> which adapters are active and also provide custom ones.
> A good use case for this functionality is using a different style naming to
> emulate other cloud providers such as AWS (i-abc123) or GCE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
