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 Wed, 04 Dec 2019 18:54:01 GMT
Mikhail,

Yes I am fine with the approach.

ср, 4 дек. 2019 г. в 20:30, Mikhail Petrov <pmgheap.sbt@gmail.com>:
>
> 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
> >
> >



-- 
Best regards,
Ivan Pavlukhin

Mime
View raw message