Anvil-access-module

From Alteeve Wiki
Jump to navigation Jump to search

 Alteeve Wiki :: Man Pages :: Anvil-access-module

NAME

anvil-access-module - external-facing interface to Anvil! internal functions

SYNOPSIS

To use interactively
' anvil-access-module
To process a script
' anvil-access-module --script <script_pathname>
To read from database
' anvil-access-module --query <sql_command> [ --uuid' <database_uuid> ]
To write to database
' anvil-access-module --mode write --query <sql_command> [ --uuid' <database_uuid> ]
To execute a Perl subroutine
' anvil-access-module --sub <subroutine_name> [ --sub-module' <perl_module_name> ] [ --sub-params <json_object> ]
To access the data hash
' anvil-access-module --data <json_object> [ --predata' <json_array> ]

DESCRIPTION

anvil-access-module exposes access to Anvil! perl modules to the command line, allowing non-perl executables to reuse existing functionalities. Upon execution, this script creates an instance of Anvil::Tools which provides reference to all *.pm instances under the Anvil/Tools directory.

OPTIONS

--data <json_object>

Specifies the data structure to copy from the data hash under the global anvil object. The script will recursively traverse each of the given JSON object's properties and pick values from the anvil->data hash for each property key that exists.

--emit-events

Toggles whether to print event lines before and/or after operations. For example, line 'connected' will be printed after establishing the database connection when --emit-events is given. The event lines should enable other programs to parse and activate additional logic as necessary.

--mode <read | write>

Used along with --query to specify whether the provided sql should be executed in read or write mode. For example, a SELECT sql command should be executed in read mode, and an UPDATE sql command should be executed in write mode.

--predata <json_array>

Specifies a 2-dimentional JSON array for specifying 1 or more subroutines to execute in ascending index order before extracting data from the data hash. Each element of the top-level array contains a 2nd-level array. Each 2nd-level array should only have 2 elements, where index 0 is a string in Perl syntax that identifies the target subroutine, and index 1 is a JSON object with parameters to supply to the target subroutine.

--query <sql_command>

Specifies a SQL command to execute. Also see --mode, which controls whether the given SQL command will be executed in read or write mode.

When in read mode, the output should be a 2 dimentional array where the 1st-level is rows and the 2nd-level is each value matching the given columns.

When in write mode, the output should be a return code where 0 is success and non-zero is write error.

--script <filepath>

Specifies a file that contains actions; these actions are the same as ones to provide to interactive mode.

An action must start with a character from one of r (read), w (write), or x (execute). The action character can optionally be prefixed with a UUID which will be used to prefix the corresponding output of the action.

Each line should follow one of the following formats: ' [ <line_uuid> ] r [ uuid=<database_uuid> ] <sql_script> ' [ <line_uuid> ] w [ uuid=<database_uuid> ] <sql_script> ' [ <line_uuid> ] x <module->subroutine> [ space-separated_positional_subroutine_parameters... ] ' [ <line_uuid> ] x <data->hash> [ = <value_to_set> ]

--sub <subroutine_name>

Specifies the target subroutine to execute in perl syntax, which can include the arrow notation (->).

--sub-module <perl_module_name>

Used with --sub to specify the perl module name of the target subroutine. It is expected to be the file name (excluding extension) of any .pm file under the Anvil/Tools directory.

--sub-params <json_object>

Used with --sub to specify the parameters to provide to the target subroutine. The given JSON object will be converted to a perl hash and passed to the specified subroutine.

--uuid <database_uuid>

Used with --query to specify a database to execute the given SQL command.

EXAMPLES

Select hosts from database
$ anvil-access-module --query "SELECT host_uuid, host_name FROM hosts;"
> [["09a3ac2f-5904-42a6-bb5e-28cffc7fa4af","mockhost01"],["df3653e3-7378-43e2-be2a-ead1b8aee881","mockhost02"],...]

OR interactively:

r SELECT host_uuid, host_name FROM hosts;
Get local host name
$ anvil-access-module --sub 'host_name' --sub-module 'Get' --sub-params '{ "debug": 1 }'
> {"sub_results":"..."}

OR interactively:

x Get->host_name '{ "debug": 1 }'
Get database data and 1 path from data hash
$ anvil-access-module --data '{ "database": true, "path": { "exe": { "grep": true } } }'
> {"database":{...},"path":{"exe":{"grep":"/usr/bin/grep"}}}

OR interactively:

x data->database
x data->path->exe->grep
Get network data collected and recorded by the Network->get_ips() subroutine
$ anvil-access-module --predata '[ ["Network->get_ips", { "debug": 1 }] ]' --data '{ "network": true }'
> {"network":{...}}

OR interactively:

x Network->get_ips '{ "debug": 1 }'
x data->network

EXIT STATUS

0
Successful program execution.
1
Usage, syntax, file access, or database connection error.

AUTHOR

Written by Yanhao Lei, Alteeve staff and the Anvil! project contributors.

REPORTING BUGS

Report bugs to users@clusterlabs.org

 

Any questions, feedback, advice, complaints or meanderings are welcome.
Alteeve's Niche! Alteeve Enterprise Support Community Support
© 2025 Alteeve. Intelligent Availability® is a registered trademark of Alteeve's Niche! Inc. 1997-2025
legal stuff: All info is provided "As-Is". Do not use anything here unless you are willing and able to take responsibility for your own actions.