cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd
Date Wed, 04 Jun 2014 14:50:45 GMT
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 <shadowsor@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 <shadowsor@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.hoogland@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 <shadowsor@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 <shadowsor@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.su@citrix.com>
>>> wrote:
>>> >>
>>> >>> Need to cherry pick it into 4.3.1 also.
>>> >>>
>>> >>> > -----Original Message-----
>>> >>> > From: Edison Su [mailto:Edison.su@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

Mime
View raw message