Steve Kuznetsov

@omissis are you still maintaining this project? Do you have any feedback on this proposal?

@omissis sorry to be a nag - I really would like to not have a long-lived fork for this project, are you able to chime in on this proposal?

Yeah sorry @r1tsuu I don't believe there were any other steps necessary to reproduce this.

The crux of the question here is - we're unpacking an index and get a filesystem out of it. We'd like to serve the content from that FBC filesystem as-is....

Is it possible for a user to rely on that side-effect of the implementation of today's FBC images? Who consumes other than OLM servers? What's the implication of "breaking" that?

You wrote: > a breaking change in the FBC spec I am asking - it's "breaking" in the sense that it changed, but would it be possible for a user...

Logs for any workspace under the org, for reconcilers: ``` kcp-apibinder-initializer kcp-apibinding kcp-apibindingdeletion kcp-apiexport kcp-permissionclaimlabel kcp-resource-permissionclaimlabel kcp-virtual-apiexport-api-reconciler ``` [kcp.log](https://github.com/kcp-dev/kcp/files/9869497/kcp.log)

Logs for controllers interacting with the APIBinding and APIExport in `root:e2e-org-p2l7n:workspace1`: kcp.log ``` 09:59:48.366700 30606 apiexport_apireconciler_controller.go:172] "queueing APIExport" reconciler="kcp-virtual-apiexport-api-reconciler" key="root:e2e-org-p2l7n:workspace1|export1" 09:59:48.366853 30606 apiexport_apireconciler_controller.go:220] "processing key" reconciler="kcp-virtual-apiexport-api-reconciler" key="root:e2e-org-p2l7n:workspace1|export1" 09:59:48.366921 30606 apiexport_apireconciler_reconcile.go:53]...

@ncdc looks like it's `expected=map[] unexpected=map[] toApply=map[] toRemove=map[] all=map[]` every time :facepalm:

We've got the test clearing the accepted claims from spec: ``` $ grep -h 6dcf1a1f-3aa2-4d9e-af24-b96006926f7c e2e-sharded/sharded/artifacts/audit-* | jq .requestObject { "spec": { "permissionClaims": null } } ``` Then, the responses...