OSCAR-6.0 is out!

This version provides the latest modifications which will ease future developments. On the roadmap, we already plan to include many project on which students worked during the summer 2008, including a benchmarking framework, a monitoring framework, and mechanisms to deal with specific NFS configuration. This version will also be a good base for bug fixes.

Remember that this version does not provide yet all the capabilities OSCAR were used to provide. For this version, we focused on the implementation of a stable OSCAR core and cleaning up; which should allow us to move forward.

Right now, OSCAR-6.x supports only RHEL/CentOS 5 for both x86 and x86_64 in a production environment. The support of Debian systems is still experimental since we found a critical bug in opkgc (which should be fixed shortly).

OSCAR-6.0 is available via our YUM/APT on-line repositories. For more details about how to use those repositories, please refer to http://svn.oscar.openclustergroup.org/trac/oscar/wiki/repoTesting. The next version of OSCAR-6.x will be available via the same repositories, providing an easy way to update OSCAR.

Since the latest update of the INRIA forge, where the OSCARonDebian website was hosted, it is not possible to maintain the website in good conditions. Therefore we migrated the OSCARonDebian website on the OSCAR wiki: OSCARonDebian.

We did not migrate all the pages yet but the most important pages have been migrated.

OSCAR 5.2 becomes OSCAR 6.0 and a beta version is now available!

Fist of all, let's explain why we decided to call the next release 6.0 instead of 5.2. It is actually very simple: the way OSCAR is initialized changed and the different commands users are supposed to use also changed. Therefore, there is no good compatibility between OSCAR-5.1 and the new release. Because of this lack of compabilities, we decided to version this release 6.0 instead of 5.2.

Now, what about the beta version? Again it is pretty simple: we were able to deploy a production CentOS-5 x86_64 cluster using this version, we do not expect to find any major bug with that version so we plan to release it as soon as possible. The deployment has been made using OSCAR core of course, plus Ganglia (other OPKGs have not been "ported" yet). This means that the OSCAR-6.0 version is not necessarily suitable for production. OSCAR-6.0 is actually very similar to KDE-4.0: this version is not necessarily "designed" for the users who need all the capabilities traditionally shipped with OSCAR, but this is a good new framework to include and develop new capabilities and move forward.

Finally, just few words about the Debian support: we found a critical bug in OPKGC on Debian therefore we will not be able to officially support Debian in OSCAR-6.0. However, users should be able to deploy a cluster based on OSCAR core.

To test this version (it officially supports only CentOS-5 both x86 and x86_64), please use our online repositories, more information is available here: http://svn.oscar.openclustergroup.org/trac/oscar/wiki/repoTesting

If no bugs are reported within the next two weeks, we will release OSCAR-6.0 on January, 5th.

We have a good news this month: an new alpha version of OSCAR-5.2, the second one, is available (note that this is still a snapshot of trunk). This version supports both Debian based systems (i.e., Debian 4.0, ubuntu-7.10, and ubuntu 8.04) and RPM based system (i.e., CentOS-5 i386, CentOS-5 x86_64, RHEL-5 i386, and RHEL-5 x86_64)!

From now, we just need to test this version to be able to release OSCAR-5.2. Also note that this version only includes OSCAR core, OSCAR packages will be included later, following users' needs.

To test this version, report to the following link http://svn.oscar.openclustergroup.org/trac/oscar/wiki/repoTesting. We need help for testing, in order to validate the new version based on different configurations (both hardware and software). If you want to help us, just send your bug report on the oscar-devel mailing list (you do not even need to try to debug OSCAR, just send the raw logs).

We organize this year again a Birds-of-Feather (BoF) at SuperComputing 2008. Please join us if you plan to attend SuperComputing. We will do some announcements during the BoF. :-)

More details here: http://scyourway.nacse.org/conference/view/bof125

We have a good news this month: an alpha version of OSCAR-5.2 (in fact the SVN trunk) is available for Debian based systems (i.e., Debian 4.0, ubuntu-7.10, and ubuntu 8.04)!

The major modifications for OSCAR-5.2 are:

• support of online repositories (no need to create local repositories if your cluster headnode has access to internet),
• the apparition of a new OSCAR component: the OSCAR Repository Manager (ORM), which provides an abstraction for the management of OSCAR repositories.
• separation of OSCAR components that led to many bug fixes and enhancements (better documentation, more tests and so on).

Note that since we separate now the different OSCAR components, the current alpha version is only based on the OSCAR core (minimum to deploy a cluster, no extra OSCAR packages).

If you want to test this version, please refer to the following webpage: https://svn.oscar.openclustergroup.org/trac/oscar/wiki/trunkTesting

