[PetiteCloud] general thoughts on archicture

[Aryeh Friedman]

Also doing this partial externalization also creates a rats nest of
security concerns (almost all stuff that can be handled within Java has to
run as root)..  we are truly on the fence right now on which way to go


On Sat, Feb 15, 2014 at 6:55 PM, Michael Thoreson <m.thoreson at c4labs.ca>wrote:

> 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
>>
>
> _______________________________________________
> petitecloud-general mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.petitecloud.nyclocal.net/pipermail/petitecloud-general-petitecloud.nyclocal.net/attachments/20140215/26b8def7/attachment-0003.htm>