Hi, Had initial discussion with Azeez and Carbon team about $subject. Please find the details.
*Are we embedding MB into kernel?* We though of not to embed MB into kernel, rather runs it on top or separate. Kernel APIs are expect topology and ADC topic (MB end point) for the artifact distribution and the topology management. Will bungle light weight MB features with products which can runs in management node to cover requirement. But importantly kernel APIs are not depend on any specific MB, rather only need MB end point. *Important of the topology topic* Topology topic contain cluster detail of the all members, artifacts etc. When ever new member created (statically or dynamically) kernel will update the topology with member details like cluster, IP, ports etc. With the effect of topology introduce, Load Balancers get all member information dynamically which eliminate static member configuration. With the load balancer extension, capable of working with ANY load balancers without coupling to one. With the topology based LB support, we can achieved partition based artifact update without major effect. e.g. Say we are having 5 nodes on a cluster and want to update 3 node with artifact V1 and other two with artifact V2. ADC can instruct (will explain topic based ADC next section) second 2 nodes to take new version V2 and update the topology with relevant artifact version, then LBs can dynamically configure to route V1 to first 3 nodes and V2 to second 2 nodes etc. Topology also help to provide better solution to WKA member discovery in current hazelcast implementation. Simply we can get all members information for a cluster and update hazelcast member list. See same mechanism used in Kubernetes to member discovery on hazelcast based containers [1]. With the effect on that all members will be WKA and we also no need to go specific implementation AWS member discovery etc. This can be used in any cloud with out specific to a provider. Also this can used with any clustering implementation. (not specific to hazelcast) [1] https://github.com/pires/hazelcast-kubernetes-bootstrapper/blob/master/src/main/java/com/github/pires/hazelcast/HazelcastDiscoveryController.java *Topic based artifact synchronizer* This will replace hazelcast/SVN based artifact synchronizer. Instead sending cluster messages, artifact updates are notify via pub/sub communication which give more scalability and capable of multi region deployment support. Also new artifact update should have two phases. 1. Upload artifact to management node 2. Notify the members of the cluster Two phase model bring following benefits. - Artifact versioning support. - with the versioning effect, capable of artifact rollback - composite application artifact support - IMO individual products should not aware of the deployment logic of the composite apps artifacts, rather centralize ADC should handle the decompose logic and notify relevant products to get relevant artifact update. - Artifact update message should provide protocol and artifact end point ( IMO by default we should support HTTP based artifact end points), kernel will get and deploy the artifacts. - By default HTTP based artifact server will host in the management node, but if a cluster having larger size artifacts and frequent updates recommended to having separate file server. But either way artifact update APIs are not changed. These are some key points, can discussed details when having the review session. @Azeez is anything I missed? Welcome your thoughts :) PS: Also we have discussed MT model effect with containers and microservice based product deployment. Need separate thread I guess :) -- Lakmal Warusawithana Vice President, Apache Stratos Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blog : http://lakmalsview.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
