Replies: 3 comments
-
In principle, we could do that. In practice, some modules don't have features, so we'd have to either add bogus features to them or use two mechanisms. As for "merge conflicts", multiple people would have to be working on the same module on different platforms at the same time. I'd love to have that problem ;) |
Beta Was this translation helpful? Give feedback.
-
Will implement this (with a few extra bits and pieces) to support "parent device" functionality. Empty feature will indicate the device supports that module, but has no configurable elements, feature set to false will indicate the device does NOT support that module. |
Beta Was this translation helpful? Give feedback.
-
Implemented in #853 |
Beta Was this translation helpful? Give feedback.
-
Every time we add the support for a "feature" (aka: module) on a platform, it is needed that we edit both the platform and the feature section.
example:
IMHO it would be easier if we can auto-generate the "supported_on" based on the platform data itself.
This would also add the "benefit" of avoiding conflicts on the file if multiple people are working to different platforms at the same time.
the "supported_on" attribute can be auto-generated with sth like:
I can try to work on this after the JunOS stuff I'm working on, if you agree.
Beta Was this translation helpful? Give feedback.
All reactions