1:24 p.m.
Hello,
Hi,
Thanks Ivan for starting this dialogue.
> - have each microservice be its own python package and selectively
> install it using pip
>
> My concern with that approach is that most of my deployments use
> multiple microservices (sometimes as many as 4) and so it would be a bit
> cumbersome to install SATOSA and then 4 additional microservices. It
> would be simpler to just have the microservices be a complete package by
> itself.
>
> On the other hand there is the issue of a microservice having unique
> dependencies, like the LDAP Attribute Store has on ldap3.
>
> I do not have a good answer.
> - have the microservices repo be a package itself and use pip to install it
> - have microservices repo as a git module under satosa (not suggested)
>
> I agree. That is not a good idea.
> - have microservices as something completely external and fetch using
> http/git (as shown below). This could mean a lot of different things -
> ie, should microservices use code from satosa? if so, satosa is a
> dependency to microservices and as such this makes microservices a
> package with dependencies, etc.
> - (more options?)
>
> Skoranda mentioned that
>
>> If you need the LDAP Attribute Store microservice you must also install ldap3
using pip:
>
> This indicates that certain microservices have their own dependencies.
> Users cannot guess what dependencies are needed for a certain
> microservice. This information should be explicit and automatically
> resolved by the microservice installation process.
> This leads me to think to having each microservice as a separate
> (python) package, with its own dependencies and deployment process, is
> the way to go.
>
> I think I agree. A deployment that uses many microservices would find it
> a bit cumbersome, but not that much since pip does make it fairly
> straightforward. This is probably the best compromise.
I agree with Ivan and Scott here. I would prefer to explicitly install any microservices I
need as long as it takes care of all the dependencies. I don't think this makes it too
cumbersome, and automated provisioning/deployment tools take away that complexity too.
The only issue I would see is the possibility to end up with a huge compatibility matrix
to describe which satosa version works with which versions of each microservice, but the
interface is rather simple and I don't foresee any breaking changes there in the
future.
Ioannis
Thanks,
Scott K
---------------------------------------------------------------
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev