onos-classic config loader failed to push configuration

[teone]

After month of usage across the board today we observed a failure in the config-loader:

Check that component org.opencord.olt.impl.OltFlowService is active
-----------------------------------------
{"org.opencord.olt.impl.OltFlowService":{"enableDhcpOnNni":"false","enablePppoe":"false","defaultTechProfileId":"64","enableIgmpOnNni":"false","enableEapol":"true","enableDhcpV6":"false","enableDhcpV4":"true"}}Prepare to update org.opencord.olt.impl.OltFlowService config
{
  "enableDhcpOnNni": "false",
  "defaultTechProfileId": "64",
  "enableIgmpOnNni": "false",
  "enableEapol": "false",
  "enableDhcpV6": "false",
  "enableDhcpV4": "false"
}
curl: (22) The requested URL returned error: 404

as a result of the 404 the config in ONOS was (note the enableEapol and enableDhcpV4 values):

org.opencord.olt.impl.OltFlowService
    name=enableDhcpOnNni, type=boolean, value=false, defaultValue=false, description=Create DHCP trap flow on NNI port(s).
    name=enablePppoe, type=boolean, value=false, defaultValue=false, description=Send PPPoED authentication trap flows before subscriber provisioning.
    name=defaultTechProfileId, type=integer, value=64, defaultValue=64, description=Default technology profile id that is used for authentication trap flows.
    name=enableIgmpOnNni, type=boolean, value=false, defaultValue=false, description=Create IGMP trap flow on NNI port(s).
    name=enableEapol, type=boolean, value=true, defaultValue=true, description=Send EAPOL authentication trap flows before subscriber provisioning.
    name=enableDhcpV6, type=boolean, value=false, defaultValue=false, description=Enable flows for DHCP v6 if dhcp is required in sadis config.
    name=enableDhcpV4, type=boolean, value=true, defaultValue=true, description=Enable flows for DHCP v4 if dhcp is required in sadis config.

This happened on a 3 nodes ONOS cluster, and I assume that because of the kubernetes service implementation the request to check if a component was active landed on one ONOS instance while the request to set the config landed on a different instance.

Another important thing to note is that in this deployment the onos-config-loader component was deployed with reconcile_mode: false, if that wasn't the case this issue would most likely solve itself.

As said this was observed once over many months of usage so I don't think an action is required, just reporting it to make other users aware of this possibility.

If this is affecting others a possible solution is to change this line to account for 404 response codes