Overview of the Compiere Application Dictionary and its Components

The original article was created by Andries L Pretorius on June 2010 at Open Source.

In this article on advanced aspects of Compiere by Andries L Pretorius, author of Compiere 3 Implementation Guide, we will cover:

• Overview of the Compiere Application Dictionary and its components


• Adding a custom field in Compiere


• Setting up a basic document process approval workflow in Compiere

The Compiere Application Dictionary (AD)

The Application Dictionary makes Compiere a truly unique and flexible business framework. Compiere was originally designed from the ground up on a model driven architecture (MDA), as defined by the Object Management Group (OMG). The system design conforms to an open standard in its layered architecture between business, application, and platform logic. MDA separates the business logic modeling, from technology modeling so as to ensure that both can evolve within their own domains, but still keeping within a framework of an open standard (and platform independent) that interconnects the two.

The benefit in the Compiere environment is that through modeling, design, and build the actual deployment time is greatly reduced. The AD also ensures a seamless upgrade of the platform while having little impact on the environment-specific business objects and processes.

The Application Dictionary of Compiere is meta data driven, meaning that contextual data defines the experience. This also means that the end user presentation layer and thus, the Graphical User Interface (GUI) platform have been defined in different technologies (i.e. Java Swing, HTML, and Ajax) and offers endless possibilities.

The Application Dictionaries can be illustrated as shown in:

[singlepic id=267 w=320 h=240 float=center]

To access the Application Dictionary you need to log in as a System Administrator and refer to the sub menu shown in:

We will use the Java Swing (Compiere Standard Edition) user interface for illustration purposes in this section.

[singlepic id=268 w=320 h=240 float=center]

Table and columns

This refers to the fundamental building blocks of the system, and links Compiere data to the underlying Table and Column structures in the database. Illustrated below is the Period table in the AD that links to the underlying table name of C_Period, which you will find in the database:

[singlepic id=269 w=320 h=240 float=center]

If the underlying database already contains the required fields, then by pressing the Create Columns from DB button and having the correct DB Table Name, Compiere will create the columns from the database in the AD.

Within a table, a key column must be created for use as the table identifier:

[singlepic id=270 w=320 h=240 float=center]

Illustrated the key column C_Period_ID. A column links to a System Element, as explained below, and is linked to the underlying table through the Synchronize Column button. In effect, synchronization creates or updates a column to the underlying database.

[singlepic id=271 w=320 h=240 float=center]

System elements

System elements are the common data elements and are used for central terminology references. These system elements link the underlying database columns to business-speak, for instance, in the screenshot in Image 5, C_Period_ID would be translated into the actual period.

[singlepic id=272 w=320 h=240 float=center]

System elements are also used for setting up translations, as well as help comments on column fields.

Validation rules

Field validation rules that are defined in the context of a column field are dynamically verified based on the predefined rules or user context, at time of rendering the data. For instance, when a Business Partner field is displayed for selecting, the Business Partner account must be active and not be a Summary Account as shown in Image 6.

[singlepic id=273 w=320 h=240 float=center]

Based on the example shown in Image 6, a dynamic validation will be set up for the C_BPartner_ID column field (the Business Partner table key identifier) on the Order table, shown in Image 7.

[singlepic id=274 w=320 h=240 float=center]

Reference

A Reference refers to database column field types that are either Data Types (i.e. an Amount, Integer, Date, Time, image, hyperlink, etc.) or a List validation (i.e. user pre-defined dropdowns) or Table validation (i.e. drop-downs for table key columns). An example of a Data Type column would be a period start date. The Column field StartDate in the Period table in the database is defined as reference Date

[singlepic id=275 w=320 h=240 float=center]

An example of a list validation on a Period Control Action (the actions that you can perform on a period) set-up is as shown in Image 9.

The list defined through a Search Key and a Name.

[singlepic id=276 w=320 h=240 float=center]

Search keys are saved in the database.

