[
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
- Cluster Created Event
- Instance Spawned Event
- Member Started Event
- Member Activated Event
- Member Suspended Event
- Member Removed Event
- Cluster Removed Event
- Service Removed Event
- Complete Topology 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 events 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
- Cluster Created Event
- Member Added Event
- Member Started Event
- Member Activated Event
- Member Suspended Event
- Member Removed Event
- Cluster 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 events 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
> 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
> - Cluster Created Event
> - Instance Spawned Event
> - Member Started Event
> - Member Activated Event
> - Member Suspended Event
> - Member Removed Event
> - Cluster Removed Event
> - Service Removed Event
> - Complete Topology 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 events 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)
