Hi, On Tue, May 31, 2016 at 4:48 AM, Gert Doering <[email protected]> wrote:
> Hi, > > On Tue, May 31, 2016 at 12:22:49AM -0400, Selva Nair wrote: > > filtering stops as soon as a match is found. Full regex support is > > not available but partial matching is used to allow some flexibility. > > Thus > > > > pull-filter accept "ifconfig 10.9.0." > > pull-filter reject "ifconfig " > > pull-filter accept "route 10." > > pull-filter reject "route " > > Thinking about this a bit more, without having studied the code - what > do you think about having a third category > > pull-filter accept "route 10." > pull-filter reject "route 195.30." > pull-filter ignore "route " > > "ignore" would be "if that option shows up, log the fact that we ignored > it, and go on", while "reject" would be "if this shows up, something bad > is happening, so complain loudly, abort the connection and try the next > alternative". > Interesting. At the very least it may be worth doing a v2 to make adding new action types easier. Suppose we do make "reject" to not just remove the option but reject the server. What to do if no alternative remotes exist --- just SIGHUP and hope that next try will succeed or something like management-hold will keep the connection waiting for user intervention? I would avoid issuing or causing a SIGTERM. > > > A maximum of 64 filters are supported. > > We briefly discussed this yesterday - 64 should be plenty for about > everything, but a dynamic list might be the way to cope for the *one* > user who then comes up with the 65th rule... > I didn't make it a linked-list mainly because of the need of adding to the tail of the list which means some extra extra book-keeping and if-elses. For now the 65th filter will trigger an early exit at the config parsing stage with a message. Selva