If you encounter any problem, please send your bug reports to the oscar-devel mailing list.

We will prepare beta binary package for OSCAR as soon as few modifications will be finalized to support RPM based systems (some work needs to be done on Yume in order to make it compliant with the new PackMan? extension).

Stay tuned!

This month i would like to point at the latest developments on the OSCAR core:

• OSCAR Repository Manager, a.k.a. ORM, has appeared. ORM is a simple abstraction on top of PackMan? that allows one to easily deal with a given Linux distribution: when creating a new ORM object, one can specify the Linux distribution the object is associated with, and then ORM knows which OSCAR repositories must be used, how to bootstrap an image, and how to manage binary packages. This abstraction is usefull to simplify some OSCAR related code. For instance, SystemInstaller can now be modified to rely on ORM for image creation, avoiding the current implementation based on several modules, specific to SystemInstaller, and duplicating capabilities already provided by others OSCAR components. For more details about ORM, please refer to perldoc OSCAR::RepositoryManager? after the installation of ORM on your system.
• Audit of the Selector code: thanks to the effort of OSCAR developers, we have now a specification of Selector's capabilities. This audit allowed us to identify implementation limitations and to address those limitations. Thanks to these modifications, Selector is now much faster and is actually based on a clear and well-specified interface with ODA, the OSCAR database (Selector get/set data from/into ODA). For more details, refer to the Selector documentation, which is available with the Selector code, under to doc directory.
• Separation of the code of the different OSCAR core components: the source code of ODA, Selector, and ORM are now separated from the source code of OSCAR trunk. This source code for those components is now in pkgsrc (http://svn.oscar.openclustergroup.org/trac/oscar/browser/pkgsrc). This organization of the source code allows us to have a fine grain management of the different developments: each components can have its own release cycle and dependencies between components can easily be expressed via binary packages dependencies (especially since, nowadays, OSCAR is entirely shipped via binary packages).

We had many summer projects this year:

• NFS Mountpoints in OSCAR, by Paul Greidanus. OSCAR currently does not have an option to allow non-"standard" NFS mount points, this project would be to extend OSCAR's native NFS mount points, to include all mounted NFS servers on the head node, and clone that configuration onto the node image. Also, investigate automounters, and cloning automount configuration as well.
• Implementation and Integration of a Universal Monitoring Framework, by Okoye Chuka. Currently OSCAR can install a cluster, perform managerial tasks such as addition/deletion of nodes and also monitor the status of the cluster with ganglia or nagios. HA-OSCAR, an extension of OSCAR introduces redundancy at the head-node level by duplicating the primary head-node and based on predefined policies carries out specific actions to guarantee availability of this head-node. OSCAR cannot monitor the states of services concurrently running on all compute nodes such as lam , pbs_mom and take predefined actions in the case of failures. I propose the design, implementation and integration of a universal framework that allows gathering and storing information about the health of the various clustering services.
• OSCAR V2M Extension, by Panyong Zhang. In the 2007's soc projects, Kulathep Charoenpornwattana has implemented "Cluster Virtualization with Xen"[1], It support the Xen. As the current Lguest[3] and KVM[4] integrated in Linux kernel and vmware is used widespreadly, it would be very benificial to extend the V2M[2] to support Lguest, KVM and The purpose of this project is to extend the OSCAR V2M, Let it can work with Lguest, KVM.
• XOSCAR - A New Graphical User Interface That Enables Virtualization and System Partitioning, by Robert Barbilon. OSCAR is a software management tool initially developed to support only standard Beowulf cluster. However, Beowulf clusters are not any more the typical configuration for computation, current systems being often disk-less or even composed of virtual machines. To address this issue, the OSCAR-V project has been initiated and aims to provide a unique system management software for all types of configurations (typically disk-full, disk-less, or composed with virtual machines). One of the strong limitations of the current OSCAR-V project is to not provide any Graphical User Interface (GUI), even if an effort has been initiated last year to define the premises of what should be such a GUI (using C++ and Qt4 in order to provide portability to major platforms). Therefore, this project aims to design a new GUI for OSCAR-V that supports both the deployment and management of virtual machines, disk-less & disk-full compute nodes. The design of the GUI will have to fit the underlying OSCAR-V tools used for system management. The GUI also needs to support remote management, allowing one to "drive" the OSCAR-V cluster from its laptop.
• Implementation of a Benchmarking Framework for OSCAR, by Tara McQueen?. Performance evaluation is mandatory for high-performance computing (HPC). The diversity of parallel applications and their target platforms have also increased considerably. This heterogeneity of applications/platforms creates many challenges for performance evaluation to the point where almost all tasks for performance evaluation are still carried out manually, from the configuration of the systems, the execution of the benchmarks, to the generation of final performance reports. Furthermore, system management tools for HPC platforms are also typically lacking benchmarking mechanisms for platform “validation”, i.e., a way to validate the software configuration and therefore the overall performance available for applications. While the benchmarking tools address the challenge of evaluating the performance of a given configuration, system management and monitoring tools address the actual configuration of the benchmarks and monitor their execution. On the benchmarking aspects, only few projects, such as Cbench, address those issues, automating the execution of benchmarks and the generation of final reports. However, only a few benchmarks are included, and those projects are still lacking extensive documentation. Yet, the gap between system management/monitoring and performance evaluation is growing. In this paper, we take a step forward in automating the run-time infrastructure needed by the tasks necessary for performance evaluation, extending Cbench and integrating Cbench into OSCAR, a software suite for the management of HPC clusters.

All these projects were pretty successful and should be integrated into OSCAR pretty soon.

System-level virtualization is today widely used for server consolidation and even if the benefits of system-level virtualization for High Performance Computing is still very unclear, one may argue that a management software such as OSCAR should support virtualization. What is the current support for virtualization in OSCAR? Is it possible to deploy VMWare or Xen virtual machines with OSCAR and to monitor them remotely? A team at ORNL was actually working on that issue and the OSCAR-V project (http://www.csm.ornl.gov/srt/oscarv.html) was initiated. This project is based on a modified version of OSCAR in order to support both the management of the HostOSes (the systems that host the virtual machines) and the virtual machines. Unfortunately, these modifications were very important making their port directly into OSCAR very difficult. To address this issue, we have been working on the extension of OSCAR during the past few months: mainly the support of the concept of cluster's partitions and the implementation of a new GUI which is simpler to extend and maintain. Based on this work, we are close to enable the following scenario: the system administrator defines a partition of the system for the creation of HostOSes, which means that the virtualization solution (for instance Xen or QEMU) is installed on those systems. When the HostOSes are finally deployed by OSCAR, it is then possible to deploy virtual machines: the system administrator creates a virtual partition, defines it (what is the Linux distribution? What software should be installed?), and then can deploy it. The features are still under development and we do not plan to release those before OSCAR-5.4. But the new GUI is under active development and trunk should support soon the definition and the deployment of partition. More details very soon!

First of all, let me introduce myself. I am Geoffroy Vallee, scientist at the Oak Ridge National Laboratory and chairman of the OSCAR project since few weeks. As chairman, i will try to publish a "bulletin", each month, highlyting few interesting points. It can be ongoing developments, current unknown features or even related projects.

This month, i will present a specific point i would like to focus on for the next OSCAR releases: the isolation of a small and simple core, and the separation of the GUI and other OPKGs from the core. The goal, doing so, is to ease the development of new core features: no need any more to test the core with all the OPKGs, core developers can focus on the features they are working on. It should also allow us to develop a "validation" tool: a tool that tests the core features and validates the different APIs. Such a tool should release more often the OSCAR core and also guarantee stability.

What about the non-core OSCAR components? They can simply follow their own development cycle. Doing so, new contributors can help, join the project without to have to "play" with the OSCAR core. I think a key idea is to separate the different tasks and make contributions more efficient shorting the release cycle.

In fact, this has been discussed since a long time, even before i joined the project. Nothing new. But i think, based on the current status of the project, that it is the good time to implement it. Lately, few developments have been done in that direction, the two in top of my mind are: - we started the effort for the separation of the GUI code from the core Perl modules (Bug #416, #462), - Wesley Bland is currently working on a modification of Configurator in order to be able to use it both with the CLI and the GUI (Bug #459).

Before to be able to really implement the separation of the core from other OSCAR components, few current tasks need to be completed. The three major ongoing tasks are: (i) the release of OSCAR-5.1 (hopefully all critical bugs have been fixed), (ii) the creation of on-line repositories to host binary packages (binary packages currently overload our SVN server, slowing down all new developments), and (iii) the merge of branch-5-1 (the branch used for the release of OSCAR-5.1) and trunk (used for developments).

As you can see, we have a lot of exciting plans with the plan to continue to improve OSCAR and the OSCAR user experience.

Meeting at ORNL (Mar 12-14, 2008)

Attendees:

• DongInn Kim (IU)
• Geoffroy Vallee (ORNL)
• Thomas Naughton (ORNL)

Meeting notes are available, including a roadmap draft.

Hi, OSCAR trac website has now a blog.