I read here that this commit is not needed. Can we think of scenarios where it is?
On Tue, Jun 3, 2014 at 11:29 PM, Marcus <shadow...@gmail.com> wrote: > Your commit 5e80e5d33d9a295b91cdba9377f52d9d963d802a actually does the fix > mgmt server side and makes this patch irrelevant, as we are now passing a > proper vlan:// in this command. However, Daan's fix will make the data in > the db consistent for upgraders and fresh installers, which will fix this > and all other bugs like it. > > > On Tue, Jun 3, 2014 at 3:26 PM, Marcus <shadow...@gmail.com> wrote: > >> I don't think that's the root cause, but it shouldn't hurt. The root cause >> seems to be that we're telling the agent that the broadcastUri for the vlan >> is 'vlan://100' (as reported by Anders), but the IpAssocCmd passes >> broadcast URI as just '100'. This is a bit messy to workaround the mgmt >> server inconsistency in the agent, but it won't hurt. Fixing the >> inconsistency would be better, and Daan has applied a patch that should >> blanket fix that during the 4.4 upgrade. >> >> >> On Tue, Jun 3, 2014 at 2:44 PM, Edison Su <edison...@citrix.com> wrote: >> >>> Need to cherry pick it into 4.3.1 also. >>> >>> > -----Original Message----- >>> > From: Edison Su [mailto:edison...@citrix.com] >>> > Sent: Tuesday, June 03, 2014 1:37 PM >>> > To: dev@cloudstack.apache.org >>> > Subject: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd >>> > >>> > CLOUDSTACK-6464: >>> > The root cause is that, in 3.0.x, if guest network is >>> "vlan://untagged", then >>> > kvm agent will use whatever value in "private.network.device", while in >>> 4.x, >>> > kvm agent will use "guest.network.device". So if both value are not the >>> same >>> > in the agent.properties, then kvm agent will use incorrect bridge to >>> create vif. >>> > The fix will be, kvm agent code needs to honor traffic type passed down >>> > from mgt server in startcommand, in case of "vlan://untagged". >>> >> >> -- Daan
