-
Story
-
Resolution: Done
-
Undefined
-
None
-
None
The current `opm alpha add` command combines three functions into one:
1. Extract bundle image and format as declarative config olm.bundle blob
2. Insert the blob into the existing declarative config
3. Write out the updated declarative config
Combining these steps poses several potential problems.
1. It makes it hard to support users if this exact workflow breaks down for their use case (they would need a patched version of opm)
2. It is very opinionated, leaving users little room for adjustments and flexibility.
3. It becomes more difficult to maintain as users request custom features to be inserted that they could otherwise handle themselves if the process were decomposed.
4. The updated declarative config directory may be missing important non-declarative config files found in the original (e.g. `.git`)
One idea for a decomposed workflow that has been proposed is:
1. opm blob quay.io/hello/my-bundle:latest > my-bundle.json
2. mv my-bundle.json configs/hello/
3. ./my-custom-graphifier configs/hello
3. opm validate configs
4. opm fmt configs
AC:
1. Draft and post an enhancement proposal to operator-framework/enhancements that documents a decomposed bundle add workflow
2. Include example workflows or scripts that personas might use with this decomposed workflow
- operator author
- pipeline maintainer
- freshmaker
- cluster admin
3. Document pros and cons of decomposed workflow vs all-in-one command.
4. A working prototype that defines this behavior and can be reviewed by the group.
- is related to
-
OPRUN-2199 DC commands to generate supported blobs
- Closed