opm: Adding bundle to registry with new channel fails and deletes previous bundles

[cdjohnson]

Using opm 1.5.11

I'm trying to create a scenario where I add a second channel to a registry:

Version	Replaces	Default Channel	Channels
1.0.0		BETA	BETA
1.0.1	1.0.0	STABLE	BETA,STABLE

Commands in order:

1. operator-sdk bundle create quay.io/cdjohnson/testoperator:v1.0.0 --directory ../deploy/olm-catalog/testoperator/1.0.0 --package test-operator --channels BETA --default-channel BETA
2. docker push quay.io/cdjohnson/testoperator:v1.0.0
3. opm registry add -b quay.io/cdjohnson/testoperator:v1.0.0 -c docker

The bundles.db shows:
--channel-entry--
BETA|test-operator|testoperator.v1.0.0
1|BETA|test-operator|testoperator.v1.0.0||0
--operatorbundle--
testoperator.v1.0.0|quay.io/cdjohnson/testoperator:v1.0.0

4. operator-sdk bundle create quay.io/cdjohnson/testoperator:v1.0.1 --directory ../deploy/olm-catalog/testoperator/1.0.1 --package test-operator --channels BETA,STABLE --default-channel BETA
5. docker push quay.io/cdjohnson/testoperator:v1.0.1
6. opm registry add -b quay.io/cdjohnson/testoperator:v1.0.1 -c docker

INFO[0000] adding to the registry                        bundles="[quay.io/cdjohnson/testoperator:v1.0.1]"
DEBU[0000] couldn't rollback - this is expected if the transaction committed  error="sql: transaction has already been committed or rolled back"
INFO[0000] running docker pull                           img="quay.io/cdjohnson/testoperator:v1.0.1"
DEBU[0000] [docker pull quay.io/cdjohnson/testoperator:v1.0.1]  img="quay.io/cdjohnson/testoperator:v1.0.1"
INFO[0001] running docker save                           img="quay.io/cdjohnson/testoperator:v1.0.1"
DEBU[0001] [docker save quay.io/cdjohnson/testoperator:v1.0.1 -o bundle_staging_537743893/bundle.tar]  img="quay.io/cdjohnson/testoperator:v1.0.1"
INFO[0001] loading Bundle quay.io/cdjohnson/testoperator:v1.0.1  img="quay.io/cdjohnson/testoperator:v1.0.1"
INFO[0001] found annotations file searching for csv      dir=bundle_tmp016250894 file=bundle_tmp016250894/metadata load=annotations
INFO[0001] found csv, loading bundle                     dir=bundle_tmp016250894 file=bundle_tmp016250894/manifests load=bundle
INFO[0001] loading bundle file                           dir=bundle_tmp016250894/manifests file=testoperator.v1.0.1.clusterserviceversion.yaml load=bundle
FATA[0001] permissive mode disabled                      bundles="[quay.io/cdjohnson/testoperator:v1.0.1]" error="error loading bundle from image: Error adding package error loading bundle into db: testoperator.v1.0.1 specifies a replacement testoperator.v1.0.0 that cannot be found"

The bundles.db shows:
--channel-entry--
--operatorbundle--
testoperator.v1.0.0|quay.io/cdjohnson/testoperator:v1.0.0

CSV Files:
bundles.tar.zip

[cdjohnson]

This fails in similar ways when adding a new channel in any form:

Version	Replaces	Channels	Default Channel
1.0.0		BETA	BETA
1.0.1		STABLE	STABLE

Version	Replaces	Channels	Default Channel
1.0.0		BETA	BETA
1.0.1	1.0.0	BETA	BETA,STABLE

[shawn-hurley]

@cdjohnson

I am failing to see the issue.

sqlite> select * from channel;
name|package_name|head_operatorbundle_name
BETA|test-operator|testoperator.v1.0.1
STABLE|test-operator|testoperator.v1.0.1

entry_id|channel_name|package_name|operatorbundle_name|replaces|depth
1|BETA|test-operator|testoperator.v1.0.1|2|0
2|BETA|test-operator|testoperator.v1.0.0||1
3|STABLE|test-operator|testoperator.v1.0.1|4|0
4|STABLE|test-operator|testoperator.v1.0.0||1

This appears to me to be what we would expect based on the bundle add commands above.

[shawn-hurley]

It appears that an older version may have had an errant default with the registry add command where it did not re-use the bundles.db. This seems to be fixed in a newer version of opm.

[cdjohnson]

@shawn-hurley I can still recreate with 1.6.1 for mac:
https://github.com/operator-framework/operator-registry/releases/tag/v1.6.1

