[
https://issues.apache.org/jira/browse/CLOUDSTACK-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15399055#comment-15399055
]
ASF GitHub Bot commented on CLOUDSTACK-9003:
--------------------------------------------
GitHub user ProjectMoon reopened a pull request:
https://github.com/apache/cloudstack/pull/1492
[CLOUDSTACK-9003] Resource Naming Policies
Pull request #988, completed and reinvented.
This is an initial submission, a request for commentary.
This started with attempting to make the VirtualMachineName class
non-static, and turned into a complete overhaul of how resources in CloudStack
are named. Each supported resource has a naming policy that can be overridden
to change the way UUIDs and names are generated for them. The primary use case
for this is so CloudStack can emulate the naming schemes of other clouds. The
default naming policies are in cloud-plugin-naming-policies, cloud-server has
the server-naming module which contains the registry lifecycle, and the
registered policies are injected into the core managers context.
The supported resources are:
* User virtual machines
* All kinds of system VMs
* Security groups
* Volumes
* Snapshots
There is one issue we have before we consider this ready for submission.
The server-naming module has an ordering dependency. It must be loaded first in
cloud-server in order for everything to work. Currently in this PR is a class
called `ModuleLoadingComparator` which adds a comparator that forces the
server-naming module to the top of the list when loading modules. We obviously
want to get rid of this and are looking for suggestions on how to do this.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/greenqloud/cloudstack pr-naming-policies
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/1492.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1492
----
commit 6be87da0d98400ecb7254c200cf9fe7821181e4c
Author: nnesic <n...@greenqloud.com>
Date: 2015-12-28T10:52:54Z
Implement the naming policy feature.
The naming policies feature is a large refactoring of how CloudStack
generates names and UUIDs for the following resources: virtual
machines (user instances and system VMs), security groups, templates,
volumes, and snapshots. Previously, most of these resources were
generated in a non-uniform way, making use of static classes or simple
UUID generation.
With the naming policies feature, each type of supported resource has
a specific naming policy to go along with it that generates UUIDs and
resource names. This allows CloudStack to emulate different kinds of
naming schemes (such as those found in other clouds).
----
> 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)
