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

Controllers #3111

Closed
lampwins opened this issue Jan 11, 2023 · 4 comments · Fixed by #5325
Closed

Controllers #3111

lampwins opened this issue Jan 11, 2023 · 4 comments · Fixed by #5325
Assignees
Labels
type: feature Introduction of new or enhanced functionality to the application
Milestone

Comments

@lampwins
Copy link
Member

lampwins commented Jan 11, 2023

As ...

Nelly - Network Engineer

I want ...

A way to model and track network controllers

So that ...

I can track the relationships between controllers, and the devices that they control

I know this is done when...

  • I have a model to define a controller
  • Controllers have a Controller-specific role.
  • Devices can be optionally related to one or more controllers with a defined priority

Optional - Feature groups this request pertains to.

  • Automation
  • DCIM

Database Changes

A new controller model and relationships with devices

External Dependencies

None

@lampwins lampwins added the type: feature Introduction of new or enhanced functionality to the application label Jan 11, 2023
@jvanderaa
Copy link
Contributor

Today I would model this using a tag from within the organization. Would keeping with that model but perhaps a feature tag type set up? Somewhere that would be like "Device-Tag" that would build a relationship that only allows the tag to be related in a device - device set up?

@davidban77
Copy link

A few examples that have been brought up for this type of model/relationship:

  • Wireless Controllers + APs
  • F5 BIG-IQ Centralized Management + F5 BIG IPs
  • Firewall Managers + Firewall boxes

A way to model out this controller/worker relationship might prove useful for representing solutions like the above. A way to track the relationships basically.

Regarding the tag system I have some questions and comments:

  • What if the tag ecosystem within the Nautobot environment is already overwhelmed?
  • For me personally, a tag is great to categorize the data that is useful to the external systems/operators. Not so much for indicating internal relationships between data in the same system.
  • Keeping track of tags for the relationship between controllers/workers would need to be done externally by a process? If is properly modelled, this should not be the case correct?

I have limited knowledge of the models and tags capabilities and if there are also performance and/or maintenance aspects to consider. But it would be really nice to have a controller view with all of its workers in Nautobot 😄

@jedelman8
Copy link
Contributor

But it would be really nice to have a controller view with all of its workers in Nautobot

Yes, this! This is the part I was going to add. The operator view (with however it's implemented) is likely the most beneficial. As an operator you think about your controllers and associated devices. That should be dead simple in the UI to understand, manage, and update.

@gsnider2195
Copy link
Contributor

Could this work similarly to DeviceRedundancyGroups? Since the controller is likely already a device in Nautobot would this kind of model work? Here's the DeviceRedundancyGroup for reference:

class DeviceRedundancyGroup(PrimaryModel, StatusModel):
    name = models.CharField(max_length=100, unique=True)
    slug = AutoSlugField(populate_from="name")
    description = models.CharField(max_length=200, blank=True)
    failover_strategy = models.CharField(...)
    comments = models.TextField(blank=True)
    secrets_group = models.ForeignKey(to="extras.SecretsGroup", ...)

class Device(PrimaryModel, ConfigContextModel, StatusModel, RoleRequiredRoleModelMixin):
    ...
    device_redundancy_group = models.ForeignKey(to="dcim.DeviceRedundancyGroup", ...)
    device_redundancy_group_priority = models.PositiveSmallIntegerField(...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature Introduction of new or enhanced functionality to the application
Projects
No open projects
Status: To Groom
Development

Successfully merging a pull request may close this issue.

6 participants