You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This set action APIs enable the manual management of Jaseci actions and action
libraries/sets. Action libraries can be loaded locally into the running instance of
the python program, or as a remote container linked action library. In this mode,
action libraries operate as micro-services. Jaseci will be able to dynamically
and automatically make this decision for the user based on online monitoring and
performance profiling.
actions load local
cli: actions load local | api: actions_load_local | auth: admin
file: str (*req), ctx: dict ({})
This API will dynamically load a module based on a python file. The module
is loaded directly into the running Jaseci python instance. This API also
makes an attempt to auto detect and hot load any python package dependencies
the file may reference via python's relative imports. This file is assumed to
have the necessary annotations and decorations required by Jaseci to recognize
its actions.
Params
Params
file -- The python file with full to load actions from.
(i.e., ~/local/myact.py)
This API will dynamically load a set of actions that are present on a remote
server/micro-service. This server must be configured to interact with Jaseci
properly. This is easily achieved using the same decorators used for local
action libraries. Remote actions allow for higher flexibility in the languages
supported for action libraries. If an library writer would like to use another
language, the main hook REST api simply needs to be implemented. Please
refer to documentation on creating action libraries for more details.
Params
Params
url -- The url of the API server supporting Jaseci actions.
This API will dynamically load a module using python's module import format.
This is particularly useful for pip installed action libraries as the developer
can directly reference the module using the same format as a regular python
import. As with load local, the module will be loaded directly into the running
Jaseci python instance.
Params
Params
mod -- The import style module to load actions from.
(i.e., jaseci_ai_kit.bi_enc)
actions list
cli: actions list | api: actions_list | auth: admin
name: str ()
This API is used to list the loaded actions active in Jaseci. These actions
include all types of loaded actions whether it be local modules or remote
containers. A particular set of actions can be viewed using the name parameter.
Params
Params
name -- The name for a library for which to filter the view of shown
actions. If left blank all actions from all loaded sets will be shown.
actions module list
cli: actions module list | api: actions_module_list | auth: admin
The architype set of APIs allow for the addition and removing of
architypes. Given a Jac implementation of an architype these APIs are
designed for creating, compiling, and managing architypes that can be
used by Jaseci. There are two ways to add an architype to Jaseci, either
through the management of sentinels using the sentinel API, or by
registering independent architypes with these architype APIs. These
APIs are also used for inspecting and managing existing arichtypes that
a Jaseci instance is aware of.
architype register
cli: architype register | api: architype_register | auth: user
This register API allows for the creation or replacement/update of
an architype that can then be used by walkers in their interactions
of graphs. The code argument takes Jac source code for the single
architype. To load multiple architypes and walkers at the same time,
use sentinel register API.
Params
Params
code -- The text (or filename) for an architypes Jac code
encoded -- True/False flag as to whether code is encode
in base64
snt -- The UUID of the sentinel to be the owner of this
architype
Returns
Returns - Fields include
'architype': Architype object if created otherwise null
'success': True/False whether register was successful
'errors': List of errors if register failed
'response': Message on outcome of register call
architype get
cli: architype get | api: architype_get | auth: user
code -- The text (or filename) for an architypes Jac code/ir
mode -- Valid modes: {default, code, ir, }
Returns
Returns - Fields include (depends on mode)
'success': True/False whether set was successful
'errors': List of errors if set failed
'response': Message on outcome of set call
architype list
cli: architype list | api: architype_list | auth: user
cli: master active set | api: master_active_set | auth: user
name: str (*req)
NOTE: Specail handler included in general interface to api
master active unset
cli: master active unset | api: master_active_unset | auth: user
n/a
No documentation yet.
master active get
cli: master active get | api: master_active_get | auth: user
detailed: bool (False)
No documentation yet.
master self
cli: master self | api: master_self | auth: user
detailed: bool (False)
No documentation yet.
master delete
cli: master delete | api: master_delete | auth: user
name: str (*req)
No documentation yet.
APIs for object
...
global get
cli: global get | api: global_get | auth: user
name: str (*req)
No documentation yet.
object get
cli: object get | api: object_get | auth: user
obj: Element (*req), depth: int (0), detailed: bool (False)
No documentation yet.
object perms get
cli: object perms get | api: object_perms_get | auth: user
obj: Element (*req)
No documentation yet.
object perms set
cli: object perms set | api: object_perms_set | auth: user
obj: Element (*req), mode: str (*req)
No documentation yet.
object perms default
cli: object perms default | api: object_perms_default | auth: user
mode: str (*req)
No documentation yet.
object perms grant
cli: object perms grant | api: object_perms_grant | auth: user
obj: Element (*req), mast: Element (*req), read_only: bool (False)
No documentation yet.
object perms revoke
cli: object perms revoke | api: object_perms_revoke | auth: user
obj: Element (*req), mast: Element (*req)
No documentation yet.
info
cli: info | api: info | auth: public
n/a
No documentation yet.
APIs for prometheus
No documentation yet.
prometheus metrics list
cli: prometheus metrics list | api: prometheus_metrics_list | auth: admin
n/a
No documentation yet.
prometheus pod list
cli: prometheus pod list | api: prometheus_pod_list | auth: admin
namespace: str (), exclude_prom: bool (False)
No documentation yet.
prometheus pod info
cli: prometheus pod info | api: prometheus_pod_info | auth: admin
namespace: str (), exclude_prom: bool (False), timestamp: int (0), duration: int (0)
No documentation yet.
prometheus node info
cli: prometheus node info | api: prometheus_node_info | auth: admin
namespace: str (), exclude_prom: bool (False), timestamp: int (0), duration: int (0)
No documentation yet.
APIs for queue
APIs used for celery configuration and monitoring
walker queue check
cli: walker queue check | api: walker_queue_check | auth: user
task_id: str ()
No documentation yet.
walker queue wait
cli: walker queue wait | api: walker_queue_wait | auth: user
task_id: str (*req), timeout: int (30)
No documentation yet.
APIs for sentinel
A sentinel is a unit in Jaseci that represents the organization and management of
a collection of architypes and walkers. In a sense, you can think of a sentinel
as a complete Jac implementation of a program or API application. Though its the
case that many sentinels can be interchangeably across any set of graphs, most
use cases will typically be a single sentinel shared by all users and managed by an
admin(s), or each users maintaining a single sentinel customized for their
individual needs. Many novel usage models are possible, but I'd point the beginner
to the model most analogous to typical server side software development to start
with. This model would be to have a single admin account responsible for updating
a single sentinel that all users would share for their individual graphs. This
model is achieved through using \texttt{sentinel_register},
\texttt{sentinel_active_global}, and \texttt{global_sentinel_set}.
sentinel register
cli: sentinel register | api: sentinel_register | auth: user
These User APIs enable the creation and management of users on a Jaseci machine.
The creation of a user in this context is synonymous to the creation of a master
Jaseci object. These APIs are particularly useful when running a Jaseci server
or cluster in contrast to running JSCTL on the command line. Upon executing JSCTL
a dummy admin user (super_master) is created and all state is dumped to a session
file, though any users created during a JSCTL session will indeed be created as
part of that session's state.
user create
cli: user create | api: user_create | auth: public
This API is used to create users and optionally set them up with a graph and
related initialization. In the context of
JSCTL, any name is sufficient and no additional information is required.
However, for Jaseci serving (whether it be the official Jaseci server, or a
custom overloaded server) additional fields are required and should be added
to the other fields parameter as per the specifics of the encapsulating server
requirements. In the case of the official Jaseci server, the name field must
be a valid email, and a password field must be passed through other fields.
A number of other optional parameters can also be passed through other feilds.
\vspace{3mm}\par
This single API call can also be used to fully set up and initialize a user
by leveraging the global init parameter. When set, this parameter attaches the
user to the global sentinel, creates a new graph for the user, sets it as the
active graph, then runs an initialization walker on the root node of this new
graph. The initialization walker is identified by the name assigned to
global init. The default empty string assigned to global init indicates this
global setup should not be run.
Params
Params
name -- The user name to create. For Jaseci server this must be a valid
email address.
global_init -- The name of an initialization walker. When set the user is
linked to the global sentinel and the walker is run on a new active graph
created for the user.
global_init_ctx -- Context to preload for the initialization walker
other_fields -- This parameter is used for additional fields required for
overloaded interfaces. This parameter is not used in JSCTL, but is used
by Jaseci server for the additional parameters of password, is_activated,
and is_superuser.
user delete
cli: user delete | api: user_delete | auth: admin
name: str (*req)
This API is used to delete a user account.
Params
Params
name -- The user name to delete. For Jaseci server this must
be a valid email address.
user deleteself
cli: user deleteself | api: user_deleteself | auth: user
n/a
This API is used to delete a user account.
APIs for walker
The walker set of APIs are used for execution and management of walkers. Walkers
are the primary entry points for running Jac programs. The
primary API used to run walkers is \textbf{walker_run}. There are a number of
variations on this API that enable the invocation of walkers with various
semantics.