Add identity for model-name. #1161
Conversation
|
How the identities are defined? Is the expectation that each vendor creates its own augmentation? |
+1 to this question. I'd like to understand the problem statement with this being a free-form string in reality at the implementations discretion. If this is now an identityref, the only method to cover some complete list now involves augments across all hardware models on all implementations that every consumer needs to absorb and handle should there be some strict validation. Any such augments should in reality also follow OC style but could do whatever they wish and breach the boundaries of the YANG language restrictions within OC (general augment problem) This introduces more complexity in reality and it's a design pattern that you could question all over the model set. I get the reason to want to enforce a better contract but I think leaving this as a (mostly) unbounded string is probably best |
|
I'm pretty much on the same page as @earies here. I think that using identities over a string would probably be quite painful for implementations to manage across different platforms/etc. I guess that the advantage of using identities is that it effectively forces an implementation to publish these ids up front (presumably they make the YANG available) rather than only being able to discover these at runtime. But I'm still not sure whether it would really help or just creates a lot of extra work for perhaps relatively little benefit. |
|
This is very timely. I've been exploring avenues to work with hardware module names. While I would love to have them well documented in a model, the complexity of naming conventions across vendors (*) poses challenges, so I see how this can get quickly out of control. Somehow related, we are currently working on a project to map the string linecard model-name to relevant configuration information, such as its interface naming convention. For more details, see: openconfig/entity-naming#33 (*)
Nokia: The Input/Output module (IOM) and Media Dependent Adapters (MDAs).
... |
|
Thanks for the comments @earies, @rgwilton and to @nleiva for the examples on the different patterns. There was some discussion on this in the Aug 13, 2024 operators meeting where concerns about the giant size of model-name identities given the breadth and long history of product catalogs make enumerating the list a burden of maintenance and bloat of the model. It's not clear there is an operational use case to have the model-names as an identity vs. runtime discovery. @SydneyCaulfeild I realize this draft PR is to explore these questions. Did you have a particular operational use case where having an identity is a significant advantage over runtime discovery? |
|
I can see how trying to maintain a list of model-names for all devices would be challenging. An example use case to demonstrate the benefit of an identity instead of a string was that when I generate devpaths (i.e. unique identifiers) for a chassis component using the device's telemetry, I use the @dplore If we're not going to use an identity, could I document somewhere that we would need to be notified if the model-name string is going to change (or maybe update the definition to say that it should not change)? If the chassis model-name string changes it would break my devpath generation for all components. Based on the comments above though it sounds like using an identity would not be worth it, which I understand. @robshakir using an identity for model-name was brought up in a meeting we had in early August. Did you have any other use cases to support using an identity over a string? If not, are you ok if we leave this as a string? |
I see where you are going with this as this creates a nice firm contract however I'd question how practical this is in reality and the gain vs. pain involved. This problem statement can apply to many areas of the model-set across many model-sets where it is potentially unmanageable (models in need of constantly being updated), extensibility must be accounted for thus augments must be accepted (does everyone want to accept augments and deviations?) and not all values can be easily describable in similar fashion (model names I'd agree may be slightly more manageable to come up with but still what I consider a small change to a model like this w/ a potential for large impact) The OC model-set is generally very loose and forgiving in definition which in reality just shifts the problems around. There are many spots where things can be firmed up but it's generally left up to implementation behavior to go enforce what is not described (leading to divergence often) The other option is to draw correlation in that values at some path (say a string) should come from a dictionary defined at some other path not bound by the YANG type (like a catalog, features, capabilities, etc.. - e.g. a loose out-of-band or annotated relationship). As an identityref with strict validation, a new version of a model needs to be published for any updates. The looser the type, the more flexibility to iterate at runtime and accept things outside the boundaries however your example refers to codegen which may be stricter.
We often talk about model node/structure backwards incompatibilities but rarely talk about the impact of values changing especially if those values are something that could be used as a cross reference, key or just ultimately a dependence being built - this is mainly your point on consistency and predictability. The reality is that change does occur for a variety of reasons - some good, some bad w/ varying effects so I think this is more about the pros and cons associated with being too strict vs. too loose and the overall impact to the community and implementors. Am not discrediting the overall problem statement though as having an enumerated list of all possible options for a value is desirable - esp. when it comes to hardware model names. YMMV as speaking on behalf of 1 implementation right now, there is often the dilemma to try to describe something as an enum or identity but the total amount of options may be too large or too dynamic in nature that falling back to a string is the best option overall. |
|
Thank you all for your feedback! Based on the consistent feedback that changing this to an identity would not be worth the pain of maintaining a list of hardware models, we can leave this as a string. We will instead send requests to communicate what we are expecting the model-name value to be so that we are on the same page with vendors. Here is an example of how the model-name would be used for the chassis component on a Nokia 7250 IXR-10e device:
|
Change Scope