Platform Clustering (S1NPM-109893 / S1NPM-110145) — Request: Configurable SelfMon Cluster Member Auto‑Discovery (Enable/Disable Toggle)

Hello Ryan,

Please find my answers:

Are these net new peers you're adding to a cluster, or are you taking a base image and doing an HSA add to replace a retired node?
Answer These are not net-new peers. They are existing cluster members that have been part of the cluster for some time but were not onboarded as regular SevOne devices for Self-Monitoring.

Since upgrading to SevOne 7.x, cluster appliances that were not previously onboarded as regular devices are automatically created shortly after the upgrade. We see the same behavior when an appliance is added as a cluster member before it is onboarded through our standard process.

Our internal onboarding system, Telemetry Portal, uses the SevOne API to manage and track device additions, removals, and modifications. It also applies the metadata required for alerting, monitoring, ownership, and operational workflows.

When SelfMon automatically creates the device:

• SevOne reports that the device already exists.

• Telemetry Portal has no corresponding onboarding record.

• Required metadata has not been applied.

• Telemetry Portal cannot onboard the device because its duplicate-device validation correctly detects that it already exists in SevOne.

• If we remove the automatically created device, SelfMon recreates it within approximately 15 seconds.

This leaves SevOne and Telemetry Portal in an inconsistent state and prevents us from completing the controlled onboarding workflow.

Do you delete self-monitoring devices and re-create them with your PAVE/REPAVE functions? I'm trying to figure out why new SelfMon devices are created in the first place.

Answer: Our automation uses a controlled sequence to remove, rebuild, validate, and onboard an appliance. Device creation and metadata assignment are expected to occur through Telemetry Portal at the appropriate step.

The new device is not intentionally created by our PAVE/REPAVE automation. It is automatically created by SelfMon when the appliance is detected as a cluster member. If we delete that automatically created device so that Telemetry Portal can onboard it correctly, SelfMon recreates it before our workflow can complete.

What prevents devices added by other means from blocking the repave automation?
Answer: Telemetry Portal is the authoritative onboarding path for our environment. It maintains the workflow state and applies the required metadata. Devices created outside that process do not have the corresponding Telemetry Portal record or metadata.

The automation checks SevOne before adding a device. If a device already exists, it stops rather than modifying or taking ownership of a device that it did not create. This safeguard prevents duplicate or destructive actions, but it also means that a SelfMon-created device blocks the normal onboarding process.

Is the problem that the new SelfMon device is in the queue for first discovery, or that its active discovery blocks your automation from working properly due to device locks?

Answer: The primary issue is the automatic creation of the regular device record before our onboarding step. That alone causes the duplicate-device validation to fail.

Discovery activity or device locks may introduce additional timing issues, but they are not the fundamental problem. Even if discovery completes successfully, the device still exists outside Telemetry Portal and lacks the required metadata and workflow record.

If it were possible to cancel all running discoveries and prevent new discoveries from starting until discovery was re-enabled, would this help?

Answer: No. Telemetry Portal must explicitly request the device onboarding and creation. However, the SelfMon-created device does not appear in the normal discovery queue, so there is no discovery job that we can identify, pause, or cancel to prevent its creation.

Additionally, canceling all running discoveries would disrupt normal operations by stopping unrelated device discoveries across the environment. That would introduce unnecessary impact without addressing the underlying SelfMon behavior.

What we need is a targeted, supported control that temporarily disables SelfMon cluster-member auto-creation, without affecting normal discovery activity for unrelated devices.

If there are any other mechanistic details you can share about how device discovery or the new SelfMon device creation blocks your automation, please do.
Answer: The issue is not caused by a normal discovery job. The SelfMon process automatically creates the cluster member as a regular SevOne device outside the standard discovery queue.

Our onboarding flow works as follows:

1. Telemetry Portal requests device creation through the SevOne API.

2. Before creating it, Telemetry Portal checks whether the device already exists.

3. SelfMon has already created the device, so SevOne returns it as an existing device.

4. Telemetry Portal stops the onboarding to prevent duplicates or unintended modifications.

5. The SelfMon-created device has no corresponding Telemetry Portal record and is missing the metadata required for ownership, alerting, and monitoring.

6. If we delete the device to allow controlled onboarding, SelfMon recreates it within approximately 15 seconds.

Because this creation is not represented as a standard discovery task, we cannot selectively identify, pause, or cancel it. We need a supported control specifically for SelfMon cluster-member auto-creation, without affecting unrelated discoveries or normal monitoring operations.

Let me know if you have further questions and if you prefer to do a zoom session to explain it better.

Kind regards,

Nicolas.

JPMC team, any feedback on the clarifying questions asked by @Ryan Wilson here ?

Nicolas, I'd like to explore alternative solutions because I'd prefer to avoid enabling users to turn off automatic SelfMon device creation.

Here's some follow-up questions aimed at better understanding:

• Are these net new peers you're adding to a cluster, or are you taking a base image and doing an HSA add to replace a retired node?

• Do you delete self-monitoring devices and re-create them with your PAVE/REPAVE functions? I'm trying to figure out why new SelfMon devices are created in the first place.

• What prevents devices added by other means from blocking the repave automation?

• Is the problem that the new SelfMon device is in the queue for first discovery, or that its active discovery blocks your automation from working properly due to device locks?

• If it were possible to cancel all running discoveries and prevent new discoveries from starting until discovery was re-enabled, would this help?

• If there are any other mechanistic details you can share about how device discovery or the new SelfMon device creation blocks your automation, please do.

I'm also open to chatting via a video call if you feel that would be more productive.

Ryan Wilson

Senior Product Manager, IBM SevOne

ryan.wilson4@ibm.com