On Sat, Feb 18, 2017 at 2:55 PM, Noah Watkins <noahwatkins at gmail.com> wrote: > The least intrusive solution is to simply change the sandbox to allow > the standard file system module loading function as expected. Then any > user would need to make sure that every OSD had consistent versions of > dependencies installed using something like LuaRocks. This is simple, > but could make debugging and deployment a major headache. A locked down require which doesn't load C bindings (i.e. only load .lua files) would probably be alright. > A more ambitious version would be to create an interface for users to > upload scripts and dependencies into objects, and support referencing > those objects as standard dependencies in Lua scripts as if they were > standard modules on the file system. Each OSD could then cache scripts > and dependencies, allowing applications to use references to scripts > instead of sending a script with every request. This is very doable. I imagine we'd just put all of the Lua modules in a flattened hierarchy under a RADOS namespace? The potentially annoying nit in this is writing some kind of mechanism for installing a Lua module tree into RADOS. Users would install locally and then upload the tree through some tool. -- Patrick Donnelly
 |