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 09:39:33 GMT
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