So lets take some examples: #1) Suppose user goes and creates version for an existing application. and at that time the connection between Issue tracking server was lost. therefore, the version is not created in Issue tracker. Eventually system recovered (or person responsible for maintain the system fixed the problem). However, the relevant version is not created in Issue tracker, therefore users can't report the issues against that application version.
#2) Suppose in a similar situation ( user creates an application version) connectivity between build server was lost. which means there won't be a build job created for the this application version. Hence user won't be able to build/deploy the application ( -- a blocker from users prospective). Even if the connectivity is restored momentarily that will not help the users since he can't build his application. #3) Application Creation : AF does lots of taks (creating repos , build jobs etc) behinds the scenes. if something goes heywire what would be the mechanism to correct it. ( in this particular scenario it might make sense to roll back ... which again could fail in middle.). #4) Tenant creation: same as above. In my opinion its not realistic for someone, to go and correct these, in the back end specially in a large deployment. ( Further, would tenants agree/ feel comfortable having parties who are maintaining the deployment accessing their data directly from backend ?). What I think we need is a way to repair/diagnose situations such as above without having to go to backend. it could be something like a service desk. Thoughts ? On Wed, Dec 4, 2013 at 5:22 PM, Amila Maha Arachchi <[email protected]> wrote: > Distributed systems are bound with failures in components. What needs to > be done is fail-proof (resilient) coding. A monitoring tool can alert us > with the failures and it will take time to fix them. > > Both deployment and code needs to be fail-proof. > > > On Wed, Dec 4, 2013 at 5:05 PM, Ramith Jayasinghe <[email protected]> wrote: > >> Basically what we need is some kind of a monitoring system to figure out >> if everything is running smoothly. >> And possibly have ways to correct inconsistencies/errors that occur. In >> my view its might not be realistic to log in to servers directly and do >> modifications when the deployment becomes large. >> >> >> >> On Wed, Dec 4, 2013 at 4:56 PM, Ushani Balasooriya <[email protected]>wrote: >> >>> Hi, >>> >>> Can we have the $subject. During the Automation demo, Internal issue >>> tracker was down. But when I proceeded with the flow, meantime could get it >>> up. >>> >>> Then when I tried to select the project from the drop down list of the >>> Issue tracker, the app was not visible since the issue tracker was down >>> during the app creation. So all the other actions taken was a waste. >>> >>> If there is a system to ensure all the other apps needed to this flow is >>> available, I think we can get rid of these type of issues. >>> >>> >>> Thanks and Regards, >>> -- >>> *Ushani Balasooriya* >>> Software Engineer - QA; >>> WSO2 Inc; http://www.wso2.com/. >>> Mobile; +94772636796 >>> >>> >> >> >> -- >> Ramith Jayasinghe >> Technical Lead >> WSO2 Inc., http://wso2.com >> lean.enterprise.middleware >> >> E: [email protected] >> P: +94 776715671 >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Amila Maharachchi* > Senior Technical Lead > WSO2, Inc.; http://wso2.com > > Blog: http://maharachchi.blogspot.com > Mobile: +94719371446 > > > _______________________________________________ > 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 776715671
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
