Re: Joining in

[Ilya Kasnacheev]

Hello!

I have added you to contributors role.

Please make sure to read
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Regards,
-- 
Ilya Kasnacheev


чт, 1 апр. 2021 г. в 16:27, Игорь Гусев :

>
> Hi all!
> I am Igor Gusev, and I am an experienced technical writer. I am learning
> in-memory processing technologies and would be glad to contribute to the
> community. Please give me access to Apache Ignite Jira.
> My JIRA ID is  igusev.
>
> Thanks in advance!
> Igor

Re: Joining the community

[Denis Magda]

Hi Nikita,

Welcome to the community! We've been waiting for professionals like you for
a while ;)

Sharing extra resources:

   - Our documentation contribution process, you're welcome to suggest
   changes:
   https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document
   - Our Slack channel, you can reach out to most of the contributors there
   if need to talk out any ticket 101:
   
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Collaborate#HowtoCollaborate-IgniteSlack


Please join in me and Maksim here, we already need your help:
https://issues.apache.org/jira/browse/IGNITE-13796

-
Denis


On Thu, Dec 3, 2020 at 11:22 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi Nikita,
>
> Welcome to the community! Any help with the documentation is extremely
> valuable.
>
> I've added you to the Contributors group in Jira - you should be able to
> assign tickets to yourself now.
>
> -Val
>
> On Thu, Dec 3, 2020 at 7:46 AM Никита Сафонов 
> wrote:
>
> > Hi everyone!
> > My name is Nikita Safonov, I am a professional technical writer. Since I
> am
> > familiar with in-memory processing technology and deeply interested in
> its
> > emerging nature, I would be glad to contribute to the community. I kindly
> > request to grant me access to the Apache Ignite JIRA.
> >
> > My JIRA ID is: nsafonov
> >
> >
> > Best regards,
> >
> > Nikita
> >
>

Re: Joining the community

[Valentin Kulichenko]

Hi Nikita,

Welcome to the community! Any help with the documentation is extremely
valuable.

I've added you to the Contributors group in Jira - you should be able to
assign tickets to yourself now.

-Val

On Thu, Dec 3, 2020 at 7:46 AM Никита Сафонов 
wrote:

> Hi everyone!
> My name is Nikita Safonov, I am a professional technical writer. Since I am
> familiar with in-memory processing technology and deeply interested in its
> emerging nature, I would be glad to contribute to the community. I kindly
> request to grant me access to the Apache Ignite JIRA.
>
> My JIRA ID is: nsafonov
>
>
> Best regards,
>
> Nikita
>

Re: Joining Ignite ASF

[Ivan Pavlukhin]

Hello Semyon,

Welcome to Apache Ignite Community!

I added your account to the contributors list. Now you can assign
tickets to yourself. Do not hesitate to ask if you need any
assistance.

Please check this page out for commonly asked questions pertaining to
the contribution process https://ignite.apache.org/community/contribute.html
Consult "Pick a ticket" section if you have no ticket to start with.

Best regards,
Ivan Pavlukhin

пн, 6 апр. 2020 г. в 21:07, Данилов Семён :
>
> Hello!
> I would like to start contributing, could you please add me to contributors 
> list? My login for https://issues.apache.org/ is sdanilov.
>
> Kind regards,
> Semyon Danilov.

Re: joining

[Prashant Rahulkar]

Hello Denis,
We are planning to migrate to Apache Ignite, we have created POC for our
system with Ignite and working well so want to contribute in development.

Thanks,
Prashant Rahulkar.

On Tue, 17 Dec 2019 at 01:25, Denis Magda  wrote:

