From: "Owen W. Taylor" <otaylor(a)fishsoup.net>
This is an initial attempt to create a configuration for flatpak-indexer to replace
regindexer and add an image delta capability. The config here is derived from
a working openshift configuration, but is untested in this form.
See: https://pagure.io/fedora-infrastructure/issue/9272
Open questions:
How to propagate content to the registry.fedoraproject.org reverse proxy
========================================================================
Currently the regindexer-generated content is rsync'ed from sundries to
fedora-web/registry. How should this be done with flatpak-indexer running as
an openshift app? Some possibilities that come to mind:
- Run a rsyncd within the openshift app (either as a separate deploymentconfig
or as a sidecar to the indexer) and expose a route to it internally in
Fedora infrastructure.
- Run a web server within the openshift app, expose a route to it internally
in Fedora infrasturcture, and reverse proxy the content on fedora-web/registry
instead of rsync'ing it.
- Write the content onto a netapp volume, and mount that volume RO either
on a host running rsyncd or directly on fedora-web/registry.
What to use for a redis image
=============================
Redis is used for caching and communication between the components. What redis
image should be used?
registry.redhat.io/rhel8/redis-5
needs configuration of a subscription
docker.io/library/redis:5
centos/redis-5-centos7
don't rely on such images currently
Custom Dockerfile image built from fedora:32
how would rebuilds be triggered?
For the two other images needed here, I used ubi8 images - which aren't currently
used elsewhere, but are presumably ok.
How to handle identifying versions to build for staging/production
==================================================================
I see that most openshift applications simply use 'staging'/'production' tags
in the upstream repo, while a few take the approach of having specific hashes
checked into the infrastructure ansible repository.
Is the upstream tag approach considered sufficiently secure? (Making the service
write a malicious index could allow causing users to upgrade to arbitrary
application binaries.)
Owen W. Taylor (1):
Add a flatpak-indexer openshift service
playbooks/openshift-apps/flatpak-indexer.yml | 56 +++++
.../reversepassproxy.registry-generic.conf | 34 ++-
.../flatpak-indexer/files/imagestream.yml | 52 +++++
.../flatpak-indexer/files/service.yml | 16 ++
.../flatpak-indexer/files/storage.yml | 24 ++
.../flatpak-indexer/templates/buildconfig.yml | 84 +++++++
.../flatpak-indexer/templates/configmap.yml | 98 ++++++++
.../templates/deploymentconfig.yml | 221 ++++++++++++++++++
.../flatpak-indexer/templates/secret.yml | 11 +
roles/regindexer/build/tasks/main.yml | 21 --
roles/regindexer/build/templates/config.yaml | 74 ------
11 files changed, 584 insertions(+), 107 deletions(-)
create mode 100644 playbooks/openshift-apps/flatpak-indexer.yml
create mode 100644 roles/openshift-apps/flatpak-indexer/files/imagestream.yml
create mode 100644 roles/openshift-apps/flatpak-indexer/files/service.yml
create mode 100644 roles/openshift-apps/flatpak-indexer/files/storage.yml
create mode 100644 roles/openshift-apps/flatpak-indexer/templates/buildconfig.yml
create mode 100644 roles/openshift-apps/flatpak-indexer/templates/configmap.yml
create mode 100644 roles/openshift-apps/flatpak-indexer/templates/deploymentconfig.yml
create mode 100644 roles/openshift-apps/flatpak-indexer/templates/secret.yml
delete mode 100644 roles/regindexer/build/tasks/main.yml
delete mode 100644 roles/regindexer/build/templates/config.yaml
--
2.28.0
