[PetiteCloud] a small development project for someone

[Aryeh Friedman]

Forgot to mention the project

1. Make it so the user can decide (advanced options only) if they want one
bridge per tap or one bridge per host
2. You will likely need to reorganize org.petitecloud.net.NetIface.reset()
3. Keep track of what tap goes to what bridge (just same device number
might do it)

Neither I or Dee will have time for this for a few weeks.



On Tue, Feb 11, 2014 at 4:32 PM, Aryeh Friedman <aryeh.friedman at gmail.com>wrote:

> 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:
>
> 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.
>
> 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)
>
> 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.
>
> --
> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>



-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.petitecloud.nyclocal.net/pipermail/petitecloud-general-petitecloud.nyclocal.net/attachments/20140211/c0dc5c26/attachment-0003.htm>