Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd

2014-06-04 Thread Daan Hoogland
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 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

Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd

2014-06-04 Thread Marcus
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 fu

Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd

2014-06-04 Thread Marcus
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. O

Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd

2014-06-04 Thread Daan Hoogland
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 wrote: > Your commit 5e80e5d33d9a295b91cdba9377f52d9d963d802a actually does the fix > mgmt server side and makes this patch irrelevant, as we are now passing a > proper vlan:

Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd

2014-06-03 Thread Marcus
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 an

Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd

2014-06-03 Thread Marcus
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 in

RE: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd

2014-06-03 Thread Edison Su
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