[PetiteCloud] general thoughts on archicture

Michael Thoreson m.thoreson at c4labs.ca
Sat Feb 15 15:55:04 PST 2014


Get the source for pfSense. They have been doing what I think you want 
to do for a long time now. It is a routing project but it is solely 
based on FreeBSD and they are making the move to FBSD v10 with their 2.2 
version. They have tons of scripts for building a very minimal BSD 
installation and you can take a look at their "single config file" 
method. pfSense as a whole is just a fancy web ui that calls php\perl 
and i think some bash scripts to configure the host's applications that 
do the hard work. Also they have a great package framework you may be 
able to use as an example.


On 15/02/2014 5:41 PM, Aryeh Friedman wrote:
> One way to think of petitecloud is nothing more then a brillian script 
> generator.  Namely it does all the precondtion checks on it's own and 
> then generates a serialized script (no loops or conditionals) to the 
> task it needs to do this.
>
> Currently some of this done by doing one shot commands straight from 
> the business logic (and the underlying drivers).   This makes stuff 
> fast and easy for typical cases but some of the flexibility that we 
> are talking about it breaks it very fast.
>
> An example of such a design dilemma is hyperv support spread across 
> muiltiple host OS's.   Namely the actual syntax (and sometimes the 
> semantics) for how a given hyperv is called on one OS is different 
> then on a different host OS.  Also sometimes the semantics even differ 
> between the same hyperv on the same OS.  For example the only 
> difference between "bhyve-freebsd" and "bhyve-linux" is the name of 
> the bhyveload and how it is called (namely you need to also 
> make/populate the device map dir).
>
> We realized a few weeks ago that this created a "N time M" problem in 
> how many classes we have (i.e. we would need to subclass each hyperv 
> for each supported OS).   This gets really hard to manage very quickly 
> and is due to it's complexity likely to be the source of many bugs 
> (i.e. bugs not in the scripts generated but the wrong script be 
> generated [and within the context it was generated it is correct]).
>
> An other solution is we just do a partial externalization of the 
> scripts themselves.   This way we just do the mixing and matching at 
> runtime and not compile time and the lack of a script template 
> indicates lack of support (one major issue we had under the above 
> design was how to handle unsupported operations).
>
> In order to do this right we would need to do the following:
>
> 1. Come up with a universal script templating system (i.e. tell PC 
> where the blanks to be filled in are)
>
> 2. Refactor PC so all calls to OSCommand (except trivial ones that are 
> only generation prep calls) they all go through some form of script
>
> 3. Redesign most of the sub-business logic architecture to be nothing 
> but smart script callers (they internalize far too much right now)
>
> -- 
> 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