Table Validations are data-defined based on existing referenced key columns and SQL selection. An example of a table reference would be a Document type based on a table validation SQL query. Herewith, a Document type (C_DocType) is defined, but it refers to the appropriate Tenant/client so as to ensure that only the document types for a Tenant are displayed, shown in Image 11.

[singlepic id=277 w=320 h=240 float=center]

Windows, Tabs, and Fields

Compiere generates all of its windows in a standard dynamic way by reference to the defined AD. This AD window thus relates to setting up the Windows, and the Tabs(sub-linked windows) and Fields that are displayed on those Windows. Illustrated here is an example of the Calendar and Period window that defines the structure of the periods within Compiere.

[singlepic id=278 w=320 h=240 float=center]

Windows may be of the following Window Types:

1. Maintain: Usually used in the context of master data, such as Business Partner or Products.


2. Query Only: A window type that is used for displaying results in a grid, and is not editable.


3. Transaction: A window type used for transaction processing , such as an order or an invoice.

The Window Tabs refer to the sub-linked windows of the main window header, or the preceding tab. In the example below, the Calendar window is built by defining the Calendar, applicable Year, Period and Period control, and Non Business Day.

[singlepic id=279 w=320 h=240 float=center]

The window's Fields are populated from the Table and Columns associated with the window.

[singlepic id=280 w=320 h=240 float=center]

Forms

Forms are windows that are not automatically generated through the AD but are static and are usually for custom purposes, based on specific Java code classes.Below is a Form that defines the File Import Loader process.

[singlepic id=281 w=320 h=240 float=center]

Once a Form has been defined, it is linked to the Java classes through the Classname(Swing) and Java Classname for Web UI fields. These classes will contain the source code to build these custom Forms.

Info windows

These are windows that are used for quick searches and information views. Here, is the Info window for viewing invoices. It is defined through an SQL query on a table and then defining the columns within the Info Window.

[singlepic id=282 w=320 h=240 float=center]

Report Views

Where database views may exist within the underlying database, the AD requires the Database views to be defined in the system in order to be accessible. Here, is an example of the Invoice database view for a week:

[singlepic id=283 w=320 h=240 float=center]

To distinguish them from normal tables, Compiere uses the RV_ prefix convention to name a Report View within the underlying database.

Reports and processes

These are used to set up reports (link to a Report view) or a process that can link to a Java code class. Reports and processes may have parameters that define a selection process. Examples of a report would be an invoice enquiry, and an example of a process would be to generate invoices from orders.Here is the actual Report that defines the Invoices per week report.

[singlepic id=284 w=320 h=240 float=center]

Reports may have access restrictions and selection parameters.

If a report is also displayed as a Dashboard (Compiere Enterprise version 3.5 onwards) then an underlying dashboard widget needs to be defined. An example of the Invoice Generate Process, that links to the underlying Java class:

[singlepic id=285 w=320 h=240 float=center]

In windows, Buttons may be linked to processes (i.e. C_Invoice Copy From which copies lines from other invoices on the Invoice windows) and Processes need not all be manually run as such. Processes can be defined as server processes, and can also be scheduled through the Compiere scheduler.

Adding a Custom Field in Compiere 3

The user menu is your default tree, and is accessed through the System Administrator role. You can find the Menu item in the screen tree:

[singlepic id=286 w=320 h=240 float=center]

The above screenshot illustrates a typical window set-up, which is done as follows:

1. Create a new menu item by clicking on the New button. Enter a name and a description.


2. Define its action type: A menu item's action type can be a Window, Form,Process, Report, Task, or Workflow. Link an AD item to the menu, which is illustrated above, where window Sales Order is linked to the Sales Order menu item.


3. Move the menu item in context of the main menu tree for users understanding and access.

It is recommended that you define your own windows, or copy from the existing dictionary, for customizations. Because dictionary (system) defined items may be overwritten during the process of migrating to a new version, it is better to copy a window and customize it in the copied window (or create new). This applies to Java code as well: never change the original source as it may be overwritten during migration.

