Start Services/Ingress/Route/... informers lazily about podman-desktop

[benoitf]

hello @feloy could you use the GitHub issue template when filling issues ?

[feloy]

hello @feloy could you use the GitHub issue template when filling issues ?

Yes, sorry, I'll do

[deboer-tim]

Found a bug: we don't clean the resources up after we stop the informer (which is handy if you just lost the connection, esp. temporarily), but when it connects again the same resources are 'new' and reported through onAdd. This is most noticeable if you switch back and forth between contexts, as you'll get duplicates of everything.

I confirmed the issue by adding state.resources.services = state.resources.services.filter(o => o.metadata?.uid !== obj.metadata?.uid); to onUpdate, but if any resources were updated or deleted while it was disconnected they would be in the old state forever. I'm assuming the fix is to use onReachable to reset the array, but haven't tested yet.

[feloy]

Found a bug: we don't clean the resources up after we stop the informer (which is handy if you just lost the connection, esp. temporarily), but when it connects again the same resources are 'new' and reported through onAdd. This is most noticeable if you switch back and forth between contexts, as you'll get duplicates of everything.

I confirmed the issue by adding state.resources.services = state.resources.services.filter(o => o.metadata?.uid !== obj.metadata?.uid); to onUpdate, but if any resources were updated or deleted while it was disconnected they would be in the old state forever. I'm assuming the fix is to use onReachable to reset the array, but haven't tested yet.

This bug/feature was on purpose because on my side, I was seeing that the resources were not 'added' again when reconnecting the informer. I think it depends on the activity on the context; if the objects are not modified, it seems to me that the informers are expecting some local cache. I would use for add the same technique as for update, to remove the old resource with the same uid if it exists

[deboer-tim]

Yes, that definitely works and is a quick/safe fix, I just want to confirm that if something is deleted while disconnected we get a delete event/clean up correctly.

I can't verify this as I'm also hitting a second problem: if you are watching services in one context and then switch current context, it doesn't automatically start the new informer; if you are watching and switch current context and switch back, you have cached data that is no longer updated. Still trying to figure out exactly what's happening.

[feloy]

I can't verify this as I'm also hitting a second problem: if you are watching services in one context and then switch current context, it doesn't automatically start the new informer; if you are watching and switch current context and switch back, you have cached data that is no longer updated. Still trying to figure out exactly what's happening.

Oh, you are right. Because the services informer is started only when the store is started, so if you are on a page using this store, and you switch the context from the status bar (without quitting the page), the informer will be stopped because of the context switch, but won't be restarted, because the store is not restarted.

This means that we will need to add some subscription system (a store subscribes when it starts, and unsubscribes when it stops), so when the context is switched, if there are some subscription, we can start immediately the services informer

For your tests, as a workaround, you can select another page then go back to the Services page, and the informer should be restarted again and resources should be updated correctly again.

[feloy]

Yes, that definitely works and is a quick/safe fix, I just want to confirm that if something is deleted while disconnected we get a delete event/clean up correctly.

I have made some tests, and no events are received for a resource deleted during the non-connected time.

This issue tracks the problem, it has been closed after no activity, but could be reopened if we can qualify the bug: kubernetes-client/javascript#795

I'll work on creating a simple and reproducible case.

[feloy]

Yes, that definitely works and is a quick/safe fix, I just want to confirm that if something is deleted while disconnected we get a delete event/clean up correctly.

I have made some tests, and no events are received for a resource deleted during the non-connected time.

This issue tracks the problem, it has been closed after no activity, but could be reopened if we can qualify the bug: kubernetes-client/javascript#795

I'll work on creating a simple and reproducible case.

Here is a simple test: https://github.com/feloy/informer-test

From what I understand from it:

• if we stop()/start() the informer (without recreating it), we receive events for modified resource when the informer is stopped then restarted
• if the informer is stopped, recreated and started, we receive all events again, for all resources (not taken care of what we received with the first informer).

So, for the services, we have to delete the cached services, as the informer will be recreated again every time we connect, but for the pods/deployments informers, it is a little different, as we are not recreating it again on disconnection, but we are just restarting it.

[feloy]

#6250 should fix the issue of services in double when reconnecting

[feloy]

Closing, as tracked by #6259