[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ezjail] Multiple flavours and version 3.1



We use jails in general and ezjail in particular to provide a Unix teaching
environment at Swinburne University. We have a server typically running ~200
jails and we allocate 2-3 jails to each students depending on numbers. While
we have alot of our own extra scripts to do a number of things including
automatically assessing lab work and collecting information from jails, one
feature we would really like is the ability to group jails together (in our
case in classes).

This way we could shutdown/restart/check/manage a whole class(group) of
jails in one go rather than one at a time. We currently use directory
structure to differentiate classes and use our own scripts to parse
directories, but ezjail could manage the groups of jails. In a more
production environment, you could have say all the www jails in one group
while different jails types occupy different groups

Jason

>> Date: Sun, 14 Feb 2010 16:24:55 +0100
>> From: cryx-freebsd AT h3q DOT com
>> To: ezjail AT erdgeist DOT org
>> Subject: Re: [ezjail] Multiple flavours and version 3.1
>>
>> Andrew Hotlab wrote:
>>
>>> Clearly my opinion is influenced by the fact that I need to work with multiple FIBs... do anyone else think that it is not worth it?
>> Don't get me wrong, I think it is worth it and I understand the need for
>> this! I simple don't see this coming into 3.1 on such short notice and I
>> don't see it coming in the way you    suggested. You may also understand
>> that we need to make a cut in features that will make it into 3.1.
>>
>> I guess I can speak for Dirk when I say, its better to think this
>> through and find a generic solution that will also be usable with all
>> the other new features, then to rush it into the release. Its always
>> easy to introduce new stuff, but to remove legacy is a lot harder, e.g.
>> the make.conf problem.
>>
> 
> I understand the point and I agree with you about taking all the time it needs to build a well-designed solution. Thus I may suggest to start thinking about "the next big step" ahead the jail administration interface?
> That is, it would be the right time (after the 3.1 release) to take a break from the "day-today" administrative tasks and tell ourselves what are the main features we need to manage jails in what environments. Then, after we have a clear view of the goals, we can think about the best way to implement the features.
> 
> To be clear, I think ezjail is definitely the best way for jail management today.  I'm only guessing that ezjail has the potential to evolve and became THE tool which could persuade the average system administrator to discover and bring this FreeBSD's workloads consolidation technology in his/her datacenter.
> Maybe I'm too enthusiastic about FreeBSD's jails and the ezjail framework, but I feel here is an opportunity not to be missed! :)
> 
> As soon as my job will allow me, I would like to start with listing all the "requirements" I believe it's important to address for this evolution (even if the features already available in ezjail meet a lot of them!).
> 
> Sincerely
> 
> Andrew
> 
>  		 	   		  
> _________________________________________________________________
> Hotmail: Free, trusted and rich email service.
> https://signup.live.com/signup.aspx?id=60969


-- 

----------
Dr. Jason But
Lecturer
Centre for Advanced Internet Architectures
Faculty of Information and Communication Technologies
Swinburne University of Technology

Phone: +61 3 9214 4839
Email: jbut AT swin.edu DOT au
www:   http://caia.swin.edu.au