When going with C5 we also need to preserve the idea of "immutable servers".
On Wed, Jul 22, 2015 at 10:42 AM, Harsha Thirimanna <[email protected]> wrote: > Hi Amila, > > Thanks for the feedback and will concern about these when we achieve this. > > thanks > > > *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* > > > On Tue, Jul 21, 2015 at 5:58 PM, Amila Maha Arachchi <[email protected]> > wrote: > >> Adding SPs and IDPs via config files is very useful when managing >> deployments. What if we provide a config file to add SPs and IDPs. At >> server start, relevant component reads it and stores the config in >> registry. So, other members in the cluster can get that info from the >> registry. This will only be usable for super tenant mode. These configured >> SPs and IDPs should be shown in the UI. If edited from UI, it should change >> the registry config. But if that change is not in the config file, in the >> next restart, it will get overwritten by the file. i.e. config file has >> precedence over ui. >> >> For tenants, this has to be allowed via the UI. When a SP or IDP is added >> from UI, it should be stored in registry. >> >> There is following option as well. That is to write a deployer for this >> as IS has done in multiple userstore scenario. Then we will need dep-sync >> to sync the config file across the cluster. >> >> IMO, first approach will cause less problems. But the second approach >> looks clean. >> >> On Tue, Jul 21, 2015 at 8:16 AM, Harsha Thirimanna <[email protected]> >> wrote: >> >>> Hi Prabath, >>> >>> Registry based dep-sync is not used and it is not supported anymore. >>> Yes we are not going to implement any of this in this release. Only >>> concern was without giving different solution for different places , wanted >>> to get some generic solution for at least next release. >>> I will create a public jira as an improvement for this and will concern >>> next release. >>> >>> Thanks >>> On Jul 20, 2015 7:31 PM, "Prabath Siriwardena" <[email protected]> wrote: >>> >>>> I think one common problem we need to address is to deploy service >>>> providers/ identity providers across tenants... >>>> >>>> If we use a file based approach - we should only use that. Do we have >>>> the registry-based dep-sync working now..? >>>> >>>> Also -1 to do any of the changes to 5.1.0 - its already months late.. >>>> >>>> Thanks & regards, >>>> -Prabath >>>> >>>> >>>> On Mon, Jul 20, 2015 at 2:12 AM, 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* >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> Prabath >>>> >>>> Twitter : @prabath >>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>> >>>> Mobile : +1 650 625 7950 >>>> >>>> http://blog.facilelogin.com >>>> http://blog.api-security.org >>>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, *Johann Dilantha Nallathamby* Technical Lead & Product Lead of WSO2 Identity Server Governance Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
