ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Petrov <pmgheap....@gmail.com>
Subject Re: Joining node validation failure event.
Date Wed, 04 Dec 2019 17:30:10 GMT
Ivan,

Am I right, that current approach to solving this problem looks good for 
you?

Regards,
Mikhail.

On 03.12.2019 15:12, Ivan Pavlukhin wrote:
> Mikhail,
>
> Yep, I see IgniteNodeValidationResult in new event in PR [1].
>
>> Discovery events such as (join/left/failed) are connected with a
>> topology version change. In my case that not happens and may be
>> misleading. That's why the new event type was chosen.
> I did not mean that one of those events should be used. I meant that
> it sounds natural to me to have an additional "unsuccessful node join"
> event (like is done in PR[1]).
>
> https://github.com/apache/ignite/pull/7057/files
>
> вт, 3 дек. 2019 г. в 14:32, Mikhail Petrov <pmgheap.sbt@gmail.com>:
>> Nikolay, Ivan,
>>
>> I understood the possible problem. It seems that it can be solved using
>> EventStorageSpi which starts before DiscoveryManager.
>>
>> As for me, ClusterNode is enough. It contains all info about joining
>> node including its attributes.
>>
>> Discovery events such as (join/left/failed) are connected with a
>> topology version change. In my case that not happens and may be
>> misleading. That's why the new event type was chosen.
>>
>> The cause of the failure is also presented in the event.
>>
>> Regards,
>> Mikhail.
>>
>> On 03.12.2019 13:19, Николай Ижиков wrote:
>>> Exception(s) from component(s) that don’t want node joined.
>>>
>>>> 3 дек. 2019 г., в 12:39, Ivan Pavlukhin <vololo100@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, Николай Ижиков <nizhikov@apache.org>:
>>>>> 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
>>>> --
>>>> Best regards,
>>>> Ivan Pavlukhin
>
>

Mime
View raw message