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:22:10 GMT
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