Mikhail, Yes I am fine with the approach.
ср, 4 дек. 2019 г. в 20:30, Mikhail Petrov <pmgheap....@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....@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 <vololo...@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, Николай Ижиков <nizhi...@apache.org>: > >>>>> I think we also should provide the reason why join failed. > >>>>> > >>>>>> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin <vololo...@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....@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....@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....@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....@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....@gmail.com> > >>>>>>>>>>>>> To: Andrey Gura <ag...@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....@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....@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
