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 <daan.hoogl...@gmail.com> wrote: > H Marcus, > > concerning https://issues.apache.org/jira/browse/CLOUDSTACK-5502 > > 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 <daan.hoogl...@gmail.com> > Date: Tue, Jan 7, 2014 at 4:30 PM > Subject: Re: CLOUDSTACK-5502 [Automation] createVlanIpRange API > failing, if you pass VLAN > To: dev <dev@cloudstack.apache.org>, Marcus Sorensen <shadow...@gmail.com> > > > 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 > <vaidy...@juniper.net> wrote: >> Hi, >> Bug CS-5502 was fixed (12/20/13) and then reopened (12/26/13) again >> since for >> 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 networks >> (in advanced networking) as is the case in juniper-contrail solution. >> Is there a fix planned for this bug? >> >> Thanks & Regards, >> Sachin
