cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Koushik Das <koushik....@accelerite.com>
Subject Re: Feature proposal: Resource naming policies
Date Fri, 15 Apr 2016 12:01:46 GMT
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 <jeff@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.das@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 <jeff@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.

Mime
View raw message