[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15806067#comment-15806067
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9723:
--------------------------------------------

Github user jburwell commented on a diff in the pull request:

    https://github.com/apache/cloudstack/pull/1883#discussion_r95035212
  
    --- Diff: server/src/com/cloud/configuration/ConfigurationManagerImpl.java 
---
    @@ -790,6 +791,18 @@ private String validateConfigurationValue(final String 
name, String value, final
                 return null;
             }
     
    +        if (type.equals(Integer.class) && 
NetworkModel.MACIdentifier.key().equalsIgnoreCase(name)) {
    +            try {
    +                final int val = Integer.parseInt(value);
    +                if(val <0 || val >255){
    +                    throw new InvalidParameterValueException(name+" value 
should be between 0 and 255. 0 value will disable this feature");
    +                }
    --- End diff --
    
    Why are we using a magic value in the parameter to determine whether or not 
a feature is enabled?  Why not add an explicit flag to make it clearer for the 
end user?


> Enable unique mac address across different deployments and networks
> -------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9723
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9723
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>            Reporter: Jayapal Reddy
>            Assignee: Jayapal Reddy
>             Fix For: 4.10.0.0
>
>
> Specify the MAC address range for VMs created in ACS
> If there are Multiple CCP environments, There is  difficulty in identifying 
> VMs based on their MAC addresses since the addresses are duplicated across 
> environments.
> Specifying the MAC address range in zone will avoid the conflict.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to