Adding a new field to a window and database

In this section we are going to illustrate how the System Administrator would go about adding a new field to the database. As an illustration, we are going to add a probability reference field that can be used to measure a predefined set of outcomes on an order to the Sales Order window.

1. Find the context by Zooming to the Table from the Window. Open and find the Sales Order window in the Window, Tab, and Field menu item when logged in as System Administrator:



[singlepic id=287 w=320 h=240 float=center]



2. Zoom from the window into the underlying Table and Column window.Order records are maintained in the database in the C_Order table:



[singlepic id=288 w=320 h=240 float=center]






3. Next we refer the Column tab, and create a new column in the table(see the field naming conventions below). The new column must be as a System Element defined and hence we need to create a System Element prior to using it as a Column in the Table:



[singlepic id=289 w=320 h=240 float=center]



4. Once the System Element has been defined, we set up the Column as follows:



[singlepic id=290 w=320 h=240 float=center]



5. Create a new Reference key as follows:



[singlepic id=290 w=320 h=240 float=center]




Because this is a custom list, we choose a validation type of List Validation, and a value format of L, indicating that any letters are allowed. For a full list of these conventions, refer to the help documentation in the system by pressing F1.



6. We then define the Reference key's list validation options as follows:



[singlepic id=291 w=320 h=240 float=center]



7. The finalized column (and thus the ultimate window field) set-up is thus shown as follows:

[singlepic id=292 w=320 h=240 float=center]

We finalize the set-up of the field by indicating:

1. Field naming conventions: Compiere recommends that customer-specific table and database column names be prefixed by EXT_, XX_, or CUST_, or the four letter entity registered with Compiere, such as SAAC_. This would also apply to indexes and constraints. The reason for this is that these entities are ignored in the migration process.


2. Length of field: Because we know that for this particular field there is going to be only one character we define a length of 1.


3. Default logic: We assume U, based on our list being Unknown.


4. Mandatory UI: Indicates that this field will be mandatory in the window, but not at database level.


5. Updatable: Indicates that the field is editable.


6. Always Updatable: Indicates that the field is always updatable, regardless of document status.

Final step in column creation—Create / Synchronize with the database

The final step in the process of creating a field is to make sure that it is synchronized to the underlying database from the AD. Scroll down on the column tab to find the Synchronize Column button, as shown in the example below:

[singlepic id=293 w=320 h=240 float=center]

Adding our custom field to the Order window

Back in the menu item Window, Tab, and Field (find the Sales Order window) > Tab (header/top level):

1. Click on the Create Fields button to add the field to the database:



[singlepic id=294 w=320 h=240 float=center]



2. Change the desired sequence of the field to the correct position in the list of fields:



[singlepic id=295 w=320 h=240 float=center]



3. Re-open the appropriate Sales Order window to display the field:



[singlepic id=296 w=320 h=240 float=center]







Setting Up a Basic Document Workflow in Compiere 3




Compiere's workflow processes form an integral part of the system. In this section we are going to learn how to setup a basic approval workflow for a document within Compiere.




The system definitions are as follows:






• A workflow is made up of a node and transitions.


• A node refers to a piece of work.


• A transition is the action to get to the next node, based on a logical condition.


• The workflow process is the active workflow and an activity for the processing of the active node (an activity also may have multiple parallel processes).


• A workflow also has an active State. A Workflow State refers to whether the workflow is running, not running, not started, completed, aborted, or terminated.


• Nodes also have Owners or Responsible persons.





[singlepic id=297 w=320 h=240 float=center]




Illustrative workflow example




We are going to set up a workflow between two roles, whereby the Gardenworld Purchasing role will capture a Purchase Order and the order will be approved by the Gardenworld User role. This type of approval requires a flag, and Compiere has a built in IsApproved database field that is used for this purpose.




