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
