The node will now have both IP addresses associated with it, although the old IP is no longer configured for the node.
Changing snmp-primary to N or S does not change this btw.
This does work as expected if both system do or do not support snmp.
Environment
Operating System: Linux
Platform: PC
Acceptance / Success Criteria
None
Lucidchart Diagrams
Activity
Show:
David Hustace September 29, 2010 at 8:26 AM
Ranger, this was the way of the importer. The importer treated the requisition as the ultimate authoritative source of interfaces and services on a node and Provisiond promoted the Agent to this role. Actually, the "import phase" was demoted when the "node scan phase" was added.
I had suggested a flag on the requisition a while back but I think the "architect" saw this idea as either flawed or too complex to handle at the time.
Benjamin Reed August 25, 2010 at 10:21 AM
Can't win for losing...
People who have SNMP go down temporarily opened a bug that re-provisioning removed all their interfaces. Now people who have SNMP taken down when changing nodes want all their interfaces removed.
Sounds like this needs to be somehow configurable?
How to reproduce:
1. provision a node
the node has to support snmp
<node node-label="New Node" foreign-id="1282740818524" building="dktest">
<interface status="1" snmp-primary="P" ip-addr="10.2.50.105" descr="">
<monitored-service service-name="ICMP"/>
</interface>
</node>
2. sync the group and wait for the node scan to finish
3. edit the node
change the ip address
the new address must not support snmp
<node node-label="New Node" foreign-id="1282740818524" building="dktest">
<interface status="1" snmp-primary="P" ip-addr="10.2.50.42" descr="">
<monitored-service service-name="ICMP"/>
</interface>
</node>
4. sync the group again
The node will now have both IP addresses associated with it, although the old IP is no longer configured for the node.
Changing snmp-primary to N or S does not change this btw.
This does work as expected if both system do or do not support snmp.