The current implementation works like this:

The incoming provisioning request could range from provisioning the smallest of servers i.e. 1 web, 1 app, 1 db to hundreds of machines in each "tier". The current implementation attempts to conduct the provisioning concurrently by having the Restlet offload to a potentially large thread pool within the Restlet and have it fire literally hundreds to thousands of requests to the MOAB and each request results in a returned XML which has to be parsed.

The current observation is that whenever that happens, the Restlet gets the Premature end of file exception and results in partial provisioning. Since the current mechanism doesn't cater the "Retry" mechanism, we can only for now do it in a sequential fashion.

The front-end has a virtual private cloud designer i.e. vpc that allows the users to design a vpc, store / update and eventually provision it. The backend engine needs to provide the following interfaces

• HTTP PUT to store the design
• HTTP GET to return the design in XML
• HTTP POST to provision the design
• HTTP GET to return the status of the running design (this is currently provided)

Provide a HTTP POST to shutdown the VM. Expected input parameters includes the tenant's id & VM/PM id

When the attempt is made to update the design configuration, the application wrongfully attempted to store the document as a Java XML object and that'll be fine if there was some sort of serialization but unfortunately there wasn't.

The stack trace

WARNING: Exception or error caught in resource
java.lang.IllegalArgumentException: can't serialize class com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl
at org.bson.BSONEncoder._putObjectField(BSONEncoder.java:234)
at org.bson.BSONEncoder.putObject(BSONEncoder.java:140)
at org.bson.BSONEncoder.putObject(BSONEncoder.java:86)
at com.mongodb.OutMessage.putObject(OutMessage.java:190)
at com.mongodb.DBApiLayer$MyCollection.update(DBApiLayer.java:341)
at com.mongodb.DBCollection.update(DBCollection.java:150)
at com.mongodb.DBCollection.update(DBCollection.java:162)
at DesignServerResource.storeDesign(DesignServerResource.java:67)

Background

The Diagnostic.java is a Restlet that's designed to handle HTTP GET RESTful queries. The idea is to provide a client RESTful where the user can submit a query request to check the status of the virtual private cloud. The design is to take the request and mine the configuration data off the local database (MongoDB) and fire asynchronous commands to the MOAB server. As the VPC can be rather large, the current design is to send off 3 groups of asynchronous requests marked by their tier (e.g. web, app, db). Next, the Restlet will gather all these async requests and finally return the XML document.

What it should be

The implementation defines a thread-local buffer to store the result of each async MOAB request/response operation. As long as the buffer's size is good, you should see at least a well-formed XML document. e.g.
<xml>
<request>
<status>ok</status>
...
</request>
</xml>

What is observed

The buffer's size is good e.g. 2048-bytes but when a dozen threads are in operation, the output is truncated in a rather unpredictable fashion.

Workaround

The buffer has been resized to 256-bytes instead. However, it needs to be investigated as to why its occurring.

Provide a HTTP POST to start up the VM/PM. Expecting parameters including tenant's id & VM/PM's id.

Provide a API that allows the user to submit a destroy request. Expected parameters including tenant's id & VM/PM's id. Also, need to take this VM/PM out from the database.

The front end of the GCloud needs to be able to allow the user to activate the remote console whence he/she can control the startup/shutdown of the virtual machine. It has been determined to use VMWare's remote console feature and currently we have only one ESX host (afaik) so its the job of the backend engine to augment the virtual private cloud's configuration file to include 2 additional tags
i.e.
<vncport>
<vncpassword>

As the resource manager needs a local database to maintain its state, its obviously useful to have an automated procedure to install its dependencies i.e. MongoDB.

The request came from Rully.

Turns out that he would like the VPC configuration file be augmented with a new tag <status> in each <machine> so that his front-end (wicket code) doesn't have to write a new parser to parse the returned XML and augment it himself.

The approach would be to implant the new statuses into the original VPC configuration file and pass it back

The default format is whatever java.util.Date() generates which is wrong; but the format hasn't been finalized yet so this issue is more of a tracker