Product registry setup

[elsony]

JBoss EAP XP 2.0 stack is the first product stack that requires a login (Red Hat login) to access the image (see odo-devfiles/registry#67). Given that it requires login, it is not something that we can return as part of the list in a public community registry query.

We can provide separate queries of product vs community stack by:

1. single registry with filtering
   1. use specific tags for product vs community stacks
   2. a different option will be using a vendor field in stack metadata
   3. add query filtering based on tags/vendor in registry access (both common library and REST API)
2. separate registry for both
   1. one for product registry and another for community registry
   2. tools can access the registry using different URLs
   3. some stack may be duplicated in the two registries, e.g. the product registry may still want to return the community ones since it supports both
   4. for this option, do we use a single source registry repo (and provide a way to specify) or use separate registry source repo?

Checklist:

• Bootstrap the product devfile registry git repository: Set up a Git repository for the product devfile registry #512
• Create staging and production environments on OSD for the production registry
• Set up CI jobs to build and deploy the product registry to staging/prod: Set up CI jobs to build and deploy the devfile registry to staging and prod redhat-developer/devfile-registry#2
• Request a subdomain under redhat.com for the product registry Set up a hostname under *.redhat.com for the product registry redhat-developer/devfile-registry#3
• Run post-deploy acceptance tests against staging Run post-deploy acceptance tests against staging redhat-developer/devfile-registry#4
• Enable monitoring for the product devfile registry Enable monitoring for the product devfile registry redhat-developer/devfile-registry#5

[elsony]

Choose option 2 to use separate registries for both. Source registry is using separate repo.
Community: https://github.com/devfile/registry
Product: https://github.com/devfile/registry (need to figure, maybe under openshift org)

[elsony]

We'll continue to use this item for tracking the setup of the product registry

[johnmcollier]

Before moving forward on this item, there's a couple things that need to be decided on:

1. Location of source repository for product devfiles
   • https://github.com/openshift may be good candidate, as mentioned above by @elsony.
2. Hostname to deploy / run the registry under.
   • Something under *.redhat.com or *.openshift.com? Or something else?
3. Is the only product stack we have right now JBoss EAP XP 2.0? Are there others we should include as well?
4. Issue tracking for the product registry
   • Where should stories / issues specific to the product registry be opened?
   • Not referring to issues/stories about specific stacks.

Some other items that won't block onboarding, but should be decided on sooner rather than later:

• Any specific branding for the product registry's viewer that we need?
• Documentation for the product registry?
  • Should include instructions on getting authenticated to pull the product container images
  • Where should the docs reside?

[johnmcollier]

Discussed on today's call:

1. Will use the OpenShift org on GitHub for the Git repository Will use redhat-developer/devfile-registry instead.
2. Hostname TBD, will check with @slemeur, *.redhat.com
3. Jboss EAP is the only stack right now, but the Che team may contribute some of their stacks/samples
4. Will use the new repository for issue tracking rather than devfile/api

[johnmcollier]

Updated the issue description to add a checklist of tasks.

[johnmcollier]

devfile-registry.redhat.com and devfile-registry.stage.redhat.com are now available.

All that remains now is the post acceptance tests and monitoring.

[johnmcollier]

I've got merge requests up on gitlab that enable the following:

• Grafana dashboard for the product registry
• Post deploy acceptance tests for the product registry

[johnmcollier]

All that remains now is triggering AlertManager for the service and we can close this out.