I see. My confusion lies in the fact that this commit is associated with https://reviews.apache.org/r/21908/, which is not the right fix, but the commit does not contain the review patch provided.
In fact, we *really* don't want to apply review 21908 now that we've applied other fixes, as it is functionally incompatible with some of the other commits, but these commits should be ok. On Wed, Jun 4, 2014 at 8:13 AM, Marcus <shadow...@gmail.com> wrote: > actually this specific commit isn't the one I thought it was. This one is > a relatively innocuous catch-all that forces things to the guest bridge if > all else fails. I'm not sure it will configure things 'right', but it will > help from things going on a protected network like mgmt if things fail. > > > On Wed, Jun 4, 2014 at 1:32 AM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > >> 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 >> > >