> Prashant,
>
> What brought you to Ignite folks? Do you already use it internally and
> would like to improve contributing?
>
> -
> Denis
>
>
> On Sun, Dec 15, 2019 at 11:48 PM Prashant Rahulkar <
> prashantrahul...@gmail.com> wrote:
>
> > Hello  Dmitriy ,
> >
> > Thanks for your clarification, definitely our employee will contribute
> with
> > riEquaiton.com official mail id.
> >
> >
> > Thanks,
> > Prashant Rahulkar.
> >
> > On Sat, 14 Dec 2019 at 18:34, Dmitriy Pavlov  wrote:
> >
> > > Hi Prashant,
> > >
> > > Thank you for your interest in Apache Ignite. And I hope the Ignite
> > > community would be glad to work with new contributors.
> > >
> > > Just one note: A company can not contribute to an Apache project, but
> > your
> > > employee(s) can contribute as an individual. Similar is true for
> > > management, an employee can be a member of PMC, but the project is
> > managed
> > > not by companies but only by the project management committee.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > сб, 14 дек. 2019 г. в 05:27, Prashant Rahulkar <
> > prashantrahul...@gmail.com
> > > >:
> > >
> > > > Hello Everyone,
> > > > I have started software firm in India, with complete motivation to
> > focus
> > > on
> > > > open source technologies, so as a part of company policy we will star
> > to
> > > > contribute in this project with our company name.
> > > >
> > > >
> > > > Thanks,
> > > > PrashantR.
> > > >
> > >
> >
> >
> > --
> > ~ Rahul
> >
>


-- 
~ Rahul

Re: joining

[Denis Magda]

Prashant,

What brought you to Ignite folks? Do you already use it internally and
would like to improve contributing?

-
Denis


On Sun, Dec 15, 2019 at 11:48 PM Prashant Rahulkar <
prashantrahul...@gmail.com> wrote:

> Hello  Dmitriy ,
>
> Thanks for your clarification, definitely our employee will contribute with
> riEquaiton.com official mail id.
>
>
> Thanks,
> Prashant Rahulkar.
>
> On Sat, 14 Dec 2019 at 18:34, Dmitriy Pavlov  wrote:
>
> > Hi Prashant,
> >
> > Thank you for your interest in Apache Ignite. And I hope the Ignite
> > community would be glad to work with new contributors.
> >
> > Just one note: A company can not contribute to an Apache project, but
> your
> > employee(s) can contribute as an individual. Similar is true for
> > management, an employee can be a member of PMC, but the project is
> managed
> > not by companies but only by the project management committee.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > сб, 14 дек. 2019 г. в 05:27, Prashant Rahulkar <
> prashantrahul...@gmail.com
> > >:
> >
> > > Hello Everyone,
> > > I have started software firm in India, with complete motivation to
> focus
> > on
> > > open source technologies, so as a part of company policy we will star
> to
> > > contribute in this project with our company name.
> > >
> > >
> > > Thanks,
> > > PrashantR.
> > >
> >
>
>
> --
> ~ Rahul
>

Re: joining

[Prashant Rahulkar]

Hello  Dmitriy ,

Thanks for your clarification, definitely our employee will contribute with
riEquaiton.com official mail id.


Thanks,
Prashant Rahulkar.

On Sat, 14 Dec 2019 at 18:34, Dmitriy Pavlov  wrote:

> Hi Prashant,
>
> Thank you for your interest in Apache Ignite. And I hope the Ignite
> community would be glad to work with new contributors.
>
> Just one note: A company can not contribute to an Apache project, but your
> employee(s) can contribute as an individual. Similar is true for
> management, an employee can be a member of PMC, but the project is managed
> not by companies but only by the project management committee.
>
> Sincerely,
> Dmitriy Pavlov
>
> сб, 14 дек. 2019 г. в 05:27, Prashant Rahulkar  >:
>
> > Hello Everyone,
> > I have started software firm in India, with complete motivation to focus
> on
> > open source technologies, so as a part of company policy we will star to
> > contribute in this project with our company name.
> >
> >
> > Thanks,
> > PrashantR.
> >
>


-- 
~ Rahul

Re: joining

[Dmitriy Pavlov]

Hi Prashant,

Thank you for your interest in Apache Ignite. And I hope the Ignite
community would be glad to work with new contributors.

Just one note: A company can not contribute to an Apache project, but your
employee(s) can contribute as an individual. Similar is true for
management, an employee can be a member of PMC, but the project is managed
not by companies but only by the project management committee.

