Exception(s) from component(s) that don’t want node joined.
> 3 дек. 2019 г., в 12:39, Ivan Pavlukhin <vololo...@gmail.com> написал(а):
>
> 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
