On Thu, 15 Dec 2005 12:02:41 PST, Dave Hansen wrote:
> On Thu, 2005-12-15 at 11:49 -0800, Gerrit Huizenga wrote:
> > I think perhaps this could also be the basis for a CKRM "class"
> > grouping as well. Rather than maintaining an independent class
> > affiliation for tasks, why not have a class devolve (evolve?) into
> > a "container" as described here.
>
> Wasn't one of the grand schemes of CKRM to be able to have application
> instances be shared? For instance, running a single DB2, Oracle, or
> Apache server, and still accounting for all of the classes separately.
> If so, that wouldn't work with a scheme that requires process
> separation.
Yes, it is. However, that may be a sub-case where a single, large
server application actually jumps around from container to container.
I consider that a detail (well, our DB2 folks don't but I'm all for
solving one problem at a time ;-) and we can work some of that out
later. They are less concerned about the application being shared
or part of multiple "classes" simultaneously, as opposed to being
appropriately resource contrained based on the (large) transactions
that they are handling on behalf of a user. So, if it were possible
to jump from one container to another dynamically, then the appropriate
resource management stuff could be handled at some other level.
> There might also be some serious restrictions on containerized
> applications. For instance, taking a running application, moving it out
> of one container, and into another might not be feasible. Is this
> something that is common or desired in the current CKRM framework?
Desired, but primarily for large server applications. And, I don't
think I see much in this patch set that makes that infeasible. If
containers are going to work, you are going to have to have a mechanism
to get applications into them and to move them anyway, right? While
it would be nice if that were dirt-cheap, if it isn't, applications
may have to adapt their usage of them based on the cost. Not a big
deal as I see it.
gerrit
|