On Wed, Nov 7, 2018 at 9:28 PM Tom Pantelis <tompante...@gmail.com> wrote:
> > > 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... > BTW, this is not just for planned maintenance but also for DR should the entire primary site become unavailable. Either way I don't think changing some setting dynamically prior to fail-over (and fail-back) is a viable solution - it would be some permanent setting at installation/deployment time, similar to the configuration to put the BGP data in a local, non-replicated shard. So perhaps there could be an additional "clustered" setting in the BGP module that tells it whether or not to use EOS. > > >> >> Regards, >> Robert >> >>
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
