ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Николай Ижиков" <nizhi...@apache.org>
Subject Re: Joining node validation failure event.
Date Tue, 03 Dec 2019 09:31:11 GMT
I think we also should provide the reason why join failed.

> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin <vololo100@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.sbt@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.sbt@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.sbt@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.sbt@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.sbt@gmail.com>
>>>>>>>> To:     Andrey Gura <agura@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.sbt@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.sbt@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


Mime
View raw message