Update EP with `build` command and `opm registry` command deprecation

[anik120]

This PR

• Updates the declarative index config enhancement to rename the create and update sub-commands under opm index to a single unified build command.
• Updates the migration process to deprecate the opm registry commands instead of removing them.

[bparees]

My ask: Provide a registry-less variant that supports decoupling from all registry interaction where the build simply builds the directory structure and database (if needed) and the Dockerfile.

+1, this is the direction s2i ultimately took once it became clear that direct support for podman+docker+(future) wasn't something we wanted to sign up for maintaining.

[anik120]

@cdjohnson IIUC, you don't want to use the opm index build commands because of the issues you mentioned in your comment.

My ask: Provide a registry-less variant that supports decoupling from all registry interaction where the build simply builds the directory structure and database (if needed) and the Dockerfile.

Example: opm registry build .... that outputs the index.db file that we can build

With the opm index inspect command, you can extract the configs from an index, and the use that (instead of the database) to build the index (using a Dockerfile, that we can probably generate as a suggested starting point using something like opm index build --generate). Is that what you're asking for?

The opm index build --configs <config-folder> --tag <image-tag> command will then be for users who do not want to deal with the Dockerfile before they can build their indexes.

(Updated the PR to include the --generate flag)

[anik120]

Also @bparees @cdjohnson we have a story tracking the work for handling some of the pain points of building an image with opm here https://issues.redhat.com/browse/OLM-1843 (not part of the declarative index config epic). We could discuss possibly handling the issues brought up here as a part of that epic.

[cdjohnson]

Also @bparees @cdjohnson we have a story tracking the work for handling some of the pain points of building an image with opm here https://issues.redhat.com/browse/OLM-1843 (not part of the declarative index config epic). We could discuss possibly handling the issues brought up here as a part of that epic.

Us non-redhatters can't see that issue. Can you either make it public, or elevate it to an upstream EP?

[cdjohnson]

@anik120

With the opm index inspect command, you can extract the configs from an index, and the use that (instead of the database) to build the index (using a Dockerfile, that we can probably generate as a suggested starting point using something like opm index build --generate). Is that what you're asking for?

That's fine, as long as opm index build ... --generate option ALSO generates the database.

The sequence of event's I'd like to implement:

1. opm index inspect -c podman --image=docker.io/my-namespace/community-operators --output=json
   • Pulls/Runs/Extracts the index image and converts it to JSON (via podman and registries.conf)
2. Update the JSON index configs:
   • Directly update JSON or
   • opm index add --config
3. Generate the Dockerfile and Database via opm index build --configs <.> --generate
   • Please Confirm this will ALSO build the database. Not just generate a Dockerfile.
4. Copy the database into my own Dockerfile build tree (discard the generated Dockerfile)
   • I need to use my own Dockerfile, since the FROM and BUILDER images may not be correct for my environment, and I may have other customizations.
5. podman build --tag=<new index>
6. podman push <new index> --format v2s2
7. podman manifest create .... if I want manifest lists.

Does that make sense?

Actually: After I wrote this, I re-read the migration section. I didn't realize that the the opm registry serve --config command was being implemented right away and the database is now obsolete in my scenario. I had thought I read a few weeks ago that it was being done in stages to avoid risk. If true, then I just need to know the Dockerfile build directory format so the config files can be correctly copied.

[anik120]

Actually: After I wrote this, I re-read the migration section. I didn't realize that the the opm registry serve --config command was being implemented right away and the database is now obsolete in my scenario. I had thought I read a few weeks ago that it was being done in stages to avoid risk. If true, then I just need to know the Dockerfile build directory format so the config files can be correctly copied.

@cdjohnson that is correct. Once you have the configs you can just copy those in and use opm registry serve --config to serve content and you will not need the database. Regarding

I just need to know the Dockerfile build directory format

We'll have adequate documentation to communicate the correct formats etc.

[openshift-ci-robot]

@anik120: PR needs rebase.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[joelanford]

@anik120 Is there anything from this PR that still needs to make it into this EP? If not, can we just close?