Replies: 2 comments
-
I feel like this is something that should be solved outside of Peering Manager. You don't need to use the scheduled job to push the configurations. You could trigger a CI/CD pipeline or some approval workflow that eventually triggers the push. The pipeline can detect changes that can be auto-approved (i.e prefix list updates), and ones that must require approval. This doesn't seem like something that Peering Manager should try to solve. All the components are there to trigger what you want from an external system. But this is really up to @gmazoyer and the team to figure out if it is something that should be solved with Peering Manager. |
Beta Was this translation helpful? Give feedback.
-
It's really complex to implement this kind of things and I feel it's a bit out of scope. However I think it can be solved by introducing multiple configuration templates per router. We are still not there at implementing it but it's somewhere on the roadmap. In this way, you'll be able to have an automatic task deploying prefix lists but not other kind of configs (for example). |
Beta Was this translation helpful? Give feedback.
-
We have Peering Manager set up with automatic configuration deployment so prefix list changes can be pushed to the router in a timely manner.
Yesterday I was configuring a new peer and wanted to review the configuration difference but was confused because the software was reporting no difference. This of course has been caused by the automatic deploy.
I could have solved this issue by setting the router into maintenance mode, but that feels more like a workaround.
I would therefore like to propose a staging area, that contains all manual edits via the UI, so they will not be affected by the automatic deployment.
Beta Was this translation helpful? Give feedback.
All reactions