[jira] [Updated] (STRATOS-99) Implement Topology Events

["Imesh Gunaratne (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/STRATOS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Imesh Gunaratne updated STRATOS-99:
-----------------------------------

    Description: 
According to the new architecture, Stratos modules communicate with each other via the message broker when pub/sub type messaging is required. Topology is a data structure which is updated by the Cloud Controller and required by Load Balancers, Artifact Distribution Coordinator, Auto-scaler, Complex Event Processor, etc. Therefore topology could be distributed in Stratos eco-system via a topic in the message broker.

These messages could be designed in a way where each message represents an topology event.

Proposed Topology Events:
- Service Created Event
- Cloud Created Event
- Region Created Event
- Cluster Created Event
- Member Added Event
- Member Started Event
- Member Activated Event
- Member Suspended Event
- Member Removed Event
- Cluster Removed Event
- Region Removed Event
- Cloud Removed Event
- Service Removed Event
- Topology Updated Event

The idea is to trigger "Topology Updated Event" containing the complete topology periodically (time interval: t1), so that the receiver could initiate receiving topology event from that point onwards. The only downside of this design is that the receiver might need to wait for t1 to be operational.

The other option would be to do a service call to Cloud Controller to receive the complete topology without sending it periodically. The concern with this approach would be that the URL of the Cloud Controller should be known by the receiver.

Topic Name:
topology-topic

  was:
According to the new architecture, Stratos modules communicate with each other via the message broker when pub/sub type messaging is required. Topology is a data structure which is updated by the Cloud Controller and required by Load Balancers, Artifact Distribution Coordinator, Auto-scaler, Complex Event Processor, etc. Therefore topology could be distributed in Stratos eco-system via a topic in the message broker.

These messages could be designed in a way where each message represents an topology event.

Proposed Topology Events:
- Service Created Event
- Cloud Created Event
- Region Created Event
- Cluster Created Event
- Member Added Event
- Member Started Event
- Member Activated Event
- Member Suspended Event
- Member Removed Event
- Cluster Removed Event
- Region Removed Event
- Cloud Removed Event
- Service Removed Event
- Topology Updated Event


> Implement Topology Events
> -------------------------
>
>                 Key: STRATOS-99
>                 URL: https://issues.apache.org/jira/browse/STRATOS-99
>             Project: Stratos
>          Issue Type: Sub-task
>    Affects Versions: 4.0.0
>            Reporter: Imesh Gunaratne
>            Assignee: Imesh Gunaratne
>             Fix For: 4.0.0
>
>
> According to the new architecture, Stratos modules communicate with each other via the message broker when pub/sub type messaging is required. Topology is a data structure which is updated by the Cloud Controller and required by Load Balancers, Artifact Distribution Coordinator, Auto-scaler, Complex Event Processor, etc. Therefore topology could be distributed in Stratos eco-system via a topic in the message broker.
> These messages could be designed in a way where each message represents an topology event.
> Proposed Topology Events:
> - Service Created Event
> - Cloud Created Event
> - Region Created Event
> - Cluster Created Event
> - Member Added Event
> - Member Started Event
> - Member Activated Event
> - Member Suspended Event
> - Member Removed Event
> - Cluster Removed Event
> - Region Removed Event
> - Cloud Removed Event
> - Service Removed Event
> - Topology Updated Event
> The idea is to trigger "Topology Updated Event" containing the complete topology periodically (time interval: t1), so that the receiver could initiate receiving topology event from that point onwards. The only downside of this design is that the receiver might need to wait for t1 to be operational.
> The other option would be to do a service call to Cloud Controller to receive the complete topology without sending it periodically. The concern with this approach would be that the URL of the Cloud Controller should be known by the receiver.
> Topic Name:
> topology-topic



--
This message was sent by Atlassian JIRA
(v6.1#6144)