"session | inherited_status" does not inherit from device level status

[falz]

Peering Manager version

1.7.4

Python version

3.8

Steps to Reproduce

We're using {%- if session | inherited_status == "maintenance" %} in our code on peering sessions that are on IX's and BGP groups.

1. set a device status to Disabled or Maintenance
2. Leave the IX or BGP group and peer at enabled.
3. In jinja at peer level, {{ session | inherited_status }} will always be enabled

Expected Behavior

We expect the peer to inherit inherited_status from device, group, ix, and peer level.

Observed Behavior

inherited_status does not inherit from device level. It does from group, ix, and peer levels

Our use case is these at all levels

• enabled = production
• maintenance = drain traffic - reject prefixes, but dont kill sessions
• disabled = shut down peering sessions with rfc8203 notification method

Workflow will be

• set to status maintenance, push config, wiat until traffic drained
• set to status to disabled to shut down
• do the maintenance

If we can set an entire device status and have it affect peers, this is much simpler. Curious if others use this workflow and have any reason device status shouldn't trickle to a peer status?

[falz]

I have been informed that setting a device type to 'disabled' means that peering-manager won't push configs to it at all. This doesn't jive with my proposed workflow on the device level.

It would be useful to have more than 3 statuses, perhaps? Splitting maintenance into two options, indicating pre and post maintenance. It would of course be up to the operator / template writer to choose the real activities

• pre maintenance - some activity would be done to drain traffic - this may be sending GRACEFUL_SHUTDOWN comm, rejecting prefixes, etc
• actual maintenance - Sessions down in some way

Comment from 2020 here talking about this slightly #292 (comment)

The new status would IMO be pre-maintenance, so something like

• drain
• depref
• pre-maintenance

This would indicate you're doing some activity to offload traffic prior to maintenance.

The confusing part here is that the same 'status' field is available at all object levels, but acts differently when the device itsself is in maintenance.

I can absolutely live with the device status not being inherited, it just adds a few more clicks to put each peer group / IX into maintenance manually, but the addition of a new status type for those would be super keen.