• ActiveResource Behavior
• Actively maintained ( and will be due to SLMS support )
• Tightly developed with guys from studio team
• Well documented with yard
• Good test coverage

I think then a lot of glory words is better to show example. It is example based on example from documentation.
Example goal is simple. Create new appliance in studio, add own cool rpm and build appliance with it. It can be useful to test your new version of software in stable environment and have automatic appliance in which you can test it.

  require 'rubygems'
  require 'studio_api'

  # Fill up Studio credentials (user name, API key, API URL)
  # See https://susestudio.com/user/show_api_key if you are using SUSE Studio online
  connection = StudioApi::Connection.new('user', 'pwd', 'https://susestudio.com/api/v1/user')
  # Setup the connection for all ActiveResource based class
  StudioApi::Util.configure_studio_connection connection

  # Find template with KDE4 for SLE11SP1
  templates = StudioApi::TemplateSet.find(:all).find {|s| s.name == "default" }.template
  template = templates.find { |t| t.name == "SLED 11 SP1, KDE 4 desktop" }
  # clone template to new appliance
  appliance = StudioApi::Appliance.clone template.appliance_id, :name => "New cool appliance", :arch => "i686"
  puts "Created appliance #{appliance.inspect}"

  #add own rpm built agains SLED11_SP1
  File.open("/home/jreidinger/rpms/cool_rpm-1.0-1.60.noarch.rpm","r") do |f|
    StudioApi::Rpm.upload f, "SLED11_SP1"
  end
  # and choose it in appliance ( and of course add repository with own rpms)
  appliance.add_user_repository
  appliance.add_package "cool_rpm", :version => "1.0-1.60"
  #check if appliance is OK, like dependency problems with new rpm
  if appliance.status.state != "ok"
    raise "appliance is not OK - #{appliance.status.issues.inspect}"
  end
  
  build = StudioApi::RunningBuild.new(:appliance_id => appliance.id, :image_type => "xen")
  build.save
  build.reload
  while build.state != "finished"
    puts "building (#{build.state}) - #{build.percent}%"
    sleep 5
    build.reload
  end

  final_build = StudioApi::Build.find build.id
  puts "Appliance to download: #{final_build.download_url}"

So I hope that you like interface how I design it. Of course I welcome any suggestion how to improve it. You can use comments here, novell bugzilla or issues on github.
How to install it:

• In opensuse: 1-click for 11.3 and 1-click for factory
• alternative possible everywhere is to use
  gem install studio_api

At the end few useful links if you are interested:
repository on github
yard documentation
gem at rubygems.org

Thanks for attention and I welcome any comments

Virtualization is a concept similar to the Matryoshka analogy. There is another system running inside the host machine. So it is box in a box. There are many virtualization techniques available at the disposal of the user; vmware, virtualbox, xen to name a few which requires lots of resources. Another alternative which is OpenVZ , container-based virtualization for Linux. Each container performs and executes exactly like a stand-alone server; a container can be rebooted independently and have root access, users, IP addresses, memory, processes, files, applications, system libraries and configuration files.

Here is a quote from TechRepublic Blog :

In the past we have looked at using OpenVZ for container virtualization on Linux. OpenVZ is great as it allows you to run compartmentalized “servers” within an operating system so you can separate systems, much like running virtual machines on a host system. With OpenVZ, you can get the benefits of virtualization without the overhead.

The downside of OpenVZ is that it isn’t in the mainline kernel. This means you need to run a kernel provided by the OpenVZ project. By itself this isn’t necessarily a problem, unless you are running an unsupported Linux distribution, and also if you don’t mind a bit of lag from upstream security fixes

So what is an alternative; well maybe lxc is the answer.According to http://lxc.sourceforge.net/

The  container  technology  is actively being pushed into the mainstream linux kernel. It provides the resource management through the control groups aka process containers and resource isolation through the namespaces.

There is very little information regarding LXC in the opensuse wiki and the only one available is still draft, yet provides enough information to start rolling up your containers.  Here is the preamble of the above mentioned page:

LXC is a form of paravirtualization. Being a sort of super duper chroot jail, it is limited to running linux binaries, but offers essentially native perfomance as if those binaries were running as normal processes right in the host kernel. Which in fact, they are.

LXC is interesting primarily in that:

• It can be used to run a mere application, service, or a full operating system.
• It offers essentially native performance. A binary running as an LXC guest is actually running as a normal process directly in the host os kernel just like any other process. In particular this means that cpu and i/o scheduling are a lot more fair and tunable, and you get native disk i/o performance which you can not have with real virtualization (even Xen, even in paravirt mode) This means you can containerize disk i/o heavy database apps. It also means that you can only run binaries that the host kernel can execute. (ie: you can run Linux binaries, not another OS like Solaris or Windows)

The same page also states there is not another HOWTO or documentation explaining how to use lxc with opensuse even though the lxc package has been part of the main oss repo since 11.2 version. Furthermore there are no scripts like lxc-fedora or lxc-debian  that will automate the creation or installation of opensuse. Now while it may be true that there are no opensuse specific scripts are available (at least I could not find through a Google search), though there is an interesting video on youtube showing the lxc with opensuse 11.2.

Based on the the information on the LXC wiki page, using the  SUSEStudio , I built an appliance which  is almost ready to use lxc. In order to create a container image, a very primitive lxc_opensuse script that will do a fairly basic job is also included. Once the script is issued,it will download opensuse 11.3 base system and the user can start playing with the wonders of lxc. For the impatient, who wants do discover Matryoshka, here is the link for  the appliance .

Have fun with Matryoshka !

I have 2 Intel Atom’s running for my mail and web servers and I was quite happy with their performances, (by the way I am still happy). Hence I decided to ride the change train and bought the Intel D510 board

opensuse 11.3 Kde LiveCd worked fine and using Susestudio I designed my image. So far was really good. Booting the usb brought my feet back to earth. A frozen screen. So I tried the failsafe option and I had a 800X600 display. Reboot and this time trying “nomodeset” option same thing. Nevertheless I decided to give it a go ( I can always use it at run level 3).

Last night I have decided to include the Kernel:HEAD repo so I am using kernel-default-2.6.36-rc6.25.1.x86_64 along with the X11:XOrg repos using X.Org 1.9.0.901 (1.9.1 RC 1) so now I have “1366×768 (the max my monitor can give) and I do not need to set “nomodeset” in the boot options anymore.

I have not tweaked everything yet, like my Logitech keyboard’s multimedia keys are useless in KDE at the moment.  At the end they will work one way or the other, I am sure.

Lesson Learned: do your homework well before jumping the change train or enjoy the adventures