Sincerely,
Dmitriy Pavlov

сб, 14 дек. 2019 г. в 05:27, Prashant Rahulkar :

> Hello Everyone,
> I have started software firm in India, with complete motivation to focus on
> open source technologies, so as a part of company policy we will star to
> contribute in this project with our company name.
>
>
> Thanks,
> PrashantR.
>

Re: joining

[Prashant Rahulkar]

Hello Everyone,
I have started software firm in India, with complete motivation to focus on
open source technologies, so as a part of company policy we will star to
contribute in this project with our company name.


Thanks,
PrashantR.

Re: joining

[Ilya Kasnacheev]

Hello again!

I have added you to Contributors, you may now assign tickets to yourself.

Please read
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Regards,
-- 
Ilya Kasnacheev


чт, 12 дек. 2019 г. в 18:34, Ilya Kasnacheev :

> Hello!
>
> You will need to register on https://issues.apache.org/jira/ first.
>
> Please tell me when you do.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 12 дек. 2019 г. в 18:09, :
>
>> Hi Ilya,
>>
>> it’d be nice if it were rkoriakov
>>
>>
>>
>> Best regards,
>>
>> T-Systems RUS
>> Point of Production
>> Roman Koriakov
>> Software Developer
>> Kirova 11, Voronezh, Russia
>> Tel: + 7 473 200 15 30
>> E-mail: roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com>
>> http://www.t-systems.com<http://www.t-systems.ru/>
>>
>>
>>
>> -Original Message-
>> From: Ilya Kasnacheev 
>> Sent: Thursday, December 12, 2019 5:25 PM
>> To: dev 
>> Subject: Re: joining
>>
>>
>>
>> Hello!
>>
>>
>>
>> I will need an Apache JIRA username to add you to contributors. Can you
>> provide it?
>>
>>
>>
>> Regards,
>>
>> --
>>
>> Ilya Kasnacheev
>>
>>
>>
>>
>>
>> чт, 12 дек. 2019 г. в 17:20, > roman.koria...@t-systems.com>>:
>>
>>
>>
>> > Hi everyone,
>>
>> > I'd like to participate in this  project!
>>
>> >
>>
>> > Best regards,
>>
>> >
>>
>> > T-Systems RUS
>>
>> > Point of Production
>>
>> > Roman Koriakov
>>
>> > Software Developer
>>
>> > Kirova 11, Voronezh, Russia
>>
>> > Tel: + 7 473 200 15 30
>>
>> > E-mail: roman.koria...@t-systems.com> roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com%
>> 3cmailto:roman.koria...@t-systems.com>>
>>
>> > http://www.t-systems.com<http://www.t-systems.ru/<
>> http://www.t-systems.com%3chttp:/www.t-systems.ru/>>
>>
>> >
>>
>> >
>>
>

Re: joining

[Ilya Kasnacheev]

Hello!

You will need to register on https://issues.apache.org/jira/ first.

Please tell me when you do.

Regards,
-- 
Ilya Kasnacheev


чт, 12 дек. 2019 г. в 18:09, :

> Hi Ilya,
>
> it’d be nice if it were rkoriakov
>
>
>
> Best regards,
>
> T-Systems RUS
> Point of Production
> Roman Koriakov
> Software Developer
> Kirova 11, Voronezh, Russia
> Tel: + 7 473 200 15 30
> E-mail: roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com>
> http://www.t-systems.com<http://www.t-systems.ru/>
>
>
>
> -Original Message-
> From: Ilya Kasnacheev 
> Sent: Thursday, December 12, 2019 5:25 PM
> To: dev 
> Subject: Re: joining
>
>
>
> Hello!
>
>
>
> I will need an Apache JIRA username to add you to contributors. Can you
> provide it?
>
>
>
> Regards,
>
> --
>
> Ilya Kasnacheev
>
>
>
>
>
> чт, 12 дек. 2019 г. в 17:20,  roman.koria...@t-systems.com>>:
>
>
>
> > Hi everyone,
>
> > I'd like to participate in this  project!
>
> >
>
> > Best regards,
>
> >
>
> > T-Systems RUS
>
> > Point of Production
>
> > Roman Koriakov
>
> > Software Developer
>
> > Kirova 11, Voronezh, Russia
>
> > Tel: + 7 473 200 15 30
>
> > E-mail: roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com
> <mailto:roman.koria...@t-systems.com%3cmailto:roman.koria...@t-systems.com
> >>
>
> > http://www.t-systems.com<http://www.t-systems.ru/<
> http://www.t-systems.com%3chttp:/www.t-systems.ru/>>
>
> >
>
> >
>