Compiere has standard document workflows and transitions that are predefined within its workflow processes. These nodes are DocStart, DocPrepare, DocComplete, and DocAuto (automatic approval). What this means is that workflow processes already manage the transitions of documents, with the System being the Owner of these workflow nodes.










Defining a custom node in a workflow




We use the workflow editor to define a new node.






1. Open the Workflow editor window, and find the Order process Process_Order. Right-click in the editor, and then add an additional new node called Order Approval:



[singlepic id=298 w=320 h=240 float=center]



2. We need to define where the transition is going to take place by defining the originating node (Document prepare) and the next node (Document complete):



[singlepic id=299 w=320 h=240 float=center]



3. Click on the upper-right Zoom button to zoom to the actual workflow process, and find the newly-created node:



[singlepic id=300 w=320 h=240 float=center]



4. Define the node's owner by creating a workflow owner. Right-click on the workflow owner field:



[singlepic id=301 w=320 h=240 float=center]



5. The node's workflow owner is set to be role-based, as follows:



[singlepic id=302 w=320 h=240 float=center]



6. The Node for Approval can be summarized as follows:



[singlepic id=303 w=320 h=240 float=center]



7. Define the Transition of the node through a condition:



[singlepic id=304 w=320 h=240 float=center]









The condition we set up for the document workflow to transition to Document Complete is as follows:




[singlepic id=305 w=320 h=240 float=center]






Testing the workflow




We can now illustrate the workflow by creating an order and ensuring that it gets approved correctly.






1. We log in as the GardenWorld Purchasing role, as follows:



[singlepic id=306 w=320 h=240 float=center]



2. Create a Purchase Order, and then click on the Complete button. The Order will be placed in an In Progress status, because the workflow's next node is document approval:



[singlepic id=307 w=320 h=240 float=center]



3. We log off, and then log back in to the system with the GardenWorld User role (workflow owner):



[singlepic id=308 w=320 h=240 float=center]



4. Find the Workflow Activities menu item, and then approve the document, as follows:



[singlepic id=309 w=320 h=240 float=center]



5. The Document will be approved when the owner sets the approval status to Yes:



[singlepic id=310 w=320 h=240 float=center]






Summary




We have covered certain aspects with regards to Compiere in this three-part article series—namely the Application Dictionary (AD) and Workflows, as follows:





• We gave you an overview of the Compiere Application Dictionary components.


• We illustrated how to add a menu item and a custom list field to a Compiere window by using the AD components.


• We gave you an overview of the Compiere Workflow processes, and illustrated how this is set up.

Securing Data in The Cloud

I just found an interesting article about securing your data in the cloud. Now that cloud computing has gained quite a number of followers, it will be good to understand the additional necessary steps to ensure your confidential data are secured in a cloud computing environment.

The original article can be found here.

---

Storing data in the cloud is arguably the most important aspect of public cloud resources, but it is rarely treated as such. Two practical steps to take when securing cloud data are:

• Protect your data in a real world environment.
  
• Meet compliance requirements.
  

What are the issues?
There are two primary issues that we have to deal with when talking about data security in a public cloud:

• Protection of the data: Dealing with the confidentiality, integrity, and availability (CIA) criteria. Answering the important questions, such as, "What is the risk to the data? Are the controls in place adequate to mitigate the risk?"
  
• Location of the data: Dealing with the physical location of the "bits" and answering questions like, "Do I know where the data resides? Does this violate any of my compliance requirements?"

Location is often doubly important because we do not think about it; it may easily slip by unnoticed and have significant impact if a data loss ever occurs.

An example is the conflict between the U.S. Patriot Act and Canadian laws on the privacy of certain personal information. The U.S. government says if there is a compelling reason, they are able to see data in their jurisdiction. Canadian laws say that the data of certain Canadian citizens is protected and cannot be disclosed. If you handle Canadian data (i.e., data that is protected), then you had better be sure it is not physically located on systems in the U.S. Note that this is something providers will need to ensure via contracts.



