CM Backend Reference

This module implements a CM backend. To initialize it, an agent, typically a subclass of CmAgent must be registered with cmbackend_init(). Once initialized, CM frontends can send requests and they will be routed to the agent.


exos.api.cmbackend.cmbackend_init(agent, persistent_list=None, config_deps=None)[source]

Initialize the CM backend for this process. As actions and events are received, methods in agent will be called. persistent_list is a list of tables that should be saved in the EXOS config.

config_deps is an optional list of process names as strings. CM will not load this process’ config until these processes have loaded theirs and gone to the READY state.

Action Context

class exos.api.cmbackend.CmContext(cmbe_context, op_cookie, vr_name=None)[source]

Context object for a CM backend request. An instance will be passed to each call into the agent.


Dictionary of parameters passed in the request. This will be populated before the action is called.


Dictionary of response fields. This must be populated by the action.


Desired state of the dirty bit after the action returns. It defaults to True for set and setop methods, but can be overridden by an agent. The dirty bit indicates if the configuration needs to be saved.


True if this request is being handled asynchronously. If async, blocking calls can be made during processing.


True if this request is part of a save operation.


True if this request is part of a load operation.


True if this request is part of a getone operation.


True if this request is part of a getnext operation.


The VR in which this action should be run. If None, then no VR context was set in the request.


Indicate to the client that there’s more entries after this response. Applicable when is_getnext is true.


Stop action execution now and return the given error msg to the client.


Print a message to the CLI, if we were called from a CLI. Otherwise, the message is ignored. Useful for reporting progress on long running operations.


class exos.api.cmbackend.CmAgent(pool=<concurrent.futures.thread.ThreadPoolExecutor object at 0x2f07b10>)[source]

Base class for CM agents.

__init__(pool=<concurrent.futures.thread.ThreadPoolExecutor object at 0x2f07b10>)[source]

Create a new CM agent. pool is the thread pool to use when calling events and actions. By default, the callback pool will be used.

Not all actions and events can be run asynchronously in the thread pool. If CmContext.is_async() return False, then the agent cannot call blocking methods without risking a deadlock.


CM will begin loading our config after this event. At this point, the agent should initialize with a default config. Set actions will be called to provide deltas from the default. In these actions, CmContext.is_load will be True.

A load_start event will always be followed by a load_complete event.


CM has finished loading the module’s config. The agent should now make itself ready to handle backend requests. It should also call ready().

Always called after a load_start event.


CM will start saving our config after this event. Get actions will be called to retrieve the config. In these actions, CmContext.is_save will be True.

A save_start event will always be followed by a save_complete event.


CM has finished saving the module’s config.

Always called after a save_start event.


This event indicates that CM does not have any config to load for this module. The agent should ready itself to handle backend requests. It should also call ready().

Note that if this event is called, load_start and load_complete will not be called.