RE: joining

[Roman.Koriakov]

Hi Ilya,

it’d be nice if it were rkoriakov



Best regards,

T-Systems RUS
Point of Production
Roman Koriakov
Software Developer
Kirova 11, Voronezh, Russia
Tel: + 7 473 200 15 30
E-mail: roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com>
http://www.t-systems.com<http://www.t-systems.ru/>



-Original Message-
From: Ilya Kasnacheev 
Sent: Thursday, December 12, 2019 5:25 PM
To: dev 
Subject: Re: joining



Hello!



I will need an Apache JIRA username to add you to contributors. Can you provide 
it?



Regards,

--

Ilya Kasnacheev





чт, 12 дек. 2019 г. в 17:20, 
mailto:roman.koria...@t-systems.com>>:



> Hi everyone,

> I'd like to participate in this  project!

>

> Best regards,

>

> T-Systems RUS

> Point of Production

> Roman Koriakov

> Software Developer

> Kirova 11, Voronezh, Russia

> Tel: + 7 473 200 15 30

> E-mail: 
> roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com%3cmailto:roman.koria...@t-systems.com>>

> http://www.t-systems.com<http://www.t-systems.ru/<http://www.t-systems.com%3chttp:/www.t-systems.ru/>>

>

>

Re: joining

[Ilya Kasnacheev]

Hello!

I will need an Apache JIRA username to add you to contributors. Can you
provide it?

Regards,
-- 
Ilya Kasnacheev


чт, 12 дек. 2019 г. в 17:20, :

> Hi everyone,
> I'd like to participate in this  project!
>
> Best regards,
>
> T-Systems RUS
> Point of Production
> Roman Koriakov
> Software Developer
> Kirova 11, Voronezh, Russia
> Tel: + 7 473 200 15 30
> E-mail: roman.koria...@t-systems.com
> http://www.t-systems.com
>
>

Re: Joining node validation failure event.

[Ivan Pavlukhin]

gt;>>>>> 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 :
> >>>>>>>>>>> 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 
> >>>>>>>>>>>>  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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>&

Re: Joining node validation failure event.

[Mikhail Petrov]

 will not it?

чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov :

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 
To: Andrey Gura 



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 
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
 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

Re: Joining node validation failure event.

[Ivan Pavlukhin]

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 
> >>>>>>>>>>  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 P

Re: Joining node validation failure event.

[Mikhail Petrov]

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 :

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  написал(а):

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, Николай Ижиков :

I think we also should provide the reason why join failed.


3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):

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 :

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 :

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  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 :

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.

[Ivan Pavlukhin]

>>>>>>
> >>>>>>>> On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov 
> >>>>>>>>  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 
> >>>>>>>>>> :
> >>>>>>>>>>> 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 
> >>>>>>>>>>> To: Andrey Gura 
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
>

Re: Joining node validation failure event.

[Mikhail Petrov]

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  написал(а):

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, Николай Ижиков :

I think we also should provide the reason why join failed.


3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):

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 :

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 :

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  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 :

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 
To: Andrey Gura 



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 bet

Re: Joining node validation failure event.

[Николай Ижиков]

Exception(s) from component(s) that don’t want node joined.

> 3 дек. 2019 г., в 12:39, Ivan Pavlukhin  написал(а):
> 
> 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, Николай Ижиков :
>> 
>> I think we also should provide the reason why join failed.
>> 
>>> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):
>>> 
>>> 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 :
>>>> 
>>>> 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 :
>>>>>> 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  
>>>>>>> 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

