can't we make the single node work without having to go through topics etc? and topic based artifact distribution mechanism get enabled only if clustering is enabled?
On Thu, Jul 9, 2015 at 8:40 AM, Srinath Perera <[email protected]> wrote: > Overall look good. > > How would the single node version work? Does it embed MB? > > Kernel, are we using JMS as message interface or wrap it in our own > interface? > > --Srinath > > > > On Thu, Jul 2, 2015 at 3:49 PM, Lakmal Warusawithana <[email protected]> > wrote: > >> 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/ >> >> > > > -- > ============================ > Blog: http://srinathsview.blogspot.com twitter:@srinath_perera > Site: http://people.apache.org/~hemapani/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Ramith Jayasinghe Technical Lead WSO2 Inc., http://wso2.com lean.enterprise.middleware E: [email protected] P: +94 777542851
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
