search

inex / IXP-Manager

Full stack web application powering peering at over 200 Internet Exchange Points (IXPs) globally.
https://www.ixpmanager.org/
GNU General Public License v2.0
361 stars 158 forks source link

Please make 'Awaiting XConnect' ports appear in '/api/v4/provisioner/layer2interfaces' #780

Open ichilton opened 2 years ago

ichilton commented 2 years ago

Currently, ports marked 'Awaiting XConnect' are not included in the /api/v4/provisioner/layer2interfaces API response.

Please could they be included? - once we've allocated the switch port, we want to reserve it on the device by setting the description, so our automation needs to see the port in the data.

nickhilliard commented 2 years ago

This was a deliberate implementation choice:

https://github.com/inex/IXP-Manager/blob/master/app/Tasks/Yaml/SwitchConfigurationGenerator.php#L97-L100

Probably this should be viewed as a workflow choice with some form of config mechanism to allow / disallow these objects appearing in the provisioner output.

ichilton commented 2 years ago

but surely the automation should decide that from the available data?

If your workflow is such that you don't configure the interfaces for awaiting x-connect ports, you just ignore interfaces with that status with {% if iface.status != 'awaiting-xconnect' %} or whatever.

For us, we want to set a description on those ports, so it's allocated/visible on the switch.

nickhilliard commented 2 years ago

but surely the automation should decide that from the available data?

There are some architectural conflicts going on here, which are difficult to resolve. On the one hand, automation using APIs and template languages are supposed to be handled on the basis that the complexity is handled in the controller, so that the template can be as dumb as possible. Templating languages reflect this design methodology and are generally fairly simple + don't have the types of linguistic constructions that general purpose programming languages have. Jinja2 is a good example of this.

This works fine until you hit the real world. In the case of IXP Manager, the API needs to: 1. encode the minimum of data that you need to unambiguously describe the data model that you're dealing with, 2. be generic enough to cope with the requirements of lots of different data consumers and 3. be specific enough to cope with the requirements of different data consumers.

There are various approaches you can take to achieve this end. IXP Manager chose one, which was to code a reasonable set of data in a specific way but be inflexible about what's presented. Another - more advanced - approach would have been to create a filter mechanism on the API using either urlparams or POST data so that the consumer could select what data to receive. Good examples of this would be the Netbox or Equinix APIs.

Hopefully this explains why the API was written in the way it was written.

That said, maybe exposing awaiting cross-connect physical interfaces would work and the api consumer side can make a decision. The token is already defined as "awaitingxconnect":

https://github.com/inex/IXP-Manager/blob/master/app/Models/PhysicalInterface.php#L143

listerr commented 2 years ago

Another - more advanced - approach would have been to create a filter mechanism on the API using either urlparams or POST data so that the consumer could select what data to receive. Good examples of this would be the Netbox or Equinix APIs.

See also: https://github.com/listerr/ixpm-connections-json