From: "Owen W. Taylor" <otaylor@xxxxxxxxxxxx> 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 _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
