Is there any plan to support other sourceType?

[zhhray]

Is there any plan to support sourceType as grpc or https like olm v0, by providing address, to provide packages content to catalog?

[anik120]

@zhhray some of these v0 semantics were born out of unavoidable circumstances that we're trying to avoid porting over to v1. What is your exact use case? Could you elaborate a little more on why it isn't enough to take your FBC, and pack that into a container image?

[zhhray]

@zhhray some of these v0 semantics were born out of unavoidable circumstances that we're trying to avoid porting over to v1. What is your exact use case? Could you elaborate a little more on why it isn't enough to take your FBC, and pack that into a container image?

Our requirement is that different operators can be managed and published separately, and we do not expect to store multiple operators in the same index image, because the iteration frequency of each operator version is different, and we do not want that when there is an operator version change, we'll have to rebuild an index image, which is not the expected behavior.

[zhhray]

I'm confident that users will be able to maintain their own custom catalog backend based on the FBC api, not just the index image.

[joelanford]

@zhhray there's no specific plan to add more source types, but the API design does leave that possibility open.

There are a few things we're looking at doing to make your use case (which I think is actually extremely common) easier:

1. Build better tooling to make "we'll have to rebuild an index image" less of an issue
2. Make it possible in the ClusterExtension API to install a bundle directly, no need for a catalog at all (though that option obviously wouldn't have automatic updates)
3. Potentially add more source types here, such that FBC (or other formats convertible to FBC) could be referenced and sourced via other protocols.

Proposals are definitely welcome!