s/configurable/deployable Thanks & Regards Danushka Fernando Senior Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729
On Mon, Jul 20, 2015 at 4:02 PM, Danushka Fernando <[email protected]> wrote: > Why can't we do the same thing when we add it from the config file and ui? > I mean in both cases if we write to the same place in same manner then ui > can read it from db and show it in ui so users can see it added from the UI > as well. > About claim configs +1 to make it configurable. In customer deployments we > have faced the problem that if we do it wrong in first time then we need to > clean dbs and restart. > > Thanks & Regards > Danushka Fernando > Senior Software Engineer > WSO2 inc. http://wso2.com/ > Mobile : +94716332729 > > On Mon, Jul 20, 2015 at 2:42 PM, Harsha Thirimanna <[email protected]> > wrote: > >> Hi All, >> Since we support file base deployment for SP/IDP, we should have >> consistent mechanism to deploy it in clustered environment. >> >> *How it works now* >> We can create SP and IDP from UI and it is stored in data base, for both >> super tenant and multi-tenant mode. >> In file base, we can only create super tenant SP/IDP. It is also not show >> in the UI. >> >> *Problems* >> When we create IDP or SP in file, we update the database and retrieve >> from database when it wants. Every time when restart the node, we >> re-deploy all the idp configs. In cluster mode, we have to maintain same >> config file in all the node, otherwise wrong file may be updated or some >> other node will delete from database if some files not available in there. >> In claim deployment, we deployed claims from config file only in very >> first start of the server. So after that we can't change the file. We have >> to go to the UI. If we solve that problem to deploy when it change, then >> above pattern can be seen again. >> >> *Suggesion* >> If we consider these are as deploy-able artifact, then we can move these >> in to the deployment path and allow to dep-synch work. In that case , only >> concern is adding configs to the database or not. >> OR >> We can keep as same now and write simple deployment component base on >> database. We can delete config file just after update the database from >> file and let user to edit from UI. If user want to change from file only, >> then he can put new config again and it will udpate database again and >> delete file in local. Then we don't want to put any file in to the other >> node in cluster. But if we put another config file in other node, then it >> will update the database(but not a big issue). >> OR >> As same as second option in above, we can update database from reading >> file and keep the file as it is without deleting from locally. To do that >> we have to create a config to allow , one specific node to do the update >> and others are not. All the config can be seen from the UI and allow to >> edit. >> >> WDYT ? >> >> *Harsha Thirimanna* >> Senior Software Engineer; WSO2, Inc.; http://wso2.com >> * <http://www.apache.org/>* >> *email: **[email protected]* <[email protected]>* cell: +94 71 5186770 * >> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>* >> *harshathirimannlinked-in: **http: >> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122 >> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>* >> >> *Lean . Enterprise . Middleware* >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
