MAISTRA-2262: Make sure IOR respond to all events

[jwendell]

Even those that arrive while IOR is performing its initial
sync. Previously those events were ignored.

Manual backport of #311

[knrc]

While you have addressed the race between the incoming events and the initial sync it looks as if you have introduced another by switching to namespaces instead of r.namespaces. I think your goroutine needs to grab the namespace lock around initialSync and use the current r.namespaces otherwise you could miss SMMR events

[knrc]

While you have addressed the race between the incoming events and the initial sync it looks as if you have introduced another by switching to namespaces instead of r.namespaces. I think your goroutine needs to grab the namespace lock around initialSync and use the current r.namespaces otherwise you could miss SMMR events

Looking further into the code it doesn't look as if you take any notice of the additional updates after the initial sync, other than to note the namespaces, which makes this change okay although I think you are going to face other issues by doing this. The code is still querying pods and services for every namespace and it relies on the UpdateNamespace call being invoked in time for it to do that which may not always happen, if so you will possibly miss a namespace update when you process the config updates for the gateways.

[jwendell]

I think your concern is covered in the unit tests (see the 2.1 PR).
When a new namespace is added to SMMR, and it contains a gateway, two things happen:
UpdateNamespaces() is called, amd it just updates r.namespaces.
handleEvent() is called, eventually calls findService() which reads r.namespaces

The reason I switched from r.namespaces to namespaces in initialSync() (within the first UpdateNamespaces() call) was to deal with this:

• first UpdateNamespaces() is called, say, with ns1, ns2.
• initialSync() is invoked in a goroutine
• UpdateNamespaces() is called again with ns1, ns2, ns3
• when initialSync() actually runs, it would read the new set of namespaces, instead of the initial set.

[knrc]

I think your concern is covered in the unit tests (see the 2.1 PR).
When a new namespace is added to SMMR, and it contains a gateway, two things happen:
UpdateNamespaces() is called, amd it just updates r.namespaces.
handleEvent() is called, eventually calls findService() which reads r.namespaces

The issue I think you will face is that these could come in the other way around, i.e. you could get a call to handleEvent before the related UpdateNamespaces is called. The risk of the race is small but I think it does still exist.

[jwendell]

@knrc I just backported the 2.1 commits here.

[knrc]

/test unit