[PetiteCloud] a small development project for someone
Michael Thoreson
m.thoreson at c4labs.ca
Tue Feb 11 16:00:23 PST 2014
As for making packages we just need to get the makefile(s) right and
then I can use centos\fedora\debian\ubuntu vm's to make rpm's and debs.
*BSD systems that use ports will take care of themselves once the
project is included as the ports system builds ports periodically so
them be added with pkg.
I don't know enough about making linux binaries yet to write a how to
but it is something I can work at.
I agree you can go too far with the lego method but the outcome can be
very entertaining either "wow that is not practical at all" or "omg that
failed spectacularly with fireworks and the like" especially on those
nights were exhaustion has faded into a dim memory and some bizarre part
of your mind believes it can work so you keep banging your head against
the wall :)
I might be able to take the "unstable" environment further than a living
of an NYC apartment to extreme conditions. It would be a very small
market but still one that could be an option. Remote sites or mobile
sites that may have extreme temperature stress or need a small, light
and low power solutions could benefit from some new pico and thin
mini-itx platforms running a light weight hypervisor which could run any
os\app combo that may be needed. Another future option is ARM platforms
since there is current development for a FreeBSD arm port.
Michael Thoreson,
On 11/02/2014 5:15 PM, Aryeh Friedman wrote:
> Roughly equiv to our setup but we focus more on the computing side
> then the storage because the N*M problem discussed else where. We are
> developing on the theory that if PetiteCloud can run on the cheapest
> equipment we could find arranged in one of the most unstable
> environments possible for stable and reliable virtualization and the
> other stuff needed to do cloud computing [aka the living room of a NYC
> apartment] that if we get that right [not just hacked but sound in
> terms of software engineering also and just the right sys/netadmin
> glue] that given the right "gloss" applications we can run clouds of
> any size [and run circles around every other platform]). In other
> words the best way to describe our development model is a sys/netadmin
> lab with the refinement of a computer science lab. I am also a
> Jack-of-All-Trades and am a *VERY* heavy believer in the lego model
> (the *ONLY* reason we even consider petitecloud doable by such a small
> team is the knowledge that 90+% of the problem has already been solved
> by existing OS services and the final 10% is nothing but "glue").
> Note though it is possible to go to far with the lego model and allow
> combinations that are just a bad idea [I can think of many OpenStack
> examples]. Of course the above might not scale due to some inherent
> performance issues with the native OS tools, that's where things like
> system templates might be useful [fill in the blank scripts for
> non-default behaviors such as setting up a storage abstraction layer].
>
> We have our own plans for how to handle clustering (all the way up to
> between data centers) but due to our belief in not having vaporware we
> will not say much more til we get closer to it (towards the middle to
> the end of spring is my guess).
>
> A few useful things for the immediate future:
>
> 1. We are *NOT* linux people and really need some help in getting the
> install completely right and perhaps in packaging up the binaries for
> distrubition
> 2. A few how-to's would be nice (the topic need not matter to much)
>
>
> On Tue, Feb 11, 2014 at 5:15 PM, Michael Thoreson
> <m.thoreson at c4labs.ca <mailto:m.thoreson at c4labs.ca>> wrote:
>
> Thats fine. I am sure we all appreciate the work Dee and yourself
> are doing for the project. My coding skills are limited and will
> do what I can. I however am good with problem solving and most of
> my experience has been in the "lego" style. Basically finding
> projects and putting them together to see what works and what kind
> of new scenarios it solve.
>
> This kind of explains my playing around with glusterfs and i love
> virtual labs so I can "mash" anything I want together and when it
> gets too mashed up then I just erase the machine and start over :)
> or in the case with zfs just roll back a snapshot. So with that
> said if you need me to test different setups let me know. I don't
> have lots of machines but they are high capacity machines.
>
> AMD AM3+ with 8 core 4.4Ghz AthlonFX 16GB DDR3-1600 6x3TB WD Red's
> RaidZ2 currently running FreeNAS but I am in the process of
> changing that to TrueOS so that I can test PetiteCloud on real
> hardware.
>
> Alienware M18R2 2x1TB HD 16GB DDR3-1600 i7-3630QM 802.11abgn
> Blutooth USB3 aka the works cause it is Alienware :) running
> Windows 7x64 Ultimate
>
> Supermicro G34 system with 3x256 OCZ SSD Raid 0 2xOpteron 6212's 8
> core each 32 GB ECC DDR3-1600 RAM with Dual Intel GB nics.
>
> I have 2x8port 1x4port and 1x24 port Gigabit switch, basic ASUS
> wireless abgn router and an external RAID 10 USB3 HD enclosure
> with 4x3TB WD Reds. I also have a supermicro intel atom system
> running pfsense for routing with dual wans.
>
> I am also playing around with a number of wan optimization
> projects and I believe adding it as an advanced function to
> PetiteCloud would be of great interest to investors and platform
> adopters as it would allow the cloud to spread across
> geographically diverse datacenters. But this is for another
> discussion as there is already enough on the todo list :)
>
> Michael Thoreson,
>
>
> On 11/02/2014 3:41 PM, Aryeh Friedman wrote:
>
> 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 <mailto:aryeh.friedman at gmail.com>
> <mailto:aryeh.friedman at gmail.com
> <mailto: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
>
>
> _______________________________________________
> petitecloud-general mailing list
> petitecloud-general at lists.petitecloud.nyclocal.net
> <mailto:petitecloud-general at lists.petitecloud.nyclocal.net>
> http://lists.petitecloud.nyclocal.net/listinfo.cgi/petitecloud-general-petitecloud.nyclocal.net
>
>
> _______________________________________________
> petitecloud-general mailing list
> petitecloud-general at lists.petitecloud.nyclocal.net
> <mailto:petitecloud-general at lists.petitecloud.nyclocal.net>
> http://lists.petitecloud.nyclocal.net/listinfo.cgi/petitecloud-general-petitecloud.nyclocal.net
>
>
>
>
> --
> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>
>
> _______________________________________________
> petitecloud-general mailing list
> petitecloud-general at lists.petitecloud.nyclocal.net
> http://lists.petitecloud.nyclocal.net/listinfo.cgi/petitecloud-general-petitecloud.nyclocal.net
More information about the petitecloud-general
mailing list