How that reason will look like? Actually, I mostly thinking about general API here. What I would like to avoid is exposing something not general but needed only for a particular extension (plugin).
вт, 3 дек. 2019 г. в 12:31, Николай Ижиков <nizhi...@apache.org>: > > I think we also should provide the reason why join failed. > > > 3 дек. 2019 г., в 12:22, Ivan Pavlukhin <vololo...@gmail.com> написал(а): > > > > Mikhail, > > > > So, I suppose there should be ordering guarantees that listener is > > registered before first validation failure can occur. Hope > > GridComponent#onKernalStart is the right place. Is it enough to pass > > only problematic node id (or ClusterNode) with an event? Actually such > > event seems to fit naturally node join/left/failed events. > > > > вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov <pmgheap....@gmail.com>: > >> > >> Hi Ivan. > >> > >> No other lifecycle events are needed in my case. > >> > >> We can register a listener in the security component's > >> GridComponent#onKernalStart method and listen locally to every failed > >> joining attempt. Am I missing something? > >> > >> Regards, > >> Mikhail. > >> > >> On 03.12.2019 8:48, Ivan Pavlukhin wrote: > >>> Mikhail, > >>> > >>> Do you need some ordering guarantees among node lifecycle events and > >>> listener notifications. For example, I can imagine that it is good to > >>> notify security component about every node failed validation. How can > >>> we achieve it with events (I assume dynamic listener registration)? > >>> > >>> пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov <pmgheap....@gmail.com>: > >>>> Hi, Andrey. > >>>> > >>>> It doesn't influence on authentication or authorization process. There > >>>> is a security requirement that demands to notify some outer security > >>>> subsystems in a specific way when joining node validation failed in any > >>>> Ignite component (e.g. GridCacheProcessor) not only in > >>>> IgniteSecurityProcessor. So PluginProvider#validateNewNode is not > >>>> acceptable for me. > >>>> > >>>> Regards, > >>>> Mikhail. > >>>> > >>>> On 02.12.2019 16:35, Andrey Gura wrote: > >>>>> Mikhail, > >>>>> > >>>>> I don't understand how node validation on join affects security. But > >>>>> it seems that you can use > >>>>> PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode, > >>>>> java.io.Serializable) method. Does it fit for your needs? > >>>>> > >>>>> On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov <pmgheap....@gmail.com> > >>>>> wrote: > >>>>>> Hi, Ivan. > >>>>>> > >>>>>> > >>>>>> Unfortunately, we came to no decision yet. As I mentioned above this > >>>>>> event is disabled by default and no node will receive this event > >>>>>> without > >>>>>> an explicit subscription. In my case, that event is assumed to be used > >>>>>> on node locally to share joining node info between security and > >>>>>> discovery components. I have no idea how to solve this problem without > >>>>>> publishing a new event too. But I'm concerned about the acceptance of > >>>>>> that solution. Maybe it can be solved some other way? I will appreciate > >>>>>> any suggestion or review PR [1] with event implementation. > >>>>>> > >>>>>> > >>>>>> [1] https://github.com/apache/ignite/pull/7057 > >>>>>> > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Mikhail. > >>>>>> > >>>>>> On 02.12.2019 10:38, Ivan Pavlukhin wrote: > >>>>>>> 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 > -- Best regards, Ivan Pavlukhin