Where to start: Data classification
If you don't take time to understand your data, then you are setting yourself up for failure in a public cloud environment. Therefore, securing data must begin with data classification.

Here are some steps to follow:

1. Identify the data that will be processed or stored in the cloud.
   
2. Classify the information in regards to sensitivity towards loss of the CIA criteria. This would include identifying regulatory requirements for the data.
   
3. Define the rules by which particular information classes of instances must be stored, transmitted, archived, transported and destroyed. Many handling requirements result from contractual or regulatory requirements.
   

A thought on physical location
As stated earlier, if there are restrictions on the physical location of data, you'll need to find a provider that can handle them. Amazon Web Services uses regions, and many of the other cloud providers offer similar structures. However, you need to ensure the service-level agreements meet your locality requirements.



Protecting data in the cloud
In the cloud, your data can be in any of the following locations:

• Local storage of the virtual machine (i.e., processing engine). Data is tied to the virtual machine location and state.
  
• Persistent data store (i.e., Amazon EBS or S3, Azure SQL, etc.). Data is independent of virtual machine location and state.
  
• In transit on the wire.
  

You will also need to use one of the following methods to meet your data protection requirements:

• File system and share access control lists: This would be using the access control mechanisms in the offering to ensure appropriate restrictions on the data. This would be used in all cases, but it would not protect from malicious IT staff at the provider.
  
• Encryption with a mixture of public and private key solutions: This would most likely be used to protect against malicious IT staff at the provider.
  
• Transport level encryption: This would be used as a matter of course whenever sensitive information was being passed or transmitted.
  

In closing
I strongly insist that everyone classifies their data. Once that is done, there are a couple of cloud issues you need to think about:

• Is my data stored where is should be?
  
• If there are any physical location limits, are those met?
  
• Am I protecting against malicious IT staff?
  

The rest should be basic security practices, much like those used in your non-cloud environment. There is nothing obscure about securing data in the cloud. Just remember that "good security is good security" and you should be good to go.

---

Run your own Ubuntu Enterprise Cloud, part 3

A continuation and final article on how to set up cloud computing on Ubuntu. This information is originally posted here.

---

In part 1 and part 2 of this series, we saw how to set up a minimal cloud infrastructure and bundle a basic image (and test it). In this final article, we’ll play with our cloud from an end-user perspective.

Setting up the web UI

First of all, before accepting end users, as the administrator of the cloud you will have to setup a few things on the web UI. Using your favorite browser, you should:

* Open https://cloudcontroller:8443/
* Log in using the default user/password: admin/admin
* Change the default password, setup the cloud admin email address
* Logout

Setting up the cloud client

We’ll use Ubuntu 9.10 beta for this purpose, as it includes all the needed packages, and it’s so great ! You will have to install the following packages:

      $ sudo apt-get install euca2ools unzip



Registering on UEC, getting credentials

As the end-user, fire up your favorite browser and:

      * Open https://cloudcontroller:8443/
      * Click “Apply” and enter your end user details

If you set up the email correctly on your cloud controller, it should send an email to the cloud admin address asking him to approve that request. Follow the instructions on that email to approve the account as the admin.

You should then get an email at the end user email address asking you to confirm the account request. Follow the instructions on that email, then you can log in on the web UI:

      * Open https://cloudcontroller:8443/
      * Login using your end user username and password
      * Click “Download Credentials” in the “Credentials” tab
      * Note the EMI reference you can use on the “Images” tab

Starting up an instance

You should unzip the credentials zipfile you just downloaded, then source the eucarc file and test the connection:

      $ unzip euca2-enduser-x509.zip
      $ . eucarc
      $ euca-describe-availability-zones verbose

Setup a SSH key and allow connection to the SSH port:

      $ euca-add-keypair enduserkey > enduserkey.priv
      $ chmod 0600 enduserkey.priv
      $ euca-authorize default -P tcp -p 22 -s 0.0.0.0/0

