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
