[Asterisk-Dev] Asterisk test-o-matic

[Julian Lyndon-Smith]

Umm,

Not such a crazy idea (unless we're both mad) - I posted something 
similar a few days ago to the astlinux mailing list:

More comments inline:

Julian

-----Original Message-----
From: astlinux-users-bounces at jail1.krisk.org 
[mailto:astlinux-users-bounces at jail1.krisk.org] On Behalf Of Julian 
Lyndon-Smith
Sent: lundi, 22. août 2005 22:55
To: astlinux-users at jail1.krisk.org
Subject: [Astlinux-users] "pluggable" asterisk

Just thinking of a whacked-out idea, but one that may be useful:

I am wanting to use astlinux, because of the booting from cd-rom / cf
feature: it means that anyone of my team who can fit a pci card can then 
also install and run Linux and asterisk without having to go through the
   Linux installation process.

However, we also use several versions of asterisk, from 1.09 through to 
CVS-HEAD (for our "bleeding edge" clients).

Would it be possible to have astlinux as two separate "bits" - astlinux 
(the Linux portion) and astlinux (the asterisk portion). Astlinux
(Linux) could load / copy / insert the required version of asterisk from 
either the cd, cf, tftp etc etc.

This would help, for example, if a patch to asterisk was released - I 
could recompile *, and have that load instead of the default * that is 
residing on the astlinux media, sort of a "pluggable" pbx.

Anyone think that this is just whacked, or has some merit ?

Julian

Kristian Kielhofner wrote:
> Hello everyone,
> 
>     So, a crazy idea just hit me...  What about making an Asterisk 
> patch-o-matic?  As some of you know, I created AstLinux, a distro for 
> running Asterisk.  It has turned out to be quite adaptable, and I am 
> wondering if it might be able to help with another problem: Asterisk 
> patches.
> 
>     It is my opinion that people would be much more willing/able to try 
> Asterisk patches/CVS Head/etc if it didn't mean patching Asterisk, 
> re-compiling, and possibly breaking their production systems (they 
> should have test machines, anyways, right?).
> 
>     For instance, let's say that I had a machine with a Digium te110p 
> and four PRI's connected to it.  Every day from 9-5  it is handling 
> calls for my call center or whatever.  However, after hours it is just 
> sitting there, idle.  Wouldn't it be cool if I could boot from a CD (or 
> USB flash drive, USB hard drive, alternate hard drive, etc) and try out 
> a test version of Asterisk, new CVS, new patches, etc?  If something 
> goes wrong, reboot, and poof! you are back to your original environment 
> and configuration, no harm done.
> 
>     I am currently doing a lot of work on an automated 
> Asterisk/zaptel/libpri/AstLinux build system that will allow someone to 
> build Asterisk/zaptel/libpri (with AstLinux) with a single command (it 
> is practically done).  It would not be difficult to add the ability to 

That would be great - I was looking for a way of doing that. When? When? 
(can you tell I'm desperate!)

> pull down CVS HEAD (or CVS of you choosing), grab any misc. patches 
> (again, of your choosing), and rebuild the AstLinux disk image with all 
> of this included.  Toss in some debug tools like strace and valgrind and 
> I say we are in business!
> 
>     To get really crazy (I'll have to think about this one), what if we 
> do this all from a web interface like rom-o-matic.net?  Go to the web 
> GUI, pick your Asterisk/libpri/zaptel version, pick your patches to 
> test, click a button, download your AstLinux disk image, write it to 
> CD/HD, etc, and test!

thinstation.org has a web-o-matic to create a custom linux environment 
for thin clients. We use it all the time!

http://struktur.kemi.dtu.dk/thinstation/TS

> 
>     For the web interface we would NOT be able to build 
> Asterisk/libpri/zaptel on the fly for every request, there would have to 
>  be selection of images that are built nightly, or whatever.
> 
> How about it?  Good idea?  Bad idea?  Wrong list? (oh no, not that) 
> Suggestions please!

Oh, a great idea.

> 
>     P.S. - I realize that it would have been better to think of this 
> months ago to better prepare 1.2, it's a little late now.  Oh well, you 
> can't always be in the right place at the right time :).   
>