Then starting up an instance is just a matter of passing the right EMI and type:

      $ euca-run-instances -k enduserkey emi-XXXXXXXX -t c1.medium

Enjoy !

---

Run your own Ubuntu Enterprise Cloud, part 2

A continuation on how to set up cloud computing on Ubuntu. This information is originally posted here.

---

In part 1 of this series, we saw how to install the cloud infrastructure. In this article, we’ll bundle and upload an EMI (Eucalyptus Machine Image), based on Ubuntu Server 9.10 Beta, and validate that we can run an instance of it.

Download required elements

Go to the cloud/cluster controller and download the required items.

For a 64-bit image:

      $ URL="http://uec-images.ubuntu.com/releases/karmic"
      $ wget -O image.gz $URL/beta/ubuntu-uec-karmic-amd64.img.gz
      $ wget -O vmlinuz $URL/beta/ubuntu-uec-karmic-amd64-vmlinuz-
        2.6.31-11-server
      $ wget -O initrd $URL/beta/ubuntu-uec-karmic-amd64-initrd.img-
        2.6.31-11-server

For a 32-bit image:

      $ URL="http://uec-images.ubuntu.com/releases/karmic"
      $ wget -O image.gz $URL/beta/ubuntu-uec-karmic-i386.img.gz
      $ wget -O vmlinuz $URL/beta/ubuntu-uec-karmic-i386-vmlinuz-
        2.6.31-11-generic-pae
      $ wget -O initrd $URL/beta/ubuntu-uec-karmic-i386-initrd.img-
        2.6.31-11-generic-pae



Bundle the EMI

First you should unpack and resize your image to the desired size, lets say 4Gb. This can take a very long time (15 minutes !) on slow disks as you unpack 10Gb-worth of image space:

      $ zcat -f image.gz | cp --sparse=always /dev/stdin image
      $ e2fsck -f image
      $ resize2fs image 4G
      $ truncate --size=4G image

Then bundle and upload the kernel:

      $ . eucarc
      $ euca-bundle-image -i vmlinuz --kernel true
      $ euca-upload-bundle -b ueckernel -m /tmp/vmlinuz.manifest.xml
      $ euca-register ueckernel/vmlinuz.manifest.xml
      IMAGE eki-KKKKKKKK

Take note of the EKI reference, you’ll need it later. Then bundle, upload and register the ramdisk:

      $ euca-bundle-image -i initrd --ramdisk true
      $ euca-upload-bundle -b uecramdisk -m /tmp/initrd.manifest.xml
      $ euca-register uecramdisk/initrd.manifest.xml
      IMAGE eri-RRRRRRRR

Take note of the ERI reference. Finally, bundle the image with the kernel and ramdisk, upload and register:

      $ euca-bundle-image -i image --kernel eki-KKKKKKKK --ramdisk
        eri-RRRRRRRR
      $ euca-upload-bundle -b uecimage -m /tmp/image.manifest.xml
      $ euca-register uecimage/image.manifest.xml
      IMAGE emi-XXXXXXXX

Bundling will also take a lot of time ! Take note of your EMI reference.

Start an instance of your EMI

In order to access your instance using SSH, you’ll need to setup a few one-time things (create a SSH key and authorize access to port 22 of your instances):

      $ euca-add-keypair mykey > mykey.priv
      $ chmod 0600 mykey.priv
      $ euca-authorize default -P tcp -p 22 -s 0.0.0.0/0

Now it’s time to start your instance !

      $ euca-run-instances -k mykey emi-XXXXXXXX -t c1.medium

The “c1.medium” VM type is sufficient by default to run a 4Gb instance. You should take note of the i-YYYYYYYY reference that is displayed on your INSTANCE line. The first time you start an EMI, it can take some time (like 10 minutes) to move from “pending” state to “running”, depending on size. You can use the following command to automatically watch the output of euca-describe-instances, every 5 seconds:

      $ watch -n 5 euca-describe-instances

