1:41 p.m.
Il giorno ven 12 lug 2019 alle ore 07:56 Rainer Hoerbe <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
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
--
------------------------------------------------------------------------------------------------------------------
Il banner è generato automaticamente dal servizio di posta elettronica
dell'Università della Calabria
<http://www.unical.it/5x1000>