You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Jeff Hair <je...@greenqloud.com> on 2016/04/14 13:40:37 UTC
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.
Re: Feature proposal: Resource naming policies
Posted by ilya <il...@gmail.com>.
Awesome and long awaited!!!!
On 4/14/16 4:40 AM, Jeff Hair wrote:
> 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.
>
Re: Feature proposal: Resource naming policies
Posted by Koushik Das <ko...@accelerite.com>.
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 <je...@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 <ko...@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 <je...@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.
Re: Feature proposal: Resource naming policies
Posted by Jeff Hair <je...@greenqloud.com>.
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 <ko...@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 <je...@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.
>
Re: Feature proposal: Resource naming policies
Posted by Koushik Das <ko...@accelerite.com>.
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 <je...@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.
Re: Feature proposal: Resource naming policies
Posted by Daan Hoogland <da...@gmail.com>.
sounds usefull for companies that for instance want to enforce uuid in name
or include some user string in it, same would be true for networks. look
forward to your design.
On Thu, Apr 14, 2016 at 1:40 PM, Jeff Hair <je...@greenqloud.com> wrote:
> 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.
>
--
Daan