Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NAV Api shows no LAG information #1765

Closed
Jin42 opened this issue Aug 29, 2018 · 4 comments · Fixed by #2440
Closed

NAV Api shows no LAG information #1765

Jin42 opened this issue Aug 29, 2018 · 4 comments · Fixed by #2440
Assignees
Labels
api enhancement good first issue Needs no networking experience and is assumedly small
Milestone

Comments

@Jin42
Copy link

Jin42 commented Aug 29, 2018

I tried to get information per API, which physical ports are part of an logical port, but I couldn´t find a way to get that information from the API.

@lunkwill42
Copy link
Member

Yes, this hasn't been implemented in the API. I will consider this the official feature request :-)

@lunkwill42 lunkwill42 added the good first issue Needs no networking experience and is assumedly small label Dec 14, 2021
@lunkwill42
Copy link
Member

The principal NAV model that describes link aggregation is InterfaceAggregate:

class InterfaceAggregate(models.Model):
"""Interface aggregation relationships"""
aggregator = models.ForeignKey(
Interface,
on_delete=models.CASCADE,
db_column='aggregator',
related_name='aggregators',
)
interface = models.ForeignKey(
Interface,
on_delete=models.CASCADE,
db_column='interface',
related_name='bundled',
)
class Meta(object):
db_table = u'interface_aggregate'

The aggregator is the port that aggregates a set of interfaces, so every aggregator will have a number of entries in the InterfaceAggregate table.

The related_name values will embue every Interface with the attributes aggregators and bundled. I'm thinking a straightforward implementation here would be to extend the existing /interface endpoint to also serialize a representation of these attributes.

A, perhaps simpler, implementation is to introduce a new endpoint which only exposes the information from InterfaceAggregate model.

I'm having trouble deciding between the two - perhaps a design discussion is needed...

@lunkwill42
Copy link
Member

More importantly, there are the get_aggregator() and get_bundled_interfaces() methods on the Interface class. An example from an interactive session:

$ django-admin shell
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
Type 'copyright', 'credits' or 'license' for more information
IPython 8.4.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from nav.models import manage

In [2]: i = manage.Interface.objects.get(ifname='Trk1', netbox__sysname='teknobyen-3etg-sw2.uninett.no')

In [3]: i.get_bundled_interfaces()
Out[3]: <QuerySet [<Interface: 47 at teknobyen-3etg-sw2.uninett.no>, <Interface: 48 at teknobyen-3etg-sw2.uninett.no>]>

In [4]: _47 = i.get_bundled_interfaces()[0]

In [5]: _47.get_aggregator()
Out[5]: <Interface: Trk1 at teknobyen-3etg-sw2.uninett.no>

@lunkwill42
Copy link
Member

More importantly, there are the get_aggregator() and get_bundled_interfaces() methods on the Interface class. An example from an interactive session:

We more or less decided that the quickest win here is to serialize the results of these two method calls as a list of primary key IDs of the related Interface objects (which would not require writing a new view class)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api enhancement good first issue Needs no networking experience and is assumedly small
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants