Autodiscover should not require identical metadata for start/stop events

[andrewvc]

I'm currently in the process of writing an AWS ELB autodiscover adapter in #8680 .

One design issue I'm hitting, which probably didn't come up before, is that the event data published here is mutable. In other words, an ELB might be in a different state at stop than start, yielding different metadata. This is important because autodiscover de-duplication and stop/start code relies on hashing metadata consistently.

This breaks with AWS autodiscover since a number of items in the metadata are mutable. While it may be possible to remove those, it would be better to not handicap this provider.

I propose that we modify the autodiscover code to have two paths. One for the current method, and the other using a synthetic PK, which in the case of AWS is an item's ARN.

This would mean that we would maintain a second hash table per provider in autodiscover.go for items of this type of the . form map[string][]config, where string is that synthetic PK and []config is the list of configs rendered for that unique resource.

[ruflin]

@exekias Would be great to get your opinion on this one.

[exekias]

Interestingly enough, I started just this 18h ago: #8851 😄

[exekias]

About having 2 paths: I think we are still on time of going for this new approach and kill the old one. I don't feel really comfortable with dual behavior, as long as we can avoid it.

[andrewvc]

I actually don't need the current path so one works for me!

…

On Thu, Nov 1, 2018, 5:22 AM Carlos Pérez-Aradros Herce < ***@***.*** wrote: About having 2 paths: I think we are still on time of going for this new approach and kill the old one. I don't feel really comfortable with dual behavior, as long as we can avoid it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8863 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIBY09wZogUmUQAUJUU5SLFZoqiG9YOks5uqstigaJpZM4YFnlg> .

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[botelastic]

This issue doesn't have a Team:<team> label.