12:07 a.m.
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