On Thu, Nov 8, 2018 at 4:32 AM Tom Pantelis <tompante...@gmail.com> wrote:
> > > 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? >>> >> Same situation for unplanned as well, as as soon as primary goes down the routes will be withdrawn, so we need to have a separate connection from DR in parallel >>> 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... >>> >> >> One option I see is to give preference to voting members but if none exists, give ownership to non-voting one. This will have to be reevaluated every time the candidate list changes. Not giving ownership to a (non-voting) candidate when no other candidate exists, sounds extreme to me. What do you think? Actually voting status is being considered for EOS shard, where as in BGP case we create a separate shard for BGP data which is not replicated and so it is still voting. So ideally it should look at voting status of the "service" shard, but I am not sure if it will be possible to implement that 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... >> > Adding BGP "non-clustered" knob to indicate that EOS should not be used can be an option, but in a way the user has already expressed that intent by not replicating the BGP shard, so an additional config which will have to be kept in sync with shard config.. also other apps which are in same boat like PCEP will require similar update > 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
