Hi Chamil,

A nice design! I have one question:

Is there any reason for introducing a separate component for manager agent?
For me it sounds like "manager" is a special behaviour in node agent which
could be configured. WDYT?

Thanks
Imesh


On Wed, Dec 11, 2013 at 5:34 PM, Chamil Jeewantha <[email protected]> wrote:

> We are going to implement the "View Topology" scenario as a quick start up
> to the OC work. Here is the very simple communication defined for this
> scenario.
>
>
> Components
>
> The Operation Center (OC) consists of several components:
>
>    1.
>
>    Node Agent
>    2.
>
>    Manager Agent
>    3.
>
>    OC backend
>    4.
>
>    OC Frontend (The UI)
>
>
> The Initial development will be focussing only on “View Topalogy” on the
> scenario.
>
> Communication flow
> Node to OC Backend communication - (The Manager node in the cluster
> skipped Only for the first phase)
>
>    1.
>
>    When a node starts, it sends a initial message to the OC backend.
>    2.
>
>    When a node stops, it sends a status notification to the OC backend.
>    3.
>
>    The node will send status notifications to the OC Backend  each time
>    when the configured time interval expires.
>    4.
>
>    If the OC Backend didn’t receive the status notification of a given
>    node for a configured time period, It assumes that node is non-functional.
>
>
> Status notification
>
> URL
>
> PUT /oc/1/node/status               format:
> (<http/https>://<url>/oc/<version>/node/status)
>
> Request Body
>
> {
>
>                 "id":"n1"
>
>                 ,"clusterId":"BPS"
>
>                 ,"product":"BPS"
>
>                 ,"elb":["elb1","elb2"]
>
>                 ,"name":"N1"
>
>                 ,"cpu": "20"
>
>                 ,"state": "STARTED"
>
>  }
>
> JSON parameter descriptions
>
>
>  Parameter
>
> Possible values
>
> Description
>
> id
>
> Any non empty string
>
> unique id (within the cluster) to identify the node
>
> clusterId
>
> Any non empty string
>
> Id of the cluster the node belongs to
>
> product
>
> ELB, BPS, IS ...
>
> TO identify what type of the product is deployed in the node.
>
> elb
>
> Id of a deployed elb instance
>
> Name
>
> Any String
>
> Name of the node
>
> cpu
>
> Any Integer
>
> percentage of the CPU usage
>
> state
>
> STARTED, STOPPED, CRASHED
>
> state of the server.
>
> *Response*
>
>  200 OK - if the notification is correct.
>
> Error Codes:
>
> <TODO>
>
> OC Backend to OC Frontend(UI) communication
>
> This is simply a JSON based communication in whatever the way the UI
> people wants.
>
> Possible:
>
>    1.
>
>    AJAX
>    2.
>
>    Caramel module
>    3.
>
>    etc….
>
>
> --
> K.D. Chamil Jeewantha
> Associate Technical Lead
> WSO2, Inc.;  http://wso2.com
> Mobile: +94716813892
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Imesh Gunaratne*
Technical Lead
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: http://imesh.gunaratne.org
Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to