Re: Joining node validation failure event.

[Ivan Pavlukhin]

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, Николай Ижиков :
>
> I think we also should provide the reason why join failed.
>
> > 3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):
> >
> > 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 :
> >>
> >> 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 :
> >>>> 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  
> >>>>> 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
> >>>>

Re: Joining node validation failure event.

[Николай Ижиков]

I think we also should provide the reason why join failed.

> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):
> 
> 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 :
>> 
>> 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 :
>>>> 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  
>>>>> 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 :
>>>>>>>> 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
>

Re: Joining node validation failure event.

[Ivan Pavlukhin]

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 :
>
> 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 :
> >> 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  
> >>> 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 :
> >>>>>> 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 -

Re: Joining node validation failure event.

[Mikhail Petrov]

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 :

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  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 :

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 
To: Andrey Gura 



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 
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, Mik

Re: Joining node validation failure event.

[Ivan Pavlukhin]

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 :
>
> 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  
> > 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 :
> >>>> 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 
> >>>> To: Andrey Gura 
> >>>>
> >>>>
> >>>>
> >>>> 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 

Re: Joining node validation failure event.

[Mikhail Petrov]

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  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 :

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 
To: Andrey Gura 



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 
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
 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/ji

Re: Joining node validation failure event.

[Andrey Gura]

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  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 :
> >> 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 
> >> To: Andrey Gura 
> >>
> >>
> >>
> >> 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 
> >>> 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 n

Re: Joining node validation failure event.

[Mikhail Petrov]

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 :

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 
To: Andrey Gura 



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 
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
 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

Re: Re: Joining node validation failure event.

[Ivan Pavlukhin]

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 :
>
> 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 
> To: Andrey Gura 
>
>
>
> 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 
> > 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
> >>>  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

Fwd: Re: Joining node validation failure event.

[Mikhail Petrov]

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 
To: Andrey Gura 



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  
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 
 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

Re: Joining node validation failure event.

[Ivan Pavlukhin]

Hi Mikhail,

Interesting topic. Could you please shed some light how a node
validation failure can be handled? Immediately cannot imagine how one
can handle it.

чт, 21 нояб. 2019 г. в 14:17, Mikhail Petrov :
>
> 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  
> > 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

Re: Joining node validation failure event.

[Mikhail Petrov]

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  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

Re: Joining node validation failure event.

[Andrey Gura]

Hi, Mikhail!

Could you please describe the case for this new event?

On Wed, Nov 20, 2019 at 12:45 PM Mikhail Petrov  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
>

Re: Joining

[Denis Magda]

Mandhir,

Click on “subscribe” reference that is in the dev list row and send a message 
to the address pop up:
https://ignite.apache.org/community/resources.html#mail-lists

-
Denis

> On May 4, 2017, at 7:20 AM, Mandhir Gidda  wrote:
> 
> SUBSCRIBE

Re: joining exchange

[Semyon Boikov]

To send message to coordinator we need establish new connection, it is
preferably to use existing connections. Actually we tested this approach,
and on large clusters (> 200 nodes) it did not give start time improvments.

Thanks

On Wed, Apr 26, 2017 at 1:06 PM, ALEKSEY KUZNETSOV  wrote:

> Hi, Igntrs!
> When new node joins topology, it sends join TcpDiscoveryJoinRequestMessage
> to arbitrary node N1.
> If N1 is not coordinator, then it will resend to all nodes.
>
> Why doesn't N1 send the message directly to coordinator ?
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

Re: joining exchange

[Dmitriy Setrakyan]

On Wed, Apr 26, 2017 at 1:06 PM, ALEKSEY KUZNETSOV  wrote:

> Hi, Igntrs!
> When new node joins topology, it sends join TcpDiscoveryJoinRequestMessage
> to arbitrary node N1.
> If N1 is not coordinator, then it will resend to all nodes.
>
> Why doesn't N1 send the message directly to coordinator ?
>

It think that the joining node sends its join-request message to the IP
address that was provided by the IP Finder, possibly in the configuration.

--
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>