On 07/11/2018 20:36, Ajay Lele wrote: > > > On Wed, Nov 7, 2018 at 3:58 AM Robert Varga <n...@hq.sk > <mailto:n...@hq.sk>> wrote: > > On 07/11/2018 02:07, Ajay Lele wrote: > > Hi Controller-devs, > > > > [0] changed EOS behavior such that a non-voting member cannot become > > entity owner. But there are some situations where we want to allow > this > > e.g. when BGP speaker config is local to node and not replicated in > > cluster. I think the behavior should be that non-voting member > will not > > become entity owner *provided* one or more voting candidates are > > available. Thoughts? > > This is a sticky topic. Non-voting members are meant to be used for > geo-redundancy only, in which case non-voting side should be really > passive. > > Can you describe the deployment scenario in more detail? > > > One scenario is BGP route injection using application RIB. Injected > route will be withdrawn when BGP connection over which it is advertised > goes down. To prevent downtime window when primary to DR cutover > happens, BGP connection is established from non-voting member from DR > site as well. This is accomplished by moving BGP speaker data to a > separate shard which is not replicated.
I see, so this is used for planned maintenance only, right? If that is the case, I think it would make sense to make the selection policy switchable at runtime, such that under normal operation only voting members are considered, but in preparation for a switchover, the policy can be adjusted. Can you file an improvement issue against controller, please? Tom: do you have an opinion on how best implement this? It feels like we want to have a per-entity behavior table, so that BGP would switch to non-voting, but other services would not... Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
