I strongly doubt keystone (as a project) is affected by this. ;-)
Option 2 is best for kolla because it aligns with letting users configure stuff like this using native config format via overrides. This option was not even documented. It needs to be deprecated/obsoleted and removed. If there is something for k-a to orchestrate there, which would be unwieldy for overrides, then we can discuss it but in this form it's not worth the trouble of changing behavior.
Please see the change proposal comments for details
TL;DR: the proposal changed the default behavior by enabling the notification messaging driver by default (which is actually not a default for keystone). K-a simply did not enable it by default (and notification type was always CADF if only enabled). We would need to slap an upgrade note that we are changing that behavior and (while it is sensible to run notifications) it would need some explanation anyway.
I strongly doubt keystone (as a project) is affected by this. ;-)
Option 2 is best for kolla because it aligns with letting users configure stuff like this using native config format via overrides. This option was not even documented. It needs to be deprecated/ obsoleted and removed. If there is something for k-a to orchestrate there, which would be unwieldy for overrides, then we can discuss it but in this form it's not worth the trouble of changing behavior.
Please see the change proposal comments for details
TL;DR: the proposal changed the default behavior by enabling the notification messaging driver by default (which is actually not a default for keystone). K-a simply did not enable it by default (and notification type was always CADF if only enabled). We would need to slap an upgrade note that we are changing that behavior and (while it is sensible to run notifications) it would need some explanation anyway.