An Orca container is an instance of Orca that runs within a single Java Virtual Machine (JVM). This guide describes the basic components of a container and the configuration files and state they require.
|Configuration Files||Lists Orca's configuration files|
|Configuring Actors||Actor XML configuration file reference|
|Configuration tools||Configuration tools for containers and inventory.|
|Emulation||Execution under emulation|
|Real Mode||Execution with real resources|
|Orca and Eucalyptus||Using Orca with Eucalyptus|
An Orca container consists of the following components:
Each Orca container requires access to a database server, so that it can store information about the actors inside the container and the resources that they control. Please refer to this page for more information about creating and populating an Orca database.
Several files specify the behavior and settings of an Orca container. Please refer to this page for information about the various container configuration files.
An actor is the source of activity within an Orca container. There are multiple ways to create an actor:
Please refer to this page for information about creating actors using a configuration file.
The admin user is the initial owner of all container resources and it would delegate them to the respective site providers as needed.
When running a site provider inside an Orca container, the container needs to be configured with an inventory of resources that the provider is going to distribute.
Orca ships with a number of sample configuration files to get you started.
The first decision you must make before running an Orca container is whether you want to run under emulation or you would like to execute with real resources. This choice determines the amount of configuration and preparation that you will need to perform before you can instantiate the Orca container.
Execution under emulation exercises all Orca components with the exception that the system does not try to contact the inventory resources and does not use real resources to back the leases that it processes. This mode of execution is ideal for testing and experimentation when the fact that real resources are not used to satisfy a request is not important. When running under this mode, you still need to register some inventory into the database, but you do not need to configure the inventory. Please refer to this page for more information about emulation.
Under real execution, the system contacts the real inventory resources and uses real resources to back each lease that it issues. This process requires that the inventory used by the container is:
Please refer to this page for more information about execution with real resources.