Mikhail, Andrey, Have you come to a common decision here? As for me, it sounds useful to expose node join failure details somehow. The thing to decide on is a mechanism to expose it. Unfortunately, immediately have no idea better than using events.
> What is purpose of the special cluster wide event? Node is not joined > to the topology. Why topology nodes should know something about this > node? Was this question answered? I suppose that at least coordinator will receive the event, will not it? чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov <pmgheap....@gmail.com>: > > Hi, Ivan. > > I'm sorry that the discussion was moved in private channel. The problem > I'm trying to solve is described below in the thread. The security > plugin in my case stores and analyzesinfo about a node that failed to join. > > > Regards, > > Mikhail. > > > > -------- Forwarded Message -------- > Subject: Re: Joining node validation failure event. > Date: Thu, 21 Nov 2019 21:43:33 +0300 > From: Mikhail Petrov <pmgheap....@gmail.com> > To: Andrey Gura <ag...@apache.org> > > > > Hi, Andrey. > > In my task security plugin running on the coordinator must locally > handle the situation when some node is trying to join the topology with > the invalid configuration. I can't handle the response on a node that > failed to connect because it's untrusted. > > Actually I'm only concerned about one validation -- when all Ignite > components validate new node. > > In my case plugin must be able to obtain general and security subject > information from joining TcpDiscoveryNode attributes. But I have no idea > how to share information between the security and discovery components > without recording event and listening it locally. > > This event is assumed to be disable by default and in my case used only > on local node so it's not look like "cluster wide event". > > Also I propose to record this event in dedicated utilityPool so it can't > stuck discovery thread. > > I will appreciate any thoughts on this problem. > > Regards, > Mikhail. > > On 21.11.2019 19:40, Andrey Gura wrote: > > Mikhail, > > > > It is still not enough details to me. What is expected behavior if the > > plugin? > > > > There are a different validations during node join. Many of them > > placed in RingMessageWorker#processJoinRequestMessage method. If > > validation will fail then corresponding message will be sent to the > > joining node (including TcpDiscoveryAuthFailedMessage) and node will > > not joined to topology. > > > > What is purpose of the special cluster wide event? Node is not joined > > to the topology. Why topology nodes should know something about this > > node? > > > > On Thu, Nov 21, 2019 at 9:54 AM Mikhail Petrov <pmgheap....@gmail.com> > > wrote: > >> Hi, Andrey. > >> > >> I take part in the development of a custom security plugin for Apache > >> Ignite. There is an information security requirement for which node > >> joining failures due to invalid configuration must be handled by the > >> plugin. > >> > >> This is where my case comes from. Are there any objections to the > >> proposed approach? > >> > >> Regards, > >> Mikhail. > >> > >> On 20.11.2019 19:38, Andrey Gura wrote: > >>> Hi, Mikhail! > >>> > >>> Could you please describe the case for this new event? > >>> > >>> On Wed, Nov 20, 2019 at 12:45 PM Mikhail Petrov > >>> <pmgheap....@gmail.com> wrote: > >>>> Hello, Igniters. > >>>> > >>>> There is a case which requires to handle joining node validation > >>>> failure > >>>> in Ignite components and obtain information of the node that tried to > >>>> join and the reason for the failure. Now, as I see, there is no way to > >>>> do it. I propose to implement a new event -- NodeValidationFailedEvent > >>>> -- and record it in case the validation fails. I have created Tiket [1] > >>>> and PR [2], which shows an example of implementation. Could anyone take > >>>> a look at it, please? > >>>> > >>>> [1] https://issues.apache.org/jira/browse/IGNITE-12380 > >>>> > >>>> [2] https://github.com/apache/ignite/pull/7057 > >>>> -- Best regards, Ivan Pavlukhin
