Open zhhray opened 3 weeks ago
@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 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.
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.
@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:
Proposals are definitely welcome!
Is there any plan to support sourceType as
grpc
orhttps
like olm v0, by providingaddress
, to provide packages content to catalog?