Are you using a custom build?

Are you using the right parameters for steps 1 and 4? I wouldn't have expected v1.0.0 to be in the STABLE channel.

[jeyaramashok]

I tried with code from master, I see the same issue.

scenario from table1 in Chris #205 (comment)

1. Add a package (channel: beta, verison: 1.0.0) - works

entry_id    channel_name  package_name   operatorbundle_name  replaces    depth
----------  ------------  -------------  -------------------  ----------  ----------
1           BETA          test-operator  testoperator.v1.0.0              0

2. Add a package (channel: stable, version: 1.0.1, replaces: 1.0.0) - fails with:

"testoperator.v1.0.1 specifies a replacement testoperator.v1.0.0 that cannot be found"

It's not allowing to specify a upgrade path of (stable,1.0.1) <- (beta,1.0.0)

[cdjohnson]

Chatted with @shawn-hurley and he was able to recreate.

[cdjohnson]

@shawn-hurley @ecordell I built opm from PR #236 and am definitely getting further.

However, I'm seeing some graph oddities, that I wasn't expecting.

Let's say I run opm registry add with a bundle with the following CSV version and skipRange attributes, and bundle attributes in the specified order and dump the tables in the index.db:

ver	skipRange	channels	defaultChannel
1.0.0		V1.0	V1.0
1.0.1	<1.0.1	V1.0	V1.0

--channel--
V1.0|test-operator|testoperator.v1.0.1
--channel-entry--
1|V1.0|test-operator|testoperator.v1.0.1||0
--operatorbundle--
testoperator.v1.0.0|localhost:5000/cdjohnson/testoperator:v1.0.0
testoperator.v1.0.1|localhost:5000/cdjohnson/testoperator:v1.0.1

Bridge to a new v1.1 channel which is coming next. This looks as expected:

ver	skipRange	channels	defaultChannel
1.0.2	<1.0.2	V1.0,V1.1	V1.0

--channel--
V1.0|test-operator|testoperator.v1.0.2
V1.1|test-operator|testoperator.v1.0.2
--channel-entry--
1|V1.0|test-operator|testoperator.v1.0.2||0
2|V1.1|test-operator|testoperator.v1.0.2||0
--operatorbundle--
testoperator.v1.0.0|localhost:5000/cdjohnson/testoperator:v1.0.0
testoperator.v1.0.1|localhost:5000/cdjohnson/testoperator:v1.0.1
testoperator.v1.0.2|localhost:5000/cdjohnson/testoperator:v1.0.2

Now, I want to add a new 1.1.0 version, which I don't want to to be included in the v1.0 channel

ver	skipRange	channels	defaultChannel
1.1.0	>=1.0.2 <1.1.0	V1.1	V1.1

This REMOVED the V1.0 channel, which I don't want removed.
I also don't want 1.1.0 to be added to the V1.0 channel.

--channel--
V1.1|test-operator|testoperator.v1.1.0
--channel-entry--
1|V1.1|test-operator|testoperator.v1.1.0||0
--operatorbundle--
testoperator.v1.0.0|localhost:5000/cdjohnson/testoperator:v1.0.0
testoperator.v1.0.1|localhost:5000/cdjohnson/testoperator:v1.0.1
testoperator.v1.0.2|localhost:5000/cdjohnson/testoperator:v1.0.2
testoperator.v1.1.0|localhost:5000/cdjohnson/testoperator:v1.1.0

What's the proper sequence of skipRange and channels to achieve a V1.0 and V1.1 channel with a select set of bridge versions to achieve this?:

--channel--
V1.0|test-operator|testoperator.v1.0.2
V1.1|test-operator|testoperator.v1.1.0
--channel-entry--
1|V1.0|test-operator|testoperator.v1.0.2||0
2|V1.1|test-operator|testoperator.v1.1||0
--operatorbundle--
testoperator.v1.0.0|localhost:5000/cdjohnson/testoperator:v1.0.0
testoperator.v1.0.1|localhost:5000/cdjohnson/testoperator:v1.0.1
testoperator.v1.0.2|localhost:5000/cdjohnson/testoperator:v1.0.2
testoperator.v1.1.0|localhost:5000/cdjohnson/testoperator:v1.1.0

I've built a little test framework to test out adhoc graph scenarios.
You can see here, what I'm up to. Feel free to use it in your own testing. Maybe I have a bug, but it doesn't look like it.

[cdjohnson]

This appears to be somewhat fixed in 1.7. I've opened #258 as a follow-up.