ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Pavlukhin <vololo...@gmail.com>
Subject Re: Joining node validation failure event.
Date Tue, 03 Dec 2019 12:12:37 GMT
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



-- 
Best regards,
Ivan Pavlukhin

Mime
View raw message