cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sheng Yang (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-3753) Multiple VLAN range API need to accept a list rather than "add" or "remove" per command
Date Wed, 24 Jul 2013 09:03:49 GMT


Sheng Yang commented on CLOUDSTACK-3753:

I know the API need a way to represent the non-continguous vlan range. But it should not be
"add" and "remove" in the API. API should represent "status", rather than "action" in this

So when user call the API, the vlan would be changed according to parameter "vlan", which
is a list. And any vlan not in the list would consider "removed". 
> Multiple VLAN range API need to accept a list rather than "add" or "remove" per command
> ---------------------------------------------------------------------------------------
>                 Key: CLOUDSTACK-3753
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Network Controller
>    Affects Versions: 4.2.0
>            Reporter: Sheng Yang
>            Priority: Blocker
>             Fix For: 4.2.0
> "vlan parameter will add a new vlan range to the existing vlan range (new behavior).
if the new vlan range overlaps the existing vlan range it will extend that vlan (This is the
existing behavior.).
> removevlan parameter will remove the mentioned vlan. The removevlan and vlan parameters
can be used together. If the vlan range we are trying to remove is in use, the operation will
not succeed."
> I haven't seen such API in the CloudStack. It's much more clean to use a list here(even
for ranges, can be extended from one element, like "1-2, 4-5, 6-7"), rather than newly defined
"vlan"/"removevlan" behavior. It broke API compatibility(e.g. the previous API potentially
able to change vlan directly, rather than add it), and is also user unfriendly.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message