1:56 p.m.
Hey everyone,
Now that satosa-microservices are split into their own repository we
should set the process which acquires them back to the setup. There
are many options here:
- have each microservice be its own python package and selectively
install it using pip
- 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)
- 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.
This is not a simple decision to make. Let's have a discussion on how
the dev-community think it is better to be solved.
Cheers,
PS: This discussion was triggered by skoranda's PR here:
https://github.com/IdentityPython/SATOSA/pull/168#discussion_r149634137
--
Ivan c00kiemon5ter Kanakarakis >:3
2:12 p.m.
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
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.
Thanks,
Scott K
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. 
2: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 
2:34 p.m.
Am 08.11.2017 um 14:24 schrieb Ioannis Kakavas
<ikakavas at protonmail.com>:
Hello,
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.
I would prefer not to have dependencies hard coded (like pysaml1==4.x.x). That requires
forking the main project because of a changed dependency.
Ideally by default a safe version of a dependency would be installed, but it could be
overruled just by installing some other version before. that should apply to
microservices, plugins and other packages.
- Rainer
2:38 p.m.
I would prefer not to have dependencies hard coded
(like pysaml1==4.x.x). That
requires forking the main project because of a changed dependency.
I agree. The dependency on a particular version of pysaml2 has been
bothersome since there has been so much (quite helpful) evolution of
pysaml2 lately and production deployments need the latest release. All
of my production deployments have extra
pip --upgrade pysaml2
instructions.
I would like to use minimum version dependencies as much as possible and
let pip grab the latest version when available.
Scott K
2:42 p.m.
-------- Original Message --------
Subject: Re: [Satosa-dev] Microservices installation
Local Time: November 8, 2017 3:38 PM
UTC Time: November 8, 2017 1:38 PM
From: skoranda at gmail.com
To: Rainer Hoerbe <rainer at hoerbe.at>
Ioannis Kakavas <ikakavas at protonmail.com>, satosa-dev at lists.sunet.se
<satosa-dev at lists.sunet.se>
++
I would prefer not to have dependencies hard
coded (like pysaml1==4.x.x). That
requires forking the main project because of a changed dependency.
I agree. The dependency on a particular version of pysaml2 has been
bothersome since there has been so much (quite helpful) evolution of
pysaml2 lately and production deployments need the latest release. All
of my production deployments have extra
pip --upgrade pysaml2
instructions.
I would like to use minimum version dependencies as much as possible and
let pip grab the latest version when available. Scott K
3:53 p.m.
Hi everyone,
Martin opened a new issue over the satosa_microservices repository
related to this topic.
https://github.com/IdentityPython/satosa_microservices/issues/10
Everyone is welcome to express their opinion on the matter.
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
2236
days inactive
2382
days old
6 comments
4 participants
participants (4)
-
ikakavas＠protonmail.com -
ivan.kanak＠gmail.com -
rainer＠hoerbe.at -
skoranda＠gmail.com