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

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