The Profile Library is where administrators and users can store, view, audit, and
compare operating system profiles.
Note: You need to know about profile libraries if you are a project administrator or a TeamForge
Lab Management user who is closely involved with
the selection and maintenance of operating system profiles for their projects. For most
developers and QA personnel, ask your project administrators which profiles and versions to use.
Every system inside the TeamForge
Lab Management environment has an operating system
profile installed on it. Like source code in a version control system, these profiles are
versioned, and users can re-image systems on any operating system version in the Profile Library.
Similarly, project and domain administrators can enforce, at a per-project or per-domain level,
the ability to enforce the use or restrict certain operating system profiles. This gives users
and administrators great power and flexibility in deciding which systems to support and run.
The Profile Library implements TeamForge
Lab Management's concepts of "profiles"
in the context of a distributed software development environment encompassing multiple projects
and users. These users and projects sometimes want to share things with each other, and sometimes
they want to keep things private. They also need ways to make intelligent decisions about what
profiles to use, how profiles differ from one another, and understand how individual profiles
have evolved over time. The Profile Library enables TeamForge
Lab Management users to do all these things and
more.
- A "profile," as defined in TeamForge
Lab Management, is a reproducible collection of
software packages that comprise a runnable operating system and accompanying set of
applications. For example, a profile could be a base install of the Linux operating system with
nothing more than a kernel, a shell, and some basic utilities. Or, a profile could be a complete
installation of Linux including a windowing system, a database server, a J2EE application
server, and a web server.
- What we call a "profile" really consists of two distinct parts:
- A textual description of what the profile contains, and instructions on how to assemble
those contents. For example, details on how to partition the disk and what binary packages to
install.
- The binary contents themselves, either a set of OS packages (e.g., RPM files or Solaris
packages) or a pre-built system image file (e.g., a VMWare image file or a Solaris flar
archive).
- Profiles belong to a project, or to the entire domain. The project administrators (the Domain
Admins, in the case of domain profiles) can control the properties and availability of their
profiles to all projects on the site.
- By default, new projects cannot build systems with any profile: project admins must assign
"allowed profiles" to their projects. The "allowed profiles" can be changed
at any time by the project admin and control what operating systems and versions members of that
project can build.
- Profiles can either be public or private. Public profiles can be used by
any other project in the domain. Private profiles can only be used by the project that
owns the profile. A profile that is owned by the domain, which is marked Private, is effectively
unusable by all projects in the entire domain.
- Making a profile/version unavailable does not immediately affect existing hosts built with
that profile; however, the owner of that host will not be able to rebuild that host with that
same profile/version.