On Thu, Jul 9, 2015 at 10:16 AM, Ramith Jayasinghe <[email protected]> wrote:
> 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? > > IMO, we should used same mechanism to both single and clustered scenario. Otherwise we are complicating our life :). We need a single node because it having less load, IMO which is OK with embed MB > 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 > > -- Lakmal Warusawithana Vice President, Apache Stratos Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blog : http://lakmalsview.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
