[
https://issues.apache.org/jira/browse/CLOUDSTACK-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14982504#comment-14982504
]
ASF GitHub Bot commented on CLOUDSTACK-9003:
--------------------------------------------
Github user ProjectMoon commented on the pull request:
https://github.com/apache/cloudstack/pull/988#issuecomment-152513166
While I haven't pushed new work to this PR yet, I do have a prototype of
what I intend to do, and am looking for thoughts on it here.
My plan:
* Move MachineNameService and UUID manager into one interface. Remove the
methods from VirtualMachineNameService which are not used. Call this interface
ResourceNamingPolicy.
* Create a ResourceNamingPolicy extension registry, and a new module for
the default naming policy (which is the UUIDs ACS generates at the moment).
* When using methods from ResourceNamingPolicy, iterate through all
registered policies until one returns a name that is not null. This is in line
with other things like API authenticators, host planners, etc.
* Expand the use of the ResourceNamingPolicy beyond virtual machines and
volumes (which is what VirtualMachineName/UUIDManager touch currently). The
plan is to make use of this for these entities to begin with: VMs, volumes,
templates, security groups.
> 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)
