[Satosa-dev] sharing state between satosa microservices

I am open to different solutions, with the preference to do it consistently within SATOSA. So I am happy to accept decisions from the group or our BDFL. However, I am a bit opinionated wrt passing the config via function args. (1) By making an explicit argument an implicit kwarg you would remove the possibility of static type checking. And (2) in general, configuration is rather a cross-cutting concern and should therefore not be part of a method signature. Also, when tracing the code (-> import autologging), the config data clutters the trace output. - Rainer 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> ha scritto: settings = LazySettings() where LazySettings is at: 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. 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!! 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 ------------------------------------------------------------------------------------------------------------------ Il banner è generato automaticamente dal servizio di posta elettronica dell'Università della Calabria <http://www.unical.it/5x1000>