Column labels for the execution summary table
Message displayed if insufficient auth settings are specified, either on the command line or in environment variables. Shamelessly copied from python-swiftclient.
path/filename of the system.map (job description) in every zapp
An extension of the swiftclient.Connection which has the capability of posting ZeroVM jobs to an instance of ZeroCloud (running on Swift).
Authenticate with the provided credentials and cache the storage URL and auth token as self.url and self.token, respectively.
Parameters: |
|
---|
Upload all of the necessary files for a zapp.
Returns the name an uploaded index file, or the target if no index.html file was uploaded.
Parameters: | force (bool) – Force deployment, even if the target container is not empty. This means that files could be overwritten and could cause consistency problems with these objects in Swift. |
---|
Generate the boot/system.map file contents from the zapp config file.
Parameters: | zapp – dict of the contents of a zapp.yaml file. |
---|---|
Returns: | dict of the job description |
Generate sequence of (container-and-file-path, data, content-type) tuples.
Build an execution summary table from a job execution response.
Parameters: | resp (dict) – Response dictionary from job execution. Must contain a headers key at least (and will typically contain status and reason as well). |
---|---|
Returns: | Tuple of total execution time (str), prettytable.PrettyTable containing the summary of all node executions in the job. |
Extract a stats table from execution HTTP response headers.
Stats include things like node name, execution time, number of reads/writes, bytes read/written, etc.
Parameters: | headers (dict) – dict of response headers from a job execution request. It must contain at least x-nexe-system, x-nexe-status, x-nexe-retcode, x-nexe-cdr-line. |
---|---|
Returns: | Tuple of two items. The first is the total time for the executed job
(as a str). The second is a table (2d list) of execution data
extracted from X-Nexe-System and X-Nexe-Cdr-Line headers. Each row in the table consists of the following data:
|
Parameters: |
|
---|
Here’s a typical usage example, with typical input and output:
>>> swift_service_url = ('http://localhost:8080/v1/'
... 'AUTH_469a9cd20b5a4fc5be9438f66bb5ee04')
>>> zapp_path = 'test_container/myapp.zapp'
>>> _get_swift_zapp_url(swift_service_url, zapp_path)
'swift://AUTH_469a9cd20b5a4fc5be9438f66bb5ee04/test_container/myapp.zapp'
Guess the auth version from first the command line args and/or envvars.
Command line arguments override environment variables, so we check those first.
Auth v1 arguments:
Auth v2 arguments:
If all of the v1 and v2 arguments are specified, default to 1.0 (this is how python-swiftclient behaves).
If no auth version can be determined from the command line args, we check environment variables.
Auth v1 vars:
Auth v2 vars:
The same rule above applies; if both sets of variables are specified, default to 1.0.
If no auth version can be determined, return None.
Parameters: | args – argparse.Namespace, representing the args specified on the command line. |
---|---|
Returns: | ‘1.0’, ‘2.0’, or None |
Parameters: |
|
---|
Parameters: |
|
---|---|
Returns: | Extracted contents of the boot/system.map with the swift path to the .zapp added to the devices for each group. So if the job looks like this: [{'exec': {'args': 'hello.py', 'path': 'file://python2.7:python'},
'devices': [{'name': 'python2.7'}, {'name': 'stdout'}],
'name': 'hello'}]
the output will look like something like this: [{'exec': {u'args': 'hello.py', 'path': 'file://python2.7:python'},
'devices': [
{'name': 'python2.7'},
{'name': 'stdout'},
{'name': 'image',
'path': 'swift://AUTH_abcdef123/test_container/hello.zapp'},
],
'name': 'hello'}]
|
Bundle the project under root.
Create a ZeroVM application project by writing a default zapp.yaml in the specified directory location.
Parameters: |
|
---|---|
Returns: | List of created project files. |
Execute a zapp remotely on a ZeroCloud deployment.
Returns: | A dict with response data, including the keys ‘status’, ‘reason’, and ‘headers’. |
---|
Starting from the cwd, search up the file system hierarchy until a zapp.yaml file is found. Once the file is found, return the directory containing it. If no file is found, raise a RuntimeError.