Am 2019-07-11 um 23:19 schrieb Giuseppe De Marco <giuseppe.demarco at unical.it>: Hi Rainer, very interesting to me. The last time I heard Borg pattern was 2010, I'm touched. It's simply a singleton pattern variation based on an attributes stored in the class scope. With your example I understand your proposal and yes, I think that's a good solution to handle this kind of shared state. In the past I used a modified singleton to share objects built with the same arguments: https://github.com/faif/python-patterns/blob/master/patterns/creational/bor… <https://github.com/faif/python-patterns/blob/master/patterns/creational/borg.py> this is also a simpler pure-borg example that I found very fun in its simplicity https://github.com/faif/python-patterns/blob/master/patterns/creational/bor… <https://github.com/faif/python-patterns/blob/master/patterns/creational/borg.py> Il giorno gio 11 lug 2019 alle ore 22:10 Rainer Hoerbe <rainer at hoerbe.at <mailto:rainer at hoerbe.at>> ha scritto: We did not have time in the last call to discuss this: There are use cases where we need to share state between a request and a response microservice. Now we have already 2 cases, so I suggest to define a common method to achieve this. The same approach could also be used to access the common config, e.g. if you need to know the proxy configuration (such as a backend entityid) in a microservice. A simple mechanism would be to use a module-level variable as singleton: ===================== shared_state.py state = {} ——— plugins/microservices/a.py from shared_state import state # import executes only once … state[’a’] = 'foo' ——— plugins/microservices/b.py from shared_state import state whatever(state['a‘]) ===================== I thing that for just passing request status to response microservices and passing config data around this should be good enough. There are several alternatives, like the Borg pattern, which I find harder to read. - Rainer _______________________________________________ Satosa-dev mailing list Satosa-dev at lists.sunet.se <mailto:Satosa-dev at lists.sunet.se> https://lists.sunet.se/listinfo/satosa-dev <https://lists.sunet.se/listinfo/satosa-dev> -- ____________________ Dott. Giuseppe De Marco CENTRO ICT DI ATENEO University of Calabria 87036 Rende (CS) - Italy Phone: +39 0984 496961 e-mail: giuseppe.demarco at unical.it <mailto:giuseppe.demarco at unical.it> ------------------------------------------------------------------------------------------------------------------ Il banner è generato automaticamente dal servizio di posta elettronica dell'Università della Calabria <http://www.unical.it/5x1000>

Am 2019-07-12 um 00:40 schrieb Giuseppe De Marco <giuseppe.demarco at unical.it>: I love it, you are talking about something like from django.conf import settings

So you are looking for a way to have a request microservice configuration available to a response microservice OR to a strategy to handle a session object to fill of whatever in in each moment (runtime), like in Django we can do with request.session object (as context object propose in satosa) Could we store all the proxy/plugins configuration in context object as a final solution?

Am 2019-07-12 um 15:41 schrieb Giuseppe De Marco <giuseppe.demarco at unical.it>: Il giorno ven 12 lug 2019 alle ore 07:56 Rainer Hoerbe <rainer at hoerbe.at <mailto:rainer at hoerbe.at>> ha scritto: right, with the exception that django hides some flexibility in configuring the settings file behind the import statement. settings = LazySettings() where LazySettings is at: https://github.com/django/django/blob/master/django/conf/__init__.py#L42 <https://github.com/django/django/blob/master/django/conf/__init__.py#L42> If I'm not wrong you told me that in the django approach the filename "settings" is a constant and this is a limit. This default behaviour can be overriden: os.environ.setdefault("DJANGO_SETTINGS_MODULE", "django_peo.settings") so it just rely to a environment variable called DJANGO_SETTINGS_MODULE. Not exactly. I have to 3 use cases: 1) obtain the satosa configuration in a microservice (currently only the ms configuration is available) 2) a potential refactoring that where modules would import configuration like in django, instead of passing the config as constructor argument. 3) pass the request state from request ms to the response ms The „singleton" pattern applies to 1 + 2, whereas I think the 3 is a separated concern. But it would be nice to have both types of state sharing as a defined infrastructure in satosa, not as a ms-specific hack. Point 1) Got it! We could in addition let the "config" argument to be handled in **kwargs. For example now we have: RequestOrResponseMicroService.__init__(self, config, *args, **kwargs): we could refactor in this way: RequestOrResponseMicroService.__init__(self, *args, **kwargs): and handle the config with a overridable approach, like this PoC: self.config = kwarg.get('config', lazy_approach_to_get_global_config()) if theresn't an overloaded config argument it will always get the global one. This refactor will only impact on MS classes and the contruction calls in the code to these, where the first arguments "config" should be named, if needs to be overloaded just in that MS runtime, or not -> for default behaviour. Point 2) Completely agree with you. I want to be honest, every time I'll hear "Django" I'll say: Yes, it is, Yes, it does, Yes, let's do it. I apologize and confess for it in advance! If we agree we could spend some thoughs about an abstraction layer to get and set configurations attributes runtime. We should have a class to handle get/set for lazy_conf. In it,for every plugins in the dictionary (key: name_of_plugin) for INTERNAL_ATTRIBUTES, BACKEND_MODULES, FRONTEND_MODULES and MICRO_SERVICES, we should have the same type with the same methods... Or a multilevel nested dictionary for all. You'll know which is better starting from to what we have at the moment. Point 3) I'll listen to this topic the better I can to undertand in the deep every related critical issues. From my point of view, that ignorant one, if we would configure SATOSA in a loadbalancer where the same user-agent session should be shared by different workers/agents/servers we need to make some shared storage persistence between these (Ivan told us about that layer, starting from sqlalchemy that sounds quite good). I confess in advance that I dislike cookies. From this stored "session" we could get and set information runtime from everywhere in the code. If these words were be code we would have just finished the refactor! Too verbose!! - Rainer Thank you R ____________________ Dott. Giuseppe De Marco CENTRO ICT DI ATENEO University of Calabria 87036 Rende (CS) - Italy Phone: +39 0984 496961 e-mail: giuseppe.demarco at unical.it <mailto:giuseppe.demarco at unical.it> ------------------------------------------------------------------------------------------------------------------ Il banner è generato automaticamente dal servizio di posta elettronica dell'Università della Calabria <http://www.unical.it/5x1000>

Hi All, this is a preliminar analisys about the strategy to obtain in MS constructors (__init__) the proxy configuration and also an abstract object where to store the shared state between MS (as we talked July the 9nth). In this place: https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/base.py#L89 we could pass proxy config as argument or calling a global function that does the following before returning satosa_config config_file = os.environ.get("SATOSA_CONFIG", "proxy_conf.yaml") satosa_config = SATOSAConfig(config_file) This latter idea could introduce in addition also a refactor of this: https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/wsgi.py#L12 moving it to a specialized function, importable everywhere, to get proxy configuration where needed. I think this is a better strategy to avoid passing configuration as argument in MS __init__. Regards Il giorno ven 12 lug 2019 alle ore 17:52 Rainer Hoerbe <rainer at hoerbe.at> ha scritto: -- ____________________ Dott. Giuseppe De Marco CENTRO ICT DI ATENEO University of Calabria 87036 Rende (CS) - Italy Phone: +39 0984 496961 e-mail: giuseppe.demarco at unical.it _______________________________________________ Satosa-dev mailing list Satosa-dev at lists.sunet.se https://lists.sunet.se/listinfo/satosa-dev