openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farwell, James C" <>
Subject Re: Add support for microkernels instead of containers
Date Thu, 19 Jul 2018 17:23:54 GMT
Okay, I've created a new Ukernel class to encapsulate my microkernel, a UkernelFactory to
produce Ukernels, and a UkernelFactoryProvider to instantiate a Factory.  I've updated the
whisk.spi object (in reference.conf) to name the desired class (whisk.core.ukernel.UkernelFactoryProvider).
 Everything compiles, but when I try to deploy I get the exception 'whisk.core.ukernel.UkernelFactoryProvider$
cannot be cast to whisk.core.containerpool.ContainerFactoryProvider'.
I have searched, but cannot find any reason that SpiLoader should object to loading a class
other than whisk.core.containerpool.ContainerFactoryProvider.
I'm obviously missing something, but I can't figure out what it is.  Does anyone have any
Hi James

There's an abstract interface to the execution unit in the invoker: Start/Pause/Resume/Stop/Logs.
You can select the implementation through a configuration deployment (SPI).

There was some work on using the interface I alluded to for unikernels. I'd imagine the interface
it can be adapted for working with a process, microkernel, ...

I'm suggesting it's a drop in replacement but at face value I don't see that it's necessary
to be too invasive. The openwhisk core is really about starting/pausing/resuming/stopping
an execution unit (which happens to be a container today).

I think containers are too coarse grained an execution unit for functions and expect technology
to change in the future. But when/how long it will take... we'll see. I'm curious to see how
your work unfolds with OpenWhisk and we're happy to help.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message