Test against multiple versions of operator-courier.

[ralphbean]

This will let us test against the currently released version of operator
courier on pypi, as well as whatever they have cooking in their master branch.

An upcoming release (2.0.0) is going to have a small break in backwards
compatibility, handled here.

[kevinrizza]

I want to point out that this will only work in the flat directory case. In the operator-registry manifest format, we don't return anything on this field.

[ralphbean]

Ack - @kevinrizza can you recommend an approach that will handle both cases?

[ralphbean]

Ah, here we're always calling _flatten_manifest_structure before accessing the bundle (up in omps/api/v1/push.py).

[kevinrizza]

If you are only accessing this after flattening it, it should work. But I still want to recommend that we find an alternative solution to finding the package name here (which I assume is the reason you are accessing this bundle data?). I want to caution that there is no guarantee that in future iterations that concept will always exist, and being able to generate the name based on some metadata associated with the build or repository is going to become necessary at some point most likely

[csomh]

Could py{36,37}-courier_released,flake8} be the default envlist, and *-courier_master be available only through tox -e? All this in order to lower test execution time while developing and calling tox locally. Travis will run all the flavors in the end.

[ralphbean]

Yes, although - I'm not sure how to accomplish that in a tox.ini config.

[csomh]

Suggested change

	envlist = py{36,37}-courier_{released,master},flake8
	envlist = py{36,37}-courier_released,flake8

Will do the job, but README.md will need an update to document that tox -e 'py{36,37}-courier_master' can be used to test with the latest version of Operator Courier. This is required, b/c tox -l and tox -a will not list these environments.

[ralphbean]

Ack - should be fixed.

[MartinBasti]

Yes, packageName is reason why we are accessing bundle. I'm open to suggestions how to do that in a better way.

[kevinrizza]

Yes, packageName is reason why we are accessing bundle. I'm open to suggestions how to do that in a better way.

@MartinBasti @ralphbean

Yes, and this is what I have been pointing out and arguing for a while. The fact that it is possible for the Courier to return this data is orthogonal to the objective of Courier -- the fact that it is needed at all is tech debt that all of us should be working on to eliminate. In the future (hopefully soon) it will not even be a requirement that the package name in the package.yaml has to match the repository name in the registry. When a build system builds a docker image, there is nothing in that dockerfile that guides the name of the image it is building. The same concept should exist here.

Right now, since we have no such infrastructure in our build system in place we should be doing two things:

1. Exploring how we can get to a state where the metadata in the yaml doesn't guide the repository name.

2. In the meantime, you can do something like parse the package.yaml file at runtime and extract the packageName field from it.

I do not believe the courier should return something like this as part of its apis, and the fact that it did previously is an implementation detail.

[MartinBasti]

@kevinrizza because format of operators metadata is still not clear, I'd postpone this discussion. We still support v1 API that doesn't care about packageName, so if operators won't have packageName but explicit repository name, OMPS still support this use case.