libcloud-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tomaz Muraus (JIRA)" <>
Subject [jira] [Commented] (LIBCLOUD-272) Implement CLI tools for libcloud
Date Tue, 19 Nov 2013 03:49:22 GMT


Tomaz Muraus commented on LIBCLOUD-272:

[~mahendra.m] Yeah, there were some debates in the past. Two main questions we talked about

1. Where should the code live? Should it be a separate repository / project?
2. Should CLI be a separate package?

My opinion:

1. I'm not too opinionated about this at the moment. It could live in the same repository
under libcloud/cli/ or potentially libcloud_cli direcory/. First option would make packaging
slightly harder and probably more confusing.

2. Yes, I think it should be a separate package (apache-libcloud-cli) which depends on the
main apache-libcloud one.

And yeah, you and Brian working on that would be great. I will also try to update this ticket
with some more information and goals for the CLI project.

> Implement CLI tools for libcloud
> --------------------------------
>                 Key: LIBCLOUD-272
>                 URL:
>             Project: Libcloud
>          Issue Type: New Feature
>          Components: Core, Storage
>            Reporter: Mahendra M
> This ticket is for implementing a CLI framework for libcloud. Libcloud does a good job
of abstracting cloud operations. If this functionality can be made available via command line
tools, it will be an added advantage for libcloud usage. Some other cloud libraries provide
such functionality (Like Boto).
> Design goals are to provide
> * Command line tools for all of libcloud's functionality
> * Command line options to control auth information
> * Ability to use config files (/etc/libcloud.conf, ~/.libcloud.conf) etc. These options
can be over-written via command line arguments
> * Support for logging (controlled via config files).
> * Provide different commands for each functionality
>   * cloud_compute
>   * cloud_dns
>   * cloud_storage
>   * cloud_lb (load balancing)
> * A hierarchical command structure within each command
>   $ cloud_storage providers - list storage providers
>   $ cloud_storage container <list>/<create>/<delete>
>   $ cloud_storage object <list>/<put>/<get>/...
> * Provide simpler to remember aliases for sub-commands
>   $ cloud_storage container list/ls
> Implementation
> * For providing most of the functionality mentioned in design goals, the python cement
library was used. ( This provides an excellent framework for solving
our design goals. 
> It is tested for Python 2.6, 2.7, 3.1, and 3.2. However, I am not sure of it's support
for Python 2.5.
> * As of now only the cloud_storage command is implemented.
> Config file structure
> [base]
> storage_provider=s3_us_west
> username=*******
> access_key=********
> [log]
> level=NONE
> file=/tmp/cli1.log
> to_console=False
> rotate=False
> max_bytes=512000
> max_file=5
> cloud_storage command
> $ cloud_storage providers - Lists the available storage providers
> Container operations
> $ cloud_storage container <list|ls> - Lists available containers
> $ cloud_storage container create <container_name>
> $ cloud_storage container delete -r -f -v <container_name>
>   By default container is not deleted if it is not empty
>   If -r is provided, all objects are recursively deleted after being prompted for each
>   If -f is provided, all objects are recursively deleted without user prompt
>   If -rfv is mentioned, each deleted object is mentioned in the output
> Object operations
> List objects in a container
> $ cloud_storage object <list|ls> -v <container_name>
>   List all objects in the container
>   If -v is mentioned, object size is also listed out
> Delete an object
> $ cloud_storage object <delete|rm|del|remove> -f <container_name> <object_name>
>   Deletes the object in the container after prompting user for confirmation
>   If -f is specified, user is not prompted
> Upload an object from a local file or Unix pipe
> $ cloud_storage object <put|upload|store|create> <container_name> <object_name>
> $ cat /path/to/file | cloud_storage object put <container_name> <object_name>

> $ cat /path/to/file | cloud_storage object put <container_name> <object_name>
> Download an object ot a local file or unix pipe
> $ cloud_storage object <get|download|stream> <container_name> <object_name>
> $ cloud_storage object get <container_name> <object_name> > /path/to/file
> $ cloud_storage object get <container_name> <object_name> - > /path/to/file
> Other changes
> -------------
> * Minor bug fix in S3
> * was modified to install the cloud_storage command

This message was sent by Atlassian JIRA

View raw message