|
| 1 | +--- |
| 2 | +title: opm-package-pruning |
| 3 | +authors: |
| 4 | + - "@djzager" |
| 5 | +reviewers: |
| 6 | + - TBD |
| 7 | +approvers: |
| 8 | + - TBD |
| 9 | +creation-date: 2020-04-03 |
| 10 | +last-updated: 2020-04-03 |
| 11 | +status: implementable |
| 12 | +--- |
| 13 | + |
| 14 | +# OPM Package Pruning |
| 15 | + |
| 16 | +## Release Signoff Checklist |
| 17 | + |
| 18 | +- [ ] Enhancement is `implementable` |
| 19 | +- [ ] Design details are appropriately documented from clear requirements |
| 20 | +- [ ] Test plan is defined |
| 21 | +- [ ] Graduation criteria for dev preview, tech preview, GA |
| 22 | + |
| 23 | +## Summary |
| 24 | + |
| 25 | +Add support to the `opm` command line utility to prune operators from an |
| 26 | +operator index (or registry). This enables consumers of operator indexes to take |
| 27 | +an existing, and presumably large, index and generate a new index with only the |
| 28 | +operators they wish to make available in the catalog. In short, this is the |
| 29 | +inverse of `opm (index|registry) rm` where you select which operators to remove, |
| 30 | +`opm (index|registry) prune` allows you to select the operators to keep. |
| 31 | + |
| 32 | +## Motivation |
| 33 | + |
| 34 | +As Operator adoption expands and OLM usage increases the index images used to |
| 35 | +make operator catalogs available to OLM will grow. Cluster administrators |
| 36 | +__should__ have a way to curate operator catalogs. This feature provides a basic |
| 37 | +mechanism for catalog curation. |
| 38 | + |
| 39 | +### Goals |
| 40 | + |
| 41 | +- Allow `opm` user to select operators to keep from an existing registry or |
| 42 | + index image. |
| 43 | + |
| 44 | +### Non-Goals |
| 45 | + |
| 46 | +- Manipulate the available channels of any operator in the registry or index |
| 47 | + image. |
| 48 | + |
| 49 | +## Proposal |
| 50 | + |
| 51 | +### Prune Subcommand |
| 52 | + |
| 53 | +Adding the `prune` subcommand to the `index` and `registry` command provides a |
| 54 | +simple mechanism for selecting operators to keep from an index image or a |
| 55 | +registry database (depending on the root command). |
| 56 | + |
| 57 | +### User Story |
| 58 | + |
| 59 | +#### Pruning an Existing Operator Catalog |
| 60 | + |
| 61 | +As a cluster administrator, Billy knows what operators from an existing operator |
| 62 | +index he wants to make available to his cluster's users. Billy can build a new |
| 63 | +operator index by selecting operators from the previous index to keep. |
| 64 | + |
| 65 | +### Implementation Details |
| 66 | + |
| 67 | +#### New Commands |
| 68 | + |
| 69 | +A `prune` subcommand will be added to both the `index` and `registry` command |
| 70 | +mimmicking the behavior of `rm` in all but one significant way. The `packages` |
| 71 | +flag will represent the packages to be kept in the index or registry. |
| 72 | + |
| 73 | +## Design Details |
| 74 | + |
| 75 | +### Test Plan |
| 76 | + |
| 77 | +e2e tests will be added alongside existing tests for the `opm` tool verifying |
| 78 | +the ability to prune an index. |
0 commit comments