Hi,
I'd like to work on the improvement of the Suse Studio command line client(ssc) idea for GSOC this year. I've gone through the current ssc code but found no documentation on it. Is there someone here I can talk to who has worked on it and would know what is lacking. It would help me formulate a detailed project proposal.
As I see it I'd first write a wrapper for the suse studio api(http://susestudio.com/help/api/v1) and a command like client to use the wrapper. It would be a good idea to separate the two so that the wrapper can be used programatically as well.
Let me know what you think.
Thanks.
-- Ratan Sebastian
On Tuesday 22 March 2011 14:19:27 Ratan Sebastian wrote:
I'd like to work on the improvement of the Suse Studio command line client(ssc) idea for GSOC this year. I've gone through the current ssc code but found no documentation on it. Is there someone here I can talk to who has worked on it and would know what is lacking. It would help me formulate a detailed project proposal.
You can find more information here: http://en.opensuse.org/openSUSE:SUSE_Studio_command_line_client
You can also join us on IRC in the #susestudio channel, or use the mailing list studio-users@suse.de to reach the team and the community.
As I see it I'd first write a wrapper for the suse studio api(http://susestudio.com/help/api/v1) and a command like client to use the wrapper. It would be a good idea to separate the two so that the wrapper can be used programatically as well.
There already is a library to access the Studio API at https://github.com/jreidinger/studio_api.
Here's some of the commands the client would have. I had a look at osc and the Studio API in coming up with this. Let me know what you think.
Templates: template list
Appliances: appliance list appliance status <id> appliance create [--clone_from=appliance_name --arch=x86_64/i686] [name] # Creates a local directory with a manifest that stores apppliance id and other changes that have been made locally and not committed appliance delete <id>
Repositories: repository list <search_string> --base-system= repository add <name> <url> repository remove <id>
Packages(Software): package list # lists all repositories in the current appliance with the appliance ID from the manifest file. package add <name> --version --repository-id package remove <name> package search <search string> --all-fields --all-repos
Files: file list file add [local_path|url] [remote_path] --owner=user --group=user --permissions=-rwxr-xr-x # copies the file to the appliance directory for future edits and for comparing against the file on the server file diff [path] file update [path] # update the local file with corresponding file on the server file remove [path]
Builds: build list [running|finished] build status <id> build start build cancel <id> build delete <id>
General Commands:
commit [files|packages|repositories|all] [--cherry-pick] # The cherry pick option gives you more control over what changes you're pushing to server. checkout # update the local files packages and repository from the server status # show changes in packages/files/repos waiting for commit
All PUT, POST and DELETE requests are not done until the commit command is run. I think the existing client has to be mostly rewritten. Some of the required gems are not actively maintained and don't work under Ruby 1.9(xml-smart). We can use thor to handle the command line option parsing. And the studio_api gem to handle the requests.
On Tue, Mar 22, 2011 at 10:56 PM, Cornelius Schumacher cschum@suse.de wrote:
On Tuesday 22 March 2011 14:19:27 Ratan Sebastian wrote:
I'd like to work on the improvement of the Suse Studio command line client(ssc) idea for GSOC this year. I've gone through the current ssc code but found no documentation on it. Is there someone here I can talk to who has worked on it and would know what is lacking. It would help me formulate a detailed project proposal.
You can find more information here: http://en.opensuse.org/openSUSE:SUSE_Studio_command_line_client
You can also join us on IRC in the #susestudio channel, or use the mailing list studio-users@suse.de to reach the team and the community.
As I see it I'd first write a wrapper for the suse studio api(http://susestudio.com/help/api/v1) and a command like client to use the wrapper. It would be a good idea to separate the two so that the wrapper can be used programatically as well.
There already is a library to access the Studio API at https://github.com/jreidinger/studio_api.
-- Cornelius Schumacher cschum@suse.de -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 24 March 2011 06:52:12 Ratan Sebastian wrote:
Here's some of the commands the client would have. I had a look at osc and the Studio API in coming up with this. Let me know what you think.
That's a good start. One general problem we have to solve is how to make it clear, which commands work in which context. The list you made includes commands which work locally, like the files commands, and commands which work remotely like the templates or appliances commands, and to make things more complicated there are commands which need both, like the diffs.
Additionally it makes a difference, if you call the client within an appliance or outside of an appliance. All this could be very confusing. I think we need a consistent scheme how to deal with that, so it's clear which commands apply to what, if you see and change things locally or remotely, and which appliance is the context.
One option could be to separate command line tools, and have one for working inside an appliance and another one for working independent of a local appliance. But this could also be reflected in the structure of the commands. Ideas and good concepts are welcome.
Thanks for the feedback. I've put my thoughts inline.
On Thu, Mar 24, 2011 at 1:53 PM, Cornelius Schumacher cschum@suse.de wrote:
On Thursday 24 March 2011 06:52:12 Ratan Sebastian wrote:
Here's some of the commands the client would have. I had a look at osc and the Studio API in coming up with this. Let me know what you think.
That's a good start. One general problem we have to solve is how to make it clear, which commands work in which context. The list you made includes commands which work locally, like the files commands, and commands which work remotely like the templates or appliances commands, and to make things more complicated there are commands which need both, like the diffs.
The way I thought it might work is that only commands involving GET requests perform the action immediately(searches, listing, diffs) . Anything involving a PUT, POST or DELETE (adding or deleting repositories, packages) will be stored locally and the actions aren't performed until the `ssc commit` command is run. (This could be made flexible with some sort of --perform-now flag appendable to all those commandswhich runs the commit for that particular change). So basically any action that requires information from the API will require you to be connected whereas any changes that you make can be done locally. I think that's a intuitive scheme.
Additionally it makes a difference, if you call the client within an appliance or outside of an appliance. All this could be very confusing. I think we need a consistent scheme how to deal with that, so it's clear which commands apply to what, if you see and change things locally or remotely, and which appliance is the context.
One option could be to separate command line tools, and have one for working inside an appliance and another one for working independent of a local appliance. But this could also be reflected in the structure of the commands. Ideas and good concepts are welcome.
Maybe we could move all the commands that require you to be in the appliance directory into an appliance namespace (i.e. ssc appliance respository add) and generic commands can be used outside like(ssc repository search). Another option is to keep the commands as is. In this case it would load the values of the different parameters as required from the manifest file or from the options and errors out if any parameter is unspecified.
-- Cornelius Schumacher cschum@suse.de
Hi all,
This is a first draft of my GSOC proposal. Please let me know what you think. Any suggestions or requests for clarification are most welcome.
Title: Command line client for Suse Studio
Abstract:
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.
Detailed Description:
The command line client has two utilities:
1. Create and configure a local version of the appliance and commit the changes when done. 2. To simply retrieve information from the API (listing templates, repositories, packages, etc.)
The following main "objects" can be managed using the client:
1. appliance (create, list, status*) 2. repository (search, list*, add*, remove*) 3. package (search, list*, add*, remove*) 4. 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, else, the changes will be recorded locally and will be pushed to Studio when the commit command is run
The following commands help to work within an appliance directory:
1. 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.
Roadmap:
April 25th - May 23rd: Familiarize myself with the studio_api gem 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
About 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 that this tool will make it much easier for developers to adopt it.
Contact Information:
IRC nick: rjsvaljean e-mail: ratanjagan@gmail.com http://rjsvaljean.com
-
Cornelius Schumacher -
Ratan Sebastian