Declarative index config

Design 1

etcd ├── bundle.json └── etcd.json └── package.json

Pros:

Bundle metadata is separate from update graphs. Easier for user to consume cognitively, therefore easier to edit.
Update graph is explicit

Cons:

Bundle identity in update graph. Question: Does changing the nodes in the graph to contain bundle version for each channel instead of bundle image help alleviate concerns for this issue?
Editing update graph may need to followed up with editing bundle.json, potentially leading to mismatched information that users of the config will have to fix.

Design 2

etcd-alternative.json

What's different from design 1?

All information about the package consolidated in a single etcd.json file
Update edge in a channel is represented by: bundles[]["channels"][]["upgradeInfo"]["isReplacedBy"] -> bundle name
How does skip and skiprange work?

When a bundle is added that mentions skips or skipsrange, the metadata for skips is stored in the bundle.channels object, and existing bundles with channel+versions that's mentioned in skips/skipsrange is edited to replace it's value of bundle.channels[channel].isReplacedBy to the new bundle. When a new bundle is added, config needs to be searched for the presence of skips and skiprange in other bundles' metadata to see if the new bundle falls in the skips/skipsrange list of bundles previously added.

Cons:
- Heavy dependence on tooling. Might lead to a surge in request for opm to support different actions, the very thing we were trying to solve in the first place.
Pros:
- Solves the issue of bundle identity in the update graph of design 1 (?)

Note: In the channels objects

"channels": [
                {
                    "name": "clusterwide-alpha",
                     //"skiprange": >=0.9.0 <0.9.2  // an example of skiprange if skiprange was specified for this bundle
                    // "skips" : v0.12.2, v0.14.1  // an example of skips if skips was specified for this bundle
                    "upgradeInfo": {
                        "isReplacedBy": "etcdoperator.v0.9.4-clusterwide",
                    }
                }
            ]

An alternate approach to store the replaces information is to store it the way it's mentioned in the CSV, i.e store "replaces" for bundle it's mentioned in, instead of storing "isReplacedBy" for the bundle it replaces.

Using isReplacedBy seems like the more efficient way to store it in terms of answering the question "I have bundle x currently installed, what is the next upgrade from bundle x" since it's an O(1) operation vs storing replaces which is an O(n) operation.

Using isReplacedBy also seems like it can reduce the cognitive load for a human being reading the file too by just following bundlename.isReplacedBy -> bundleName.isReplacesBy -> ....

anik120 / etcd

Declarative index config

Design 1

Design 2

About