[ https://issues.apache.org/jira/browse/CLOUDSTACK-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15258445#comment-15258445 ]
ASF GitHub Bot commented on CLOUDSTACK-9003: -------------------------------------------- Github user nnesic commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1492#discussion_r61122746 --- Diff: api/src/com/cloud/naming/ResourceNamingPolicyManager.java --- @@ -0,0 +1,32 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. +package com.cloud.naming; + +import com.cloud.utils.component.Manager; + +public interface ResourceNamingPolicyManager extends Manager { + + + /** + * Finds a resource naming policy among the registered ones by its class + * @param policyClass + * @return + */ + @SuppressWarnings("rawtypes") + public <T extends ResourceNamingPolicy> T getPolicy(Class<T> policyClass); --- End diff -- Hi, here's the mapping of modules using naming policies. ``` Modules dependent on ResourceNamingPolicyManager: bootstrap system core server-naming compute network contrail elb storage baremetal-storage server-template-adapter discoverer baremetal-discoverer hyperv-discoverer ovm-discoverer ovm3-discoverer secondary-storage-discoverer server-discoverer vmware-discoverer xenserver-discoverer Classes relying on ResourceNamingPolicyManager: core: InternalLoadBalancerVMManagerImpl VolumeOrchestrator VirtualMachineManagerImpl ClusteredVirtualMachineManagerImpl SecondaryStorageManagerImpl PremiumSecondaryStorageManagerImpl ConsoleProxyManagerImpl VolumeApiServiceImpl SnapshotManagerImpl TemplateManagerImpl NetworkHelperImpl VpcNetworkHelperImpl SecurityGroupManagerImpl SecurityGroupManagerImpl2 UserVmManagerImpl contrail: ServiceManagerImpl elb: ElasticLoadBalancerManagerImpl LoadBalanceRuleHandler baremetal-storage: BareMetalTemplateAdapter server-template-adapter: HypervisorTemplateAdapter baremetal-discoverer: BaremetalDiscoverer hyperv-discoverer: HypervServerDiscoverer server-discoverer: KvmServerDiscoverer LxcServerDiscoverer ovm3-discoverer: Ovm3Discoverer ovm-discoverer: OvmDiscoverer simulator-discoverer: SimulatorDiscoverer xenserver-discoverer: XcpServerDiscoverer vmware-discoverer: VmwareServerDiscoverer ``` > 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)