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
Dear all,
I have an IdP that isn't signing its response (or is signing
improperly). I looked at the code for pysaml2 and found the
want_response_signed setting. I need to temporarily override
want_response_signed while I work with the IdP operator to fix this
issue, but I'd prefer to limit it to just the broken IdP. Is that
possible and if so, how?
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
Hello all,
A reminder that we have a call on the calendar for next week, using
BlueJeans. A copy of the calendar entry with the BlueJeans connection
info is attached.
-----
Updated Agenda:
0. Agenda bash
1. Project introduction
- Policy stuff: How do we communicate? Where should issues be reported?
- The community: Who is using our projects? How we communicate with
these entities? How can they get involved? What are their concerns?
- The competition: We offer a product, but there are other tools
that can satisfy one's requirements. What are we doing differently and why.
2. Project governance (Leif, Heather)
3. Project technical details
- Project goals and roadmap(s)
- Are there missing parts/additions we could incorporate/develop?
4. Review GitHub (does it have all the projects it's supposed to?) -
https://github.com/IdentityPython
5. TIIME planning (Rainer, Heather)
6. Administrivia
- call schedule and platform for 2018
- idpy-discuss vs satosa-dev lists
7. AOB
