Command line client for Suse Studio Abstract
Ratan
Short description: Appliances built with Suse Studio can be thought of as any other software project that has to be built, tested and deployed. Currently appliances have to be built using the web-interface, which while being full-featured might be a little clunky if extensive configuration, through multiple overlay files and packages, is required. The goal of this project is to create a command line tool(ssc) to make it easy for users to create appliances locally and deploy them.
Background:
There is an existing command line client for Suse Studio (http://www.gitorious.org/suse-studio/ssc) that is quite outdated and uses a few unsupported libraries. The proposed client will be written from scratch, since the functionality proposed here differs sufficiently from the old client and I will be incorporating the well-supported suse_studio gem for making API calls.
Benefits:
Users creating appliances that require extensive configuration will find the client useful. It could be used to automate the building of appliances based on a smaller set of options for much more specific customisation.
Another potential use that can be explored is to share useful complex configurations making it possible for other users with similar but not identical requirements to reuse each other's configuration.
Technical Details:
The client will be written in Ruby and packaged as a gem. It will use the studio_api gem to handle API requests.
The command line client has two utilities:
- To create and configure a local version of the appliance and commit the changes when done.
- To simply retrieve information from the API (listing templates, repositories, packages, etc.)
The following main "objects" can be managed using the client:
- appliance (create, list, status*)
- repository (search, list*, add*, remove*)
- package (search, list*, add*, remove*)
- file (list*, add*, remove*, diff*, update*)
* - These commands require the appliance ID. Either they can be run within the local application directory (created with `application create`) or they will need the --appliance-id option. This facility is so that in case only some minor changes require to be made to an appliance ( the addition of a prepared config file for instance ), it can be done without the hassle of having to setup a local appliance directory. In case the commands are run from outside the appliance directory, the changes will be effected immediately, otherwise, the changes will be recorded locally and will be updated remotely when the commit command is run.
The following commands help to work within an appliance directory:
- commit [files|packages|repositories|all] (additional options would allow users to cherry pick certain local modifications while comitting)
- checkout : update the local files and update the local record of packages and repositories from the server
- status : show changes in packages/files/repos waiting for commit
Besides those main objects, the client will also allow users to inspect builds, list templates, etc.
Use Cases:
Since the use cases are varied and quite numerous, I've included only a very simple one here to illustrate the typical workflow.
Creating an appliance with a single custom configuration file:
$ ssc appliance create new_appliance
$ cd new_appliance
$ ssc file add /local/path/to/config_file
... some other modifications later
$ ssc status
$ ssc commit
Roadmap:
- April 25th - May 23rd: Familiarize myself with the studio_api gem, make and investigate the best option to maintain versions of local changes.
Coding will be done in 2 week periods at the end of each of which some new functionality must be added to the tool and be made available for community testing.
- May 24th - Jun 5th: Create the framework for the command line client. Get the option parsing working and implement some of the basic search functionality.
- Jun 6th - Jun 19th: Implement the appliance directory management features.
- Jun 20th - 26th: Release a first alpha version for testing and reviews
- Jun 27th - Jul 11th: Tidy up, refactor code. Raise test coverage. Fix Bugs.
- Jul 12th - Jul 17th: Mid-Term Review
- Jul 17th - Jul 31st: Implement the commit, update and status commands.
- Aug 1st - Aug 15th: More testing, bug fixing and community review.
- Prepare the first stable release
Why Me:
I'm a student at the Indian Institute of Technology, Kharagpur. I've been working with ruby for the last 4 years. I've completed 2 internships as a ruby/rails developer at Sapna Solutions and slideshare.com and have done some freelance work using rails. You can see some of my open sourced code at http://github.com/rjsvaljean. Among other things, I've built a del.icio.us API wrapper [http://rubygems.org/gems/rubycious] and a custom blogging engine rxvl [http://github.com/rjsvaljean/rxvl].
I have considerable experience working with ruby and web APIs and am confident that I can write a well designed, intuitive and maintainable client for Suse Studio. Suse Studio is an important tool to create replicable custom installations for mass deployment and this tool will make it much easier for developers to adopt it.
