Background: This concern was raised during the review of PR #5333 in this comment: https://github.com/openshift/machine-config-operator/pull/5333#discussion_r2408616988

Problem: The current implementation uses GetPoolsForNode for PinnedImageSet (PIS) detection. This function implies an inheritance model similar to how MachineConfigs are handled, where a custom pool (e.g., an infra node pool) might be considered a "worker" for the purpose of PIS.

This can lead to unintended behavior. For example, a custom pool might inherit and pull PinnedImageSets from the base worker pool, even if it has its own distinct image requirements or no PIS needs at all. This is especially problematic if the custom pool uses a different base image, as it could result in pulling unnecessary or conflicting images.

Questions to Investigate:

1. Is this inheritance model for PinnedImageSets intentional?

1. What is the expected workflow for a custom pool that requires a different set of PinnedImageSets than the main worker pool?

1. Should the logic be adjusted to prevent custom pools from automatically inheriting PIS from their base pools?

This behavior is not causing an immediate bug but could lead to confusion and unexpected resource consumption. We should clarify the intended design and adjust the implementation if necessary.