Skip to content

Conversation

m-hau
Copy link
Contributor

@m-hau m-hau commented Aug 11, 2025

Small follow-up to #3391.

Fix the poe to _is_power_source rename for ports in the README, forgot that in the original PR.

Rename the device-type-level custom property is_powered to _is_powered. The leading underscore makes it obvious that it's a custom property, and is then consistent with the ports' _is_power_source. Also remove it from device types if it's true (the default).

@m-hau m-hau marked this pull request as ready for review August 11, 2025 09:11
@harryajc
Copy link
Collaborator

I think changing the property is probably not a good idea given it is used a lot within this repo

@m-hau
Copy link
Contributor Author

m-hau commented Aug 11, 2025

I believe it to be very beneficial, because a lot of the time people won't read the docs but just copy&paste some other type, and adjust it as needed, not realising that some fields are not imported into NetBox, carrying them over in a cargo-cult-like manner. Distinguishing fields from/for NetBox and repo-internal-only by using the underscore-prefix should make it obvious to anybody at a glance that later are different from all the others and thus probably "special" in some way. And since it shouldn't be used outside of the repo, renaming it should be pretty safe.

But that's just my opinion. If you want it, I can remove the rename and only leave the doc fixes.

@harryajc
Copy link
Collaborator

HI @m-hau
Okay, I think the best option is, if you can create a separate PR with the doc changes then I can get that approved and I'll get another maintainer to review this PR and see what they think of making this property change

The leading underscore makes it obvious that it's a custom property,
and is then consistent with the ports' _is_power_source. Removed it
from device types if it's true (the default).
@m-hau
Copy link
Contributor Author

m-hau commented Aug 11, 2025

Done. Moved the doc-update to #3404, and left the property-rename here.

@harryajc
Copy link
Collaborator

harryajc commented Aug 11, 2025

@danner26 @DanSheps @ryanmerolle Thoughts on this?

@harryajc harryajc added the status: gathering feedback Further discussion is needed to determine this issue's scope and/or implementation label Aug 11, 2025
@DanSheps
Copy link
Member

I need to review the ramifications of this. This is the first time I am seeing this and this is not a standard attribute

@harryajc
Copy link
Collaborator

I need to review the ramifications of this. This is the first time I am seeing this and this is not a standard attribute

This is a attribute specific to this repo for devices that aren't powered so that the power validation scripts pass successfully.

@DanSheps
Copy link
Member

I am more wondering if this is even needed or if there is a way to work this so that it doesn't check for that.

Reason being is it is possible to have a chassis without PSU's or interfaces so it would be an "unpowered" device however we handle this fine.

I think the better way to do this is;

  • Check for interfaces and console server ports, if there are no interfaces, console ports, console server ports, power outlets, or device bays we assume it is "passive device"
  • If the device is passive, simply pass the test
  • If the device is not passive, continue to validate

@m-hau
Copy link
Contributor Author

m-hau commented Aug 14, 2025

So instead of explicitly defining a device type as non-/powered and based on that validating the allowed/required components, the powered status would be inferred from the defined components and based on that validate the components. Sounds reasonable, but has the disadvantage that there is no "escape hatch" for corner cases, where you would still want to manually override/set it.
But you could also combine both: By default infer it from the components, but still allow it to be set manually in the definition. This would drastically reduce the number of manual-sets because the default would already do "the right thing" in most cases.

I did a quick-and-dirty implementation of this (applies to master), and after tweaking the checked-for components a bit (device-bay is allowed for non-powered, but not module-bay) all device-types still pass validation. Feel free to play around with it yourself.

diff --git a/tests/device_types.py b/tests/device_types.py
index 24919397..95c9d139 100644
--- a/tests/device_types.py
+++ b/tests/device_types.py
@@ -75,6 +75,11 @@ class DeviceType:
     def validate_power(self):
         CUSTOM_POWER_SOURCE_PROPERTY = '_is_power_source'
 
+        # ignore the power status from the definition, instead infer it from the components
+        self.definition['is_powered'] = False
+        for property_name in ('console-ports', 'console-server-ports', 'power-ports', 'power-outlets', 'interfaces', 'module-bays'):
+            self.definition['is_powered'] |= bool(self.definition.get(property_name, False))
+
         # Check if power-ports exists
         if self.definition.get('power-ports', False):
             # Verify that is_powered is not set to False. If so, there should not be any power-ports defined

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: gathering feedback Further discussion is needed to determine this issue's scope and/or implementation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants