Correct sysoidmask lines in default datacollection files

Description

In a datacollection file, the lines with "sysoidMask" should have a dot "." at the end of the system oid.
Some of the default datacollection files do not have the dot at the end.

Cd /opt/opennms/etc/datacollection

grep sysoidMask * | grep -v "\.<"
ceragon-FA1500.xml: <sysoidMask>.1.3.6.1.4.1.2281.1.4</sysoidMask>
ceragon-FA1500.xml: <sysoidMask>.1.3.6.1.4.1.2281.1.4.4</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.36</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.39</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.41</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.58</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.13</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.14</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.15</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.19</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.20</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.22</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.23</sysoidMask>
juniper.xml: <sysoidMask>.1.3.6.1.4.1.2636.1.1.1.2.24</sysoidMask>
konica.xml: <sysoidMask>.1.3.6.1.4.1.18334.1.1.1.2.1</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.1</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.2</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.3</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.4</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.5</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.6</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.7</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.8</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.9</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.11</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.12</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.17</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.18</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.19</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.29</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.30</sysoidMask>
paloalto.xml: <sysoidMask>.1.3.6.1.4.1.25461.2.3.35</sysoidMask>

Since that lines represent a mask of the sysoid, there could be unintended consequences of NOT having the dot.
These should not be this way by default (at install).

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Ronny Trommer May 11, 2018 at 3:45 PM

Merged PR in develop

Ronny Trommer April 18, 2018 at 9:49 AM

Solved the merge conflicts and is targeted to develop.

David Hustace April 17, 2018 at 4:42 PM

I think a lot depends on the context of the change as well as the scope/size/impact of the change.

In this case, I don't think that we'll find that changing the the juniper.xml file is necessary for Meridian since we will unlikely see juniper sysoids that end in values > 100.

The one that looks troublesome is the paloalto where it looks like double collection write there in the file with .1> also matching .11> sysods.

I doubt that there are so many customers using paloalto devices that this would need to be back ported to old Meridians.

 

This is my $0.02 and think the change should be targeted for foundation 2018.

Benjamin Reed April 17, 2018 at 4:06 PM

I saw that, but it doesn't really answer the question, only begs it.

When we do these things that target released Meridian, I would really like a more active acknowledgement from the support team of the tension between changing configs and providing value to Meridian users, since it has often gotten muddy in the past.  Every time I try to nail down "what is our official policy" I get 3 different answers.

So with that in mind, when we have config-change issues like this that come from support, I'd love to have these 3 questions answered:

  1. Does this affect Meridian customers?

  2. Should we provide configuration changes to existing Meridian releases, and if so, how far back?

  3. Should it be provided as a supplemental config that users have to merge on their own, or should it change the defaults?

Thoughts? ? ?

I'm cool with whatever the answer is, just not cool with always having to make the call last-minute when I see there's a merge happening at release time.

Ronny Trommer April 17, 2018 at 3:45 PM

sorry I made a comment about your topic in the PR

Fixed

Details

Assignee

Reporter

Fix versions

Affects versions

Priority

PagerDuty

Created April 16, 2018 at 3:46 PM
Updated May 11, 2018 at 3:45 PM
Resolved May 11, 2018 at 3:45 PM