[Idpy-discuss] maintaining pyFF server ability to serve multiple feeds for discovery

Leif Johansson leifj at sunet.se
Fri Dec 21 23:07:20 UTC 2018


On 2018-12-12 06:27, Rainer Hoerbe wrote:
> My current approach to secure the metadata signing key is to put pyff on
> a non-internet facing server, and have pyffd consume the signed
> aggregate from the public feed. MDQ is not being used, but that
> configuration would support MDQ with presigned entities. Besides the
> central list-all IDP-ds we have local customized lists. These select
> IDPs based on white-listing and add intranet-only IDPs.
> 
> IMU the planned split shall separate pyffd into a kind of business- and
> presentation layer, but the aggregator will remain, right? Therefore the

yes

> aggregator's capability to consume other sources that an MDQ-service
> remains. It should be good enough to deploy another aggregator along

yes

> with the IDP-ds to have the functionality of the pipelines to do
> filtering, validation and aggregation. This grouping of pyff with pyffd
> should solve both Scott’s and my requirements.

Yeah I don't see any of that to change fundamentally

In fact there is nothing stopping pyff to distribute a shrink-wrapped
copy of the thiss.io frontend for discovery but in keeping with the
microservice religion it may be nicer to split a pyff deployment over
multiple containers, eg

- discovery frontend (thiss.io unless you want to use the "ra21" one)
- management & visualiztion frontend (on my todo-list to split off)
- aggregation backend - perhaps serializing to (say) redis
- mdq frontend

+ any combination of that... running on multiple hosts etc

Right now on my local branch I have a pyramid version of pyffd that
exposes a pure stateless API to the pipeline(s). There are no background
jobs - you trigger an update by a call to the update endpoint. The
result feels a lot cleaner than pyffd but I haven't touched pyffd
yet so nothing has been removed. Will push sometime during the hollidays

	Cheers Leif

	Cheers Leif


More information about the Idpy-discuss mailing list