On Thu, Nov 8, 2018 at 4:48 PM Ajay Lele <ajaysl...@gmail.com> wrote:
> > > 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? > The problem with that is that it doesn't know what other candidates exist at the time the decision is made. It would work in your case assuming there's only the one local entity candidate in the entire 6-node cluster. For others, it may be that a non-voting candidate arrives first then a voting one, in which case ownership would get revoked. That is not ideal and could lead to quite bit of churn across all entities before it finally settles out. Therefore it seems there would need to be some setting per entity or entity type as Robert suggested. However this BGP use case just seems like it goes against the premise of the EOS. The EOS is intended to maintain one entity owner across a clustered environment. However in your case, it seems you essentially want to bypass this behavior and really use EOS to enable functionality per node, ie you really want to treat it as if in a non-clustered/single-node environment where the local candidate always gets ownership, and which is why the BGP data shard is non-replicated. So that's why I suggested the EOS not even be used in this case rather than trying to shim changes in to accommodate a (seemingly) incompatible use case. That's my opinion.... > 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 > Base on my comments above, I think you're going to need a setting somewhere no matter what. > > >> 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
