On 02/19/2017 12:15 PM, Patrick Donnelly wrote:
On Sat, Feb 18, 2017 at 2:55 PM, Noah Watkins <noahwatkins@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
