[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