Hi All
On Tue, Jan 28, 2014 at 11:33 AM, Manuranga Perera <[email protected]> wrote: > The problem ultimately boils down to this common scenario: > > a) A customer has a Jaggery app in their environment. > b) Some UI (images, css, headers, ect.) is customized > c) Now they find a bug and ask for a patch > +1, the issue here is all others replied here against patching a jaggery app is because you think of a jaggery app as a "hello world" web app. But you should look at the jaggery code in products like APIM / AppFac / UES / ES / MDM. In all these products Jaggery app is the place that has the major business logic. In these products Carbon is just the hosting environment. These are full fledge applications that does all kinds of things, generate meta data, has its own configurations etc, and when we find a minor issue we cannot ask people to replace the entire app and reconfigure every thing from the beginning. Just try the application developers shoes for a moment here and get out of the midleware developer mindset; Imagine we have developed an application and thats our main product. Now how do you fix problems in this product ? will you be shipping new versions of the product always when you find an issue ? If that is the case we will be shipping new versions of AS every day ;) Also when there is a requirement we should not think about how it can be squeezed into the existing model with minimum headache. We should find a comfortable solution for the users not something comfortable to implement. Just my 2cents Regards, /Nuwan > > What should we do? > > > On Tue, Jan 28, 2014 at 4:51 AM, Chan <[email protected]> wrote: > >> Below is my two cents - >> >> Let's look at the problem again. We have the X product deployed in >> Production. We have the version 1.0.0 of the app running in the server. We >> need to update some code that is in 1.0.0. >> >> I propose a solution based in git. We have a git repo for the app. I have >> done the code changes necessary in a private git repo. I will add my >> private git repo as a remote to the production app's git repository. >> Afterwards I can merge the production git repository and with my specific >> git commit. In a clustered environment the changes to the app will be >> dispersed to nodes (Artifact synchronization[1]). >> >> One downside I see in the above approach is that it's not portable (like >> a jar). But I think the above solution will solve the actual problem. >> >> WDYT? >> >> [1]- >> http://wso2.com/library/webinars/2012/10/enterprise-use-case-webinar-wso2-depsync-data-synchronization-between-nodes-cluster/ >> >> On Tue, Jan 28, 2014 at 1:37 PM, Afkham Azeez <[email protected]> wrote: >> >>> Cluster-wide patch distribution will be handle by the Operations Center. >>> >>> Azeez >>> >>> >>> On Tue, Jan 28, 2014 at 12:40 PM, Ruchira Wageesha <[email protected]>wrote: >>> >>>> >>>>>> >>>>>> If we patch a webapp, then we will do it only on master node and the >>>>>> patching process is for that. Synchronizing workers with master is a >>>>>> different task which belongs to depsync. Why do we need to mix up the >>>>>> things? May be I am missing something? >>>>>> >>>>> >>>>> No, you can't have patching only at master node and let dep-synch to >>>>> take care the rest of the patching. This will leave the system in a stage >>>>> where the slave nodes depends on dep-sych for the patching to work. If we >>>>> introduce patching process, it should be consistence across all the nodes >>>>> (servers). This is how we patch OSGi bundles. >>>>> >>>>>> >>>>>>>>>>>>>>>>> This might be a different conversation, but just to >>>> share my idea.... >>>> >>>> Why dep-synch doesn't sync the patches is because the way we have >>>> limited our own depsync model. i.e. We have used depsync only for synching >>>> so called artifacts. >>>> >>>> But assume, if we had a kernal with just an update manager like the >>>> ubuntu kernal. When we want to push something, we send an >>>> update notification and then server will update itself followed by a >>>> restart if it needed. When we want to do something to a cluster, what we do >>>> is just sending the message describing what we want to do. i.e. fetching >>>> *.jars, executing those jars(in case of a local db migration etc.) and >>>> restarting the server, deleting unwanted stuff etc. Even, we can remotely >>>> convert the whole ESB cluster to a different cluster. >>>> >>>> This would be a dumb idea, but that's how I see it personally. >>>> >>>> /Ruchira >>>> >>>> -- >>>> >>>> *Ruchira Wageesha **Associate Technical Lead* >>>> *WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>> <http://wso2.com>* >>>> >>>> *email: [email protected] <[email protected]>, blog: >>>> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, >>>> mobile: +94 77 5493444 <%2B94%2077%205493444>* >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Afkham Azeez* >>> Director of Architecture; WSO2, Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://www.apache.org/ >>> * <http://www.apache.org/>* >>> *email: **[email protected]* <[email protected]> >>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * >>> *http://blog.afkham.org* <http://blog.afkham.org> >>> *twitter: >>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez >>> <http://lk.linkedin.com/in/afkhamazeez>* >>> >>> *Lean . Enterprise . Middleware* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Chan (Dulitha Wijewantha) >> Software Engineer - Mobile Development >> WSO2Mobile >> Lean.Enterprise.Mobileware >> * ~Email [email protected] <[email protected]>* >> * ~Mobile +94712112165 <%2B94712112165>* >> >> * ~Website dulithawijewantha.com <http://dulithawijewantha.com/> * >> >> * ~Blog blog.dulithawijewantha.com >> <http://dulichan.github.io/chan/>* >> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : [email protected] > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Thanks & Regards,Nuwan BandaraTechnical Lead; **WSO2 Inc. * *lean . enterprise . middleware | http://wso2.com <http://wso2.com> * *blog : http://nuwanbando.com <http://nuwanbando.com>; email: [email protected] <[email protected]>; phone: +1 812 606 7390 * <http://www.nuwanbando.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
