On Wed, Nov 7, 2018 at 3:36 PM Robert Varga <n...@hq.sk> wrote: > 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... >
yeah that seems like one solution. However why is BGP even using the EOS in that case to establish a connection, ie if every node is intended to establish its own connection then it seems you don't need EOS to decide that... > > Regards, > Robert > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
