Hi Dominic, Lean OpenWhisk is not supposed to run on the IoT devices such as sensors and actuators directly. It's supposed to run on a Gateway node that controls the sensors and actuators connected to it. Think AWS GreenGrass, Azure Functions on IoT Edge. This is the same use case. The data from a sensor, say a temperature sensor reading, will be sent to the Gateway via MQTT or HTTP or whatever and there will be a provider at the Gateway (say, an MQTT feed, which is outside of the OW core and this proposal) that can trigger an action on a trigger previously created via a feed action for this type of feed.
This proposal is strictly about making OW a better fit for small Gateway form factors. It's true that there are some other tools we need to provide to make OW@Edge a feasible option for developers, but they are outside of the core and this specific proposal and merit a separate discussion. Cheers. -- david On 2018/07/16 11:40:35, Dominic Kim <[email protected]> wrote: > Dear David. > > This is an awesome idea!! > > Is this to control IoT devices programmatically? > If yes, there would be many different types of IoT devices especially in > terms of their capabilities such as lighting sensors, thermometer, robot > cleaner, and so on. > > Then do you have anything in mind to take care of heterogeneous sets of > edge nodes? > There is a possibility that some actions should only run on thermometers, > while the others should run on lighting sensors. > > If you are trying to install "one-for-all" OpenWhisk cluster rather than > having separate OpenWhisk clusters for each device types, how will you > manage heterogenous container pools and properly assign relevant actions to > them? > > > Best regards, > Dominic > > > 2018-07-16 20:24 GMT+09:00 Markus Thoemmes <[email protected]>: > > > Hi David, > > > > please send your PR for sure! IIRC we made the Loadbalancer pluggable > > specifically for this use-case. Sounds like a great addition to our > > possible deployment topologies. > > > > Shameless plug: Would you review the architecture I proposed here: > > https://lists.apache.org/thread.html/29289006d190b2c68451f7625c13bb > > 8020cc8e9928db66f1b0def18e@%3Cdev.openwhisk.apache.org%3E > > > > In theory, this could make your proposal even leaner in the future. Don't > > hear me say though we should hold this back, we can absolutely go forward > > with your implementation first. Just wanted to quickly verify this use-case > > will also work with what we might plan for in the future. > > > > Cheers, > > Markus > > > > >
