<div dir="ltr"><div><div><div><div>Forgot to mention the project<br><br></div>1. Make it so the user can decide (advanced options only) if they want one bridge per tap or one bridge per host<br></div>2. You will likely need to reorganize org.petitecloud.net.NetIface.reset()<br>
</div>3. Keep track of what tap goes to what bridge (just same device number might do it)  <br><br></div>Neither I or Dee will have time for this for a few weeks.<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Feb 11, 2014 at 4:32 PM, Aryeh Friedman <span dir="ltr"><<a href="mailto:aryeh.friedman@gmail.com" target="_blank">aryeh.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>Michael is correct it is likely not the best (depending on use case) to have all taps on the same bridge.   The general pros and cons of each option are:<br><br></div>1. If your looking at a set of cooperating instances on the same host [see note] then having packets that are only internal to the machine require routing (even trivial ip forwarding is routing for this discussion) is not DRY (don't repeat yourself). DRY is one of the coding standards we strive to meet,  at best and a point of failure at worst.<br>

<br></div>2. If your instances are outward facing (typical large cloud/provider use case) then it doesn't matter and having one bridge per tap is likely more secure (no cross tap snooping)<br><div><br>Note: A typical small development firm use case [PetiteCloud itself is developed on such a model {we off load testing onto a set of test machines but we have a single production machine for all of our development and business instances}... also note even though we are adding support for external storage and complex network configurations we currently rarely need them in our day to day non-cloud consulting work].   Our mental model of a typical small non-openstack user in the same kind of thing where they only need very basic services but they are delivered with complete stability and robustness (setup and forget) from a very small set of machines in their office.<span class="HOEnZb"><font color="#888888"><br clear="all">

<div><div><div><br>-- <br><div dir="ltr">Aryeh M. Friedman, Lead Developer, <a href="http://www.PetiteCloud.org" target="_blank">http://www.PetiteCloud.org</a><br></div>
</div></div></div></font></span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Aryeh M. Friedman, Lead Developer, <a href="http://www.PetiteCloud.org" target="_blank">http://www.PetiteCloud.org</a><br></div>
</div>