I had the same confusion as I inspected this id (from subject) it is pulled in now.
On Wed, Jun 4, 2014 at 4:22 PM, Marcus <shadow...@gmail.com> wrote: > 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 >>> >> >> -- Daan
