operator-framework / catalogd

On-cluster FBC catalog content server
Apache License 2.0
16 stars 32 forks source link

Design: think about how to handle icon data in catalogd APIs #55

Closed joelanford closed 12 months ago

joelanford commented 1 year ago

See: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/contributors/design-proposals/operator-logos.md

anik120 commented 1 year ago

I like the ideas discussed in that doc. It'll be beneficial to reduce burden for on-cluster components, but I'm curious, is there no better mechanisms today to communicate images other than base64 encoded data for those images? Even when I'm looking at fbc files from a catalog author's perspective, they're clunky. That with the olm.bundle.object combined together made it extremely hard for me to scroll through fbc metadata and made me think that the file is mostly encoded data (I.e it made it hard for me to focus on the actual metadata).

everettraven commented 1 year ago

@joelanford is this still relevant? Now we store this in the filesystem and this information is served over HTTP along with the rest of the catalog contents

joelanford commented 12 months ago

It's probably reasonable to close this now that catalogd is just serving the FBC directly.

I do think there's still something to think about here, but in my mind, that something is related to OCI artifacts and I'd imagine that if/when we start thinking about that possibility more, we'll have this aspect covered anyway.