[Idpy-discuss] maintaining pyFF server ability to serve multiple feeds for discovery
leifj at sunet.se
Tue Dec 11 14:58:13 UTC 2018
On 2018-12-11 15:36, Scott Koranda wrote:
> Hi Leif,
> One of the features of pyFF that I am currently leveraging is the
> ability to use different pipelines/configurations to offer multiple
> discovery service "backends", each with its own set of IdPs.
> This is important for a use case where a deployment supports multiple
> VOs and each VO needs to have its own set of IdPs that are included in
> For example, with one VO a particular IdP from a commercial
> pharmaceutical company should be included, but not for any other VOs.
> Today pyFF supports this but I would like to understand if the upcoming
> refactor (splitting off the discovery frontend into a separate project
> and refactoring the backend) will change that.
Yeah this is a requirement from multiple stake-holders so it is
definitely going to be supported. You will point the central
persistence service to multiple MDQ server backends basically
but there are other options for achieving the same result too.
> I guess more generally it would be nice to better understand your
> roadmap for pyFF development.
Right now I am starting work on a major "API-focused" refactor
of pyff that will do away with all of the frontend code, including
creating a separate "MDQ browser" application somwhere that could
be used with other MDQ servers besides pyFF.
I'm playing around in a separate fork right now and my current
thinking is to create a parallell "pyff-api" server that will
in time replace pyffd based on the pyramid framework. One of
the side-effects is to move more of the config from cmdline
to configuration files and/or environment variables over time.
The new fork may retain the current frontend "bits" but depending
on how well this is received they will either go away fast or
more slowly (or not at all if I screw up). In any case pyffd
will remain stable until we are comforable with "pyff-api"
I'll also probably make it easier to run multiple versions of
pyff in backend/frontend configurations (eg aggregating to a
redis instance in a backend and serving dynamically signed
objects from a frontend) each with separate pipelines
More information about the Idpy-discuss