cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject Re: CLOUDSTACK-5502 [Automation] createVlanIpRange API failing, if you pass VLAN
Date Thu, 09 Jan 2014 18:04:21 GMT
Currently if I create my public range with 'untagged', I get:

    "Vlan id is required when add ip range to the public network"

So at the very least it seems the patch is not working. It may be
better to edit CreateVlanIpRangeCmd and change the parameter at the
source if 'untagged' is passed in, like:
     public String getVlan() {
+        if (vlan.equalsIgnoreCase("untagged")) {
+            vlan = "";
+        }
         return vlan;

If I create my public range with "", I get a failure in bringing up
the first system vm: line 323, "Unable to convert to isolation URI:"

I'm running tests against the version with your patch reverted, but I
think the root is that untagged (and perhaps empty string) was
previously interpreted as Vlan.UNTAGGED in 4.2, and is not in 4.3,
nothing to do with your change.

There is a lot of code that is looking for untagged, or looking for
null, and either setting null to 'untagged' or skipping code entirely
if it is null, e.g. NetworkOrchestrator:

basic networking seems to get around it:

            if (vlanId == null) {
                vlanId = Vlan.UNTAGGED;
            } else {
                if (!vlanId.equalsIgnoreCase(Vlan.UNTAGGED)) {
                    throw new InvalidParameterValueException("Only
vlan " + Vlan.UNTAGGED + " can be created in " + "the zone of type " +

but advanced networking skips stuff altogether if vlanId is null
(basic networking set it to UNTAGGED and saved the day per previous

                if (vlanIdFinal != null) {
                        if (isolatedPvlan == null) {
                        URI uri = BroadcastDomainType.fromString(vlanIdFinal);
(!vlanIdFinal.equalsIgnoreCase(Vlan.UNTAGGED)) {

                                } else {

                        } else {
(vlanIdFinal.equalsIgnoreCase(Vlan.UNTAGGED)) {
                                        throw new
InvalidParameterValueException("Cannot support pvlan with untagged
primary vlan!");



On Thu, Jan 9, 2014 at 10:10 AM, Marcus Sorensen <> wrote:
> Let me see if I can dig up the specifics. If I remember right, it just
> seemed backward. No vlan id should be treated as untagged, not
> untagged treated as null. There's a lot of code that is skipped if
> vlanid is null, but does useful things if UNTAGGED. Ill be back in an
> hour or two with the results.
> On Thu, Jan 9, 2014 at 1:25 AM, Daan Hoogland <> wrote:
>> H Marcus,
>> concerning
>> Is this still a problem for you? Can I have some more info? I was
>> aware of the setting of vlan back to untagged when I wrote it. That's
>> why I thought it wouldn't be a problem. In a prior mail of you you
>> downwrote the issue as specific to your use-case. I really want to
>> understand as much as possible of these problems with
>> BroadcastDomainType as little varieties appear all over the place once
>> in a while.
>> thanks,
>> Daan
>> ---------- Forwarded message ----------
>> From: Daan Hoogland <>
>> Date: Tue, Jan 7, 2014 at 4:30 PM
>> Subject: Re: CLOUDSTACK-5502 [Automation] createVlanIpRange API
>> failing, if you pass VLAN
>> To: dev <>, Marcus Sorensen <>
>> Sachin,
>> I will look at it and propose some. @Marcus can you send me some
>> description/stacktrace/log on how your testcase fails.
>> regards
>> On Tue, Jan 7, 2014 at 4:13 PM, Sachchidanand Vaidya
>> <> wrote:
>>> Hi,
>>>     Bug CS-5502 was fixed (12/20/13) and then reopened (12/26/13) again since
>>> Vlan=UNTAGGED  case,  createVlanIpRange() API fails with "Vlan id is required
when add ip
>>> range to the public network".  Vlan ="untagged" can be a valid case for public
>>> (in advanced networking) as is the case in  juniper-contrail solution.
>>> Is there a fix planned for this bug?
>>> Thanks & Regards,
>>> Sachin

View raw message