On 02/19/2017 12:15 PM, Patrick Donnelly wrote: > 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. Using rados objects for this is not really feasible. It would be incredibly complex within the osd - it involves multiple objects, cache invalidation, and has all kinds of potential issues with consistent versioning and atomic updates across objects. The simple solution of loading modules from the local fs sounds way better to me. Putting modules on all osds and reloading the modules or restarting the osds seems like a pretty simple deployment model with any configuration management system. That said, for research purposes you could resurrect something like the ability to load modules into the cluster from a client - just store them on the local fs of each osd, not in rados objects. This was removed back in 2011: https://github.com/ceph/ceph/commit/7c04f81ca16d11fc5a592992a4462b34ccb199dc https://github.com/ceph/ceph/commit/964a0a6e1326d4f773c547655ebb2a5c97794268 Josh
 |