On Thu, Nov 8, 2018 at 2:42 PM Tom Pantelis <tompante...@gmail.com> wrote:
> > > 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.... > Fair point, I will try making changes on the BGP side and see how it goes > > > >> 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