Take note of the first ZZZ.ZZZ.ZZZ.ZZZ IP address mentioned in the output of the command. When the instance is “running”, ctrl-C to exit watch, then:

      $ ssh -i mykey.priv ubuntu@ZZZ.ZZZ.ZZZ.ZZZ

You are in ! When you’re done playing with your instance, just run the following command on the cloud/cluster controller.

      $ euca-terminate-instances i-YYYYYYYY

In the third and last part of this series of articles, we’ll talk about how to run instances from another workstation, as a cloud “customer”.

---

Run your own Ubuntu Enterprise Cloud, part 1

This information is originally posted here.

---

Ubuntu Enterprise Cloud is the product, powered by Eucalyptus, that allows you to easily run your own Amazon-EC2-like private cloud. It’s a lot simpler than you’d think. With the recent Ubuntu Server 9.10 beta release, you are now able to easily deploy that infrastructure from the CD installer.

Prerequisites

To deploy a minimal cloud infrastructure, you’ll need at least two dedicated systems. One will hold the cloud controller (clc), the cluster controller (cc), walrus (the S3-like storage service) and the storage controller (sc). This one needs fast disks and a reasonably fast processor. The other system(s) are node controllers (nc) that will actually run the instances. These ones need CPUs with VT extensions, lots of CPU cores, lots of RAM, and fast disks. For both, 64-bit support is highly recommended.

Installing the cloud/cluster controller

Download the 9.10 Server beta ISO. When you boot, select “Ubuntu Enterprise Cloud install”. When asked whether you want a “Cluster” or a “Node” install, select “Cluster”. It will ask two other cloud-specific questions during the course of the install:

      1. Name of your cluster: pick any name you want :)
      2. List of IP addresses on the LAN that the cloud can allocate to instances:
         enter a list of space-separated unused IP addresses on your LAN.

When it reboots, run the following to get the latest eucalyptus package and reboot:

      $ sudo apt-get update
      $ sudo apt-get upgrade
      $ sudo reboot

Installing node controllers

The node controller install is even simpler. Just make sure that you are connected to the network on which the cloud/cluster controller is already running. Take the same ISO, select “Ubuntu Enterprise Cloud install”. It should detect the Cluster and preselect “Node” install for you. That’s all.

It is also recommended to update to the latest 9.10 status:

      $ sudo apt-get update
      $ sudo apt-get upgrade



Connect your node controllers to the cloud

After all nodes are installed, you need to return to the cloud/controller and run the following command to make it “discover” your newly-installed nodes.

      $ sudo euca_conf --no-rsync --discover-nodes

Confirm all the nodes it finds, and you are done. To check that your private cloud infrastructure is ready to serve, you need to retrieve admin credentials and run euca-describe-availability-zones command. Run the following on your cloud/cluster controller:

      $ sudo euca_conf --get-credentials mycreds.zip
      $ unzip mycreds.zip
      $ . eucarc
      $ euca-describe-availability-zones verbose

This last command returns a description of the capabilities of your cloud cluster, how many instances of each type you could run on it, for example:

AVAILABILITYZONE myowncloud   192.168.1.1
AVAILABILITYZONE |- vm types  free / max  cpu  ram disk
AVAILABILITYZONE |- m1.small  0004 / 0004  1   128    2
AVAILABILITYZONE |- c1.medium 0004 / 0004  1   256    5
AVAILABILITYZONE |- m1.large  0002 / 0002  2   512   10
AVAILABILITYZONE |- m1.xlarge 0002 / 0002  2  1024   20
AVAILABILITYZONE |- c1.xlarge 0001 / 0001  4  2048   20

In part 2 of this series, we’ll cover bundling your first EMI (Eucalyptus Machine Image), based on Ubuntu Server 9.10 Beta. We’ll test it by starting an instance of it. Stay tuned !

---