Allow dynamic service registration and ability for local processes to register service names #1753

Add a service_get_uuid() call to the broker's service switch module. This will be required to allow service deregistration when dynamic service registration is added to the broker.

Add a module_lookup() function to the broker's modhash interface to allow a lookup of modules by their uuid. This will be necessary for dynamic service registration/deregistration.

Add new RPCs service.add and service.remove to the broker, which allow modules to dynamically register alternate service names for which they will accept requests. Each of these RPCs take a single member payload with key "service" set to the name of the requested service to register (service.add) or deregister (service.remove). This allows a single module to register under more than 2 service names, and will eventually allow locally connected API clients to register services via the local conneector.

Add flux_service_register and flux_service_unregister to the libflux API. These functions call the broker's `service.add` and `service.remove` methods on behalf of the caller.

Instead of using the MOD_SERVICE macro to register the content-sqlite module under the "content-backing" service name, use the new service.add RPC offered by the broker. Since the name must be registered before entering the reactor, we use a synchronous RPC for `service.add`. This should have the equivalent effect of the previous MOD_SERVVICE() usage.

Remove support for the optional "mod_service" symbol in modules. Support for this symbol is no longer needed after introduction of the service.add/service.remove RPCs.

Abstract the client response code out of internal_request() and create a reusable client_repond() function. This not only makes a new reusable function, but breaks up the internal_request() function, which was getting a bit long (and will get longer soon.)

Problem: API connected clients cannot send messages of type FLUX_MSGTYPE_RESPONSE. In order to allow these clients to register services, we must allow responses to flow through the connector to the broker.

This commit enables service registration from connector-local connected clients via the `service.add` RPC. Since the broker isn't currently capable of multi-hop routing of request messages, this feature is implemented by adding a service lookup hash to the connector-local module, which can then register with the broker on behalf of clients, and take care of routing requests to the client which has requested registration for the service matching those requests. The connector-local module will intercept both service.add and service.remove messages, and handle them appropriately. It will additionally automatically deregister all services currently owned by a client on disconnect. Fixes flux-framework#1689.

Problem: The connector-local module throws an error and drops any request messages from connected clients which do not have the FLUX_MSGFLAG_ROUTE flag. Currently the python flux_send() binding does not set this flag for requests, so python scripts are unable to use this interface. It is arguable that the local connector *should* drop requests without FLUX_MSG_ROUTE set, because this means that the msg being sent via the connector is not a valid request. However, since we know all requests will need FLUX_MSGFLAG_ROUTE set, and the connector is accepting messages on behalf of clients, is there a harm in ensuring the route flag is set on all requests? This reduces the burden of "encoding" requests from the API clients to the API itself, which may or may not be the correct approach. Until the python bindings can encode a request, though, add code to the connector-local module to enable routes on all request messages.

In bindings/pythoon/flux/core/handle.py MessageWatcher was imported from flux.core.watchers when the implementation is actually in flux.message. Fix the bad path.

Message payload setter should use the set_string method not set_json.

Ensure self.destruct member of Message objects is set properly to avoid double-free of flux_msg_t in situations where python doesn't have ownership of the msg object. Fixes flux-framework#1777

The MessageWatcher destroy() method was calling the incorrect C function. Update the name to `flux_msg_handler_destroy` to avoid errors when calling watcher.destroy().

Add code to pymod to register a service name dynamically based on the name of the script being loaded. This allows a python-based module to register any service name, not just `pymod` and handle request messages for that service. For example, an echo server may be loaded with flux module load pymod echo and process messages matching topic string "echo.*". Code to *deregister* the automatic `pymod` service name is also included in this commit but commented out, because, though now theoretically possible, it is not currently safe to load a second pymod module with a different python script (and there is no way to unload just one of two modules with the same name)

Update the echo.py example pymod script given the updated pymod module's capability to register a service name based on the loaded script. This version starts a simple echo service that accepts echo.* messages and replies with the same payload.

Export the name of the discovered libpython DSO name to config.h so that code that may need to know which libpython Flux was built against doesn't have to rediscover the name.

Problem: On some distributions (e.g. Ubuntu 18.04) _cffi_backend.so is not linked against libpython DSO, and since pymod.so is loaded with RTLD_LOCAL, symbols from libpython may not be visble to cffi, and thus `import cffi` fails with unresolved symbol errors. (This may be a general problem with any python module that is not linked with libpython in this scenario) To fix, promote libpython symbols to global by calling dlopen(3) on libpython (as found by configure) with RTLD_GLOBAL.

Problem: python or one of its modules seems to clear relative paths from PYTHONPATH, and this is preventing the t9001-pymod.t test from working problem with a failure to import the 'flux' module. The problem seems to be resolved using absolute paths to top_srcdir and top_builddir, so just use this as the solution for now.

Ensure pymod module can be loaded with the echo.py example, and that the example echo server can handle requests.

Add python/t1000-service-add-remove.py to the testsuite to test the connector-local usage of `service.add` and `service.remove`.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow dynamic service registration and ability for local processes to register service names #1753

Allow dynamic service registration and ability for local processes to register service names #1753

Commits on Oct 30, 2018