The invoker needs to be given some class that implements the ContainerFactoryProvider trait (single method getContainerFactory that when invoked will return an instance of some class that implements the ContainerFactory trait).
The class can be called anything you want, but it does have to implement this trait, which right now means that it will have the word "Container" in lots of places. You'll need to ignore that "Container" isn't actually a container in your implementation and just implement the expected types. Once you have it (UkernelFactoryProvider extends ContainerFactoryProvider), then you can get the system to use your implementation by giving the invoker the command line argument -Dwhisk.spi.ContainerFactoryProvider=whisk.core.containerpool.ukernel.UKernelFactoryProvider --dave From: "Farwell, James C" <james.c.farw...@intel.com> To: "dev@openwhisk.apache.org" <dev@openwhisk.apache.org> Date: 07/19/2018 04:14 PM Subject: RE: Add support for microkernels instead of containers Dave- At one point I had done this, but the host of compiler issues that came up made me want to rethink my approach. (Maybe I'm overly concerned about the word 'Container', but it's EVERYWHERE.) How can I modify SpiLoader to load a class that I determine? --James From: David P Grove [mailto:gro...@us.ibm.com] Sent: Thursday, July 19, 2018 11:41 AM To: dev@openwhisk.apache.org Subject: Re: Add support for microkernels instead of containers Did you remember to have your UkernelFactoryProvider extend ContainerFactoryProvider? For example, see KubernetesContainerFactory.scala. --dave [Inactive hide details for "Farwell, James C" ---07/19/2018 01:24:12 PM---Rodric- Okay, I've created a new Ukernel class to enca]"Farwell, James C" ---07/19/2018 01:24:12 PM---Rodric- Okay, I've created a new Ukernel class to encapsulate my microkernel, a UkernelFactory to pr From: "Farwell, James C" <james.c.farw...@intel.com< mailto:james.c.farw...@intel.com>> To: "dev@openwhisk.apache.org<mailto:dev@openwhisk.apache.org>" <dev@openwhisk.apache.org<mailto:dev@openwhisk.apache.org>> Date: 07/19/2018 01:24 PM Subject: Re: Add support for microkernels instead of containers ________________________________ Rodric- 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 ideas? Thanks, --James >----------------------------------------------------------------------------------- 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. -r
