[
https://issues.apache.org/jira/browse/LIBCLOUD-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826349#comment-13826349
]
John Carr commented on LIBCLOUD-272:
------------------------------------
My position is still: I use libcloud as a library. For me, adding CLI stuff to
the core library is at best superfluous noise and at worse a source of
confusing bonus scripts in bin/ for my users and dependencies getting installed
that neither of us want.
I'd like to see libcloud-cli as a very competent tool with nice UI, lots of
validation and helpful error messages, i18n stuff and support for advanced
shell scripting (like iterating over a list of compute nodes and doing stuff to
them). I also see it as a subproject, maybe with a name that doesn't even
mention libcloud.
That is a tool that i'd probably use (but i wouldn't ship it with binaries i
build, and I wouldn't have it installed in the venv of websites i look after).
So right now i'm in favour of a separate repo (or having a libcloud_cli package
in the main repo until we have a working prototype). Ultimately by having a
separate repo and release cycle we can use it to validate we haven't broken our
API in master.
In response to some of the arguments presented here:
* I think the "sync" thing is a human issue, not a technical one. One that
people cope with all the time in the real world. Look at celery. Sol is keeping
celery, amqplib, billiards and kombu working together just fine. And he has
very limited resources and much more complicated API interactions. Also we are
pretty good at API stability, so i don't see a new libcloud release breaking
the tool.
* Boto doesn't introduce dependencies on cliff/cement/etc. But to create a
nice UI we would want to use something like this, right? Boto does install 21
binaries in bin/ with poor naming conventions if i'm reading the code right.
My view depends on what people want libcloud-cli to actually be. If it is just
a toy for us to test our API's on then i'm not too worried if its a version
behind doesn't matter too much. If people actually want a real tool they can
use on a day to day basis to manage cloud services I think it needs to be given
a life outside of libcloud and freedom to use the best tools for the job
without worrying about whether they impact libcloud users.
And for me... In terms of what is best for libcloud-cli and its potential
users... a separate project that is able to ship fixes and iterate on its UI
without waiting for libcloud core is good.
> Implement CLI tools for libcloud
> --------------------------------
>
> Key: LIBCLOUD-272
> URL: https://issues.apache.org/jira/browse/LIBCLOUD-272
> 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. (http://builtoncement.com/). 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 object
> 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> <local_file>
> $ 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>
> <local_file>
> $ 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
> * setup.py was modified to install the cloud_storage command
--
This message was sent by Atlassian JIRA
(v6.1#6144)
