nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

About SolidFire Trap Notifications

shuhei

When using SolidFire in Openstack, when a volume is deleted, it is both deleted and purged.
However, when the volume is scheduled to be purged on the Solidfire side, the trap is raised because there is no volume .

Do you have any examples of how you are trying to suppress Trap in such an environment?

Find more posts tagged with

Accepted answers

elementx

> However, when the volume is scheduled to be purged on the Solidfire side, the trap is raised because there is no volume .

Is that trap raised sent by SolidFire SNMP Trap sender? What kind of a trap?

Maybe you are sending traps of all Events, rather than just Cluster Faults?

What are you using to receive traps? If you can filter by event content, you could ignore that specific trap (if it's different from other traps). Some software allows you to filter by trap content, some not. If you trap content isn't unique (and sometimes you want to be notified, other time you don't), then it's impossible to create a filter that would ignore only certain notifications because it's impossible to distinguish them from other notifications with the same content.

All comments

elementx

> However, when the volume is scheduled to be purged on the Solidfire side, the trap is raised because there is no volume .

Is that trap raised sent by SolidFire SNMP Trap sender? What kind of a trap?

Maybe you are sending traps of all Events, rather than just Cluster Faults?

shuhei

The customer wants to see if it is possible to set Trap filtering within SolidFire for a specific volume name or operating user in the Trap configuration.

I am aware that the only way to do this is to filter after sending the Trap, but I was wondering if there was any different workaround.

elementx

Ah, you're asking about SolidFire-side filtering... That's not possible, everything is sent if it's enabled.

That seems quite unusual, IMO, to filter at Source. In any case, it can't be done with SolidFire.

Your choices are probably just two: (a) see if you can filter on the server/agent, or (b) set up a SNMP trap forwarder (e.g. Linux container) where you could filter and drop the trap before forwarding.

In both cases you would have to be able to distinguish the fault or event from events that you normally want to alert on.

> However, when the volume is scheduled to be purged on the Solidfire side, the trap is raised because there is no volume

This sounds strange. If you can send a sample of this to me offline, I'd like to know how this happens.