Summer of Code project

Arthur - student
Lucas - mentor

instance on GCE hosting it
image-finder.d.net

Source in cloud team on Salsa

API
RSS feed
Filters

RSS - to get info about images

*.md files to describe providers
Directory markdown, its content is published by Image Finder

Postgres
Flask (python)

docker to deploy


CI
lint: flake8
Docker image registry on Salsa

DB
User
Provider
Image

Image
architecture
elease
type ?
version ?
job url
package ?

+ date 

New field - region?
+ launch link


API
===
UI is interesting, but for automation might be better for advanced users or automation

User - admin and ordinary one
admin can create new users
Authenitcated users can publish images

Do we want to have users at all?
Publishing images will only be done from Salsa

We might need to have user management to allow for OpenStack providers to register
to have images pushed to them
But - maybe let them pull RSS and deal with it themselves?
And don't do any filtering ourselves. We provide info about everything,
and it's their responsibility to do everything.

OTOH if we publish it ourselves, and then we maintain metadata and everything.
This way we make sure that all images are named the same

But not all providers will be comfortable giving us access so we can publish
images to their clouds

We might just provide script which will take care of it, to be run on
OpenStack by themselves. They will take care of running it, monitoring,
providing credentials, and so on.
==> 

We should provide (proposed) standardized metadata

As a user - should I consult cloud provider or Image Finder to get latest (or any)
image?

Provider-specific RSS feeds

Do we do signing or anything?

Next steps:
put real data (existing, already published images)
integrate with Salsa CI so new (daily) builds are added there
This way we can see how it looks in real life

adding region information - new table, or just JSONB column in Postgres
This way it'll be extensible (ability to add provider-specific data about images)