-
Notifications
You must be signed in to change notification settings - Fork 130
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
Add ASN data source #285
Add ASN data source #285
Conversation
Hi, thank you for your MR. This is looking quite good already. I am a somewhat unsure about the naming of the query attributes: You are the first person to implement an First, since "positive" filters are the default, I think you should rename Second, for other "lookup expressions" (full list here), we have to decide if we either use a "human friendly" word, like you did with Since a human friendly string for things like Opinions? |
Thanks @fbreckle for the feedback. I agree that using the explicit suffixes in the attribute names makes more sense than "human friendly" names. Especially when you start to consider the other suffix filters like the example you provided. I updated the include and exclude attributes to be I see you noticed that I used the same naming convention in #284. If this looks good to you now, I can replicate the changes in that PR. Thanks! |
LGTM now, just wondering about the docs part. About the lookup expressiosn: I might end up changing my mind about these. The arguments above are valid, but my concern is that it is really unreadable when reading code that was written by someone else. Maybe long, but human readable mappings are better after all. The good thing is, refactoring/deprecating these expressions should be rather easy, as long as they are not everywhere yet. We could even just allow both. This is just FYI. I will start a discussion about this when I have time. For now, we go with the technical names. |
* Add ASN data source * Change naming standard for tag variables * revert index.md change
netbox_asn
data source