Re: IP Filtering in IPFinders

2021-04-27 Thread Valentin Kulichenko
Hi Atri,

I've noticed that you added the property to the IgniteConfiguration, but
it's applied only within the discovery. I feel like something is wrong here.

If this feature only relates to the discovery, then we should have the
configuration property on the TcpDiscoverySpi instead. Otherwise, the
filtering should be applied to all network components (although I'm not
necessarily sure what that would imply).

What do you think?

-Val

On Tue, Apr 27, 2021 at 2:00 AM Atri Sharma  wrote:

> Hi Val and Ilya,
>
> Thank you for taking the time to pursue this issue.
>
> I have raised a new PR for the discussed approach. Please see and let
> me know what you think:
>
> https://github.com/apache/ignite/pull/9048
>
> Regards,
>
> Atri
>
> On Thu, Apr 22, 2021 at 3:34 PM Ilya Kasnacheev
>  wrote:
> >
> > Hello!
> >
> > I'm still not fully convinced, but Val's approach sounds rational to me.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 22 апр. 2021 г. в 12:45, Atri Sharma :
> >
> > > Hello!
> > >
> > > I actually saw the shared container scenario being tried by somebody
> > > who wanted an external script to monitor all IPs being used by his
> > > clusters and hence thought of this idea. Another thing that came in
> > > was the Firewall blocking a few IP addresses, hence the idea.
> > >
> > > I feel that the footprint of this change is small, and can be useful
> > > for esoteric use cases too without really interfering in any existing
> > > code path. Val's suggestion seems the right way to go since it gives
> > > the functionality without much change.
> > >
> > > Thoughts?
> > >
> > > On Thu, Apr 22, 2021 at 2:47 PM Ilya Kasnacheev
> > >  wrote:
> > > >
> > > > Hello!
> > > >
> > > > AFAIK, a S3 container, Azure blob container, etc, is a relatively
> > > > lightweight entity, similar to a table in an SQL database. Why would
> > > > different clusters need to share the same discovery storage
> container?
> > > > When I tested Azure IP finder, it created several blob containers
> for me
> > > on
> > > > demand, based on the parameter passed to IP finder. If I wanted to
> have
> > > > more than one cluster it should have been seamless already.
> > > >
> > > > I can theoretically see how address filtering may be useful to remove
> > > > public / private addresses or Docker gateway address, but it is
> usually
> > > > handled by setting localHost setting, although requiring tuning it
> for
> > > each
> > > > instance individually. Overall benefit seems to small.
> > > >
> > > > This is why I am asking, do you have any specific scenario in mind
> where
> > > > this feature is an enabler? How did you arrive at the conclusion to
> go
> > > > forward with it?
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > чт, 22 апр. 2021 г. в 07:51, Atri Sharma :
> > > >
> > > > > Hi Val,
> > > > >
> > > > > Consider a scenario where multiple Ignite clusters are running and
> for
> > > > > operational ease (and also compliance, in some cases, e.g. to make
> > > > > auditing easier), people can configure cloud based IP finders to
> share
> > > > > the same container (blob container in Azure, S3 container in AWS
> etc).
> > > > >
> > > > > In such a case, IPs for all clusters will be in the same container.
> > > > > IPFinders of both the clusters will read the entire list. In this
> > > > > case, address filtering will help ignore the irrelevant IP
> addresses.
> > > > >
> > > > > Thank you for pointing me to the alternate direction. Let me
> research
> > > > > that and revert.
> > > > >
> > > > > Atri
> > > > >
> > > > > On Wed, Apr 21, 2021 at 10:46 PM Valentin Kulichenko
> > > > >  wrote:
> > > > > >
> > > > > > Hi Atri,
> > > > > >
> > > > > > Can you describe the scenario in a little more detail? What
> exactly
> > > do
> > > > > you
> > > > > > mean by a container shared by multiple clusters? What are the
> > > > > consequences
> > > > > > of this? How does the proposed solution solve the problem?
> > > > > >
> > > > > > Also, I would suggest revisiting the design - I'm not sure such
> > > filtering
> > > > > > should be done on the IP finder level. Why not do this on the SPI
> > > level
> > > > > > instead? I would simply add something like "addressFilter" to the
> > > > > > TcpDiscoverySpi. The filter can be a generic IgnitePredicate, so
> you
> > > will
> > > > > > be able to provide any implementations, including regex or
> anything
> > > else.
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Wed, Apr 21, 2021 at 9:04 AM Atri Sharma 
> wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > When a container is shared by multiple clusters, then this can
> be
> > > > > useful
> > > > > > > for filtering IPs.
> > > > > > >
> > > > > > > Also, things like VPC based barriers can be circumvented using
> this
> > > > > > > technique.
> > > > > > >
> > > > > > > On Wed, 21 Apr 2021, 15:49 Ilya Kasnacheev, <
> > > ilya.kasnach...@gmail.com
> > > > > >
> > > > > > > 

Re: Stop sending IGNITE Created e-mails to dev@

2021-04-27 Thread Pavel Pereslegin
Hello Ilya.

Could you please add me to "Contributors 1" too?

Thank you.

вт, 27 апр. 2021 г. в 18:51, Ilya Kasnacheev :
>
> Hello!
>
> I think that role names are per-JIRA global, we can't rename them on a per
> project basis.
>
> It exists for very large projects to put more contributors on, we don't use
> it so I changed its meaning. You can mention it on the wiki if you know
> where. I'm not sure if it belongs on "how to contribute" because most of
> new contributors don't need new issies feed.
>
> Slava, I have added you to the role also.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 27 апр. 2021 г. в 11:39, Dmitriy Pavlov :
>
> > I guess so. It was always not clear for me why do we have 'contributors 1'
> > role.
> >
> > It might worth to rename role itself to contibutors with notifications.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 26 апр. 2021 г., 13:01 Ivan Pavlukhin :
> >
> > > Hi Ilya,
> > >
> > > > I have added you to "Contributors 1" role. Everybody in this role will
> > > still get those "issue created" e-mail.
> > >
> > > Thank you for that!
> > >
> > > Should not we mention this tweak with "Contributors 1" role somewhere
> > > in advanced how-to-contribute page?
> > >
> > > 2021-04-26 12:28 GMT+03:00, Ilya Kasnacheev :
> > > > Hello!
> > > >
> > > > I have added you to "Contributors 1" role. Everybody in this role will
> > > > still get those "issue created" e-mail.
> > > >
> > > > Feel free in asking me to enlist.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > чт, 22 апр. 2021 г. в 18:16, Ivan Pavlukhin :
> > > >
> > > >> > All issues notifications are also sent to iss...@ignite.apache.org
> > so
> > > >> one can subscribe to this list in order to track the created tickets.
> > > >>
> > > >> Does not sound as useful advice. Issues list [1] looks like real
> > > >> scrapyard, I doubt that it can be usable for anyone in current flavor.
> > > >> Can we send only "Created" notifications there?
> > > >>
> > > >> [1] https://lists.apache.org/list.html?iss...@ignite.apache.org
> > > >>
> > > >> 2021-04-21 18:30 GMT+03:00, Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > > >:
> > > >> > Hello!
> > > >> >
> > > >> > INFRA ticket created:
> > > https://issues.apache.org/jira/browse/INFRA-21762
> > > >> >
> > > >> > I have asked to keep sending the created issue notifications for
> > > >> > "Contributors 1" role, which is empty at present. So if you wish to
> > > >> > keep
> > > >> > getting those e-mails, please add yourself to this role or tell me
> > to
> > > >> > do
> > > >> so
> > > >> > for you.
> > > >> >
> > > >> > Regards,
> > > >> > --
> > > >> > Ilya Kasnacheev
> > > >> >
> > > >> >
> > > >> > ср, 21 апр. 2021 г. в 17:59, Alexey Goncharuk <
> > > >> alexey.goncha...@gmail.com>:
> > > >> >
> > > >> >> I support the idea. All issues notifications are also sent to
> > > >> >> iss...@ignite.apache.org so one can subscribe to this list in
> > order
> > > to
> > > >> >> track the created tickets. The notifications trash the devlist
> > > archive
> > > >> UI
> > > >> >> and make it extremely difficult to navigate.
> > > >> >>
> > > >> >> вт, 20 апр. 2021 г. в 18:35, Ilya Kasnacheev
> > > >> >>  > > >> >:
> > > >> >>
> > > >> >> > Hello, Maxim!
> > > >> >> >
> > > >> >> > You are free to revert any commit which has led to any new stable
> > > >> >> > test
> > > >> >> > failure, or new flaky test that was non-flaky before.
> > > >> >> >
> > > >> >> > Just revert the change and reopen the ticket.
> > > >> >> >
> > > >> >> > The problem here is that it's very hard to detect on the spot,
> > most
> > > >> >> > of
> > > >> >> > MTCGA e-mails are false positives and even if they are not, it is
> > > >> >> > not
> > > >> >> > relevant for most of developers.
> > > >> >> >
> > > >> >> > WDYT? I'm also still waiting for more input.
> > > >> >> >
> > > >> >> > Regards,
> > > >> >> > --
> > > >> >> > Ilya Kasnacheev
> > > >> >> >
> > > >> >> >
> > > >> >> > ср, 14 апр. 2021 г. в 21:26, Maxim Muzafarov  > >:
> > > >> >> >
> > > >> >> > > +1 for new JIRA issues
> > > >> >> > > -1 for MTCGA notifications
> > > >> >> > >
> > > >> >> > > Why we should hide errors from the dev-list? Who should take
> > care
> > > >> >> > > of
> > > >> >> > > issues reported by MTCGA.Bot in this case?
> > > >> >> > > We must apply stricter rules for such issues: a commit leading
> > to
> > > >> >> > > an
> > > >> >> > > error must be reverted.
> > > >> >> > >
> > > >> >> > > On Wed, 14 Apr 2021 at 20:00, Denis Mekhanikov
> > > >> >> > > 
> > > >> >> > > wrote:
> > > >> >> > > >
> > > >> >> > > > Huge +1 to this.
> > > >> >> > > >
> > > >> >> > > > I've already brought up this topic in the past:
> > > >> >> > > >
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >>
> > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html
> > > >> >> > > > I hope some day newcomers won't need to set up their email
> > > >> >> > > > filters
> > > >> >> when
> > > >> 

Re: Stop sending IGNITE Created e-mails to dev@

2021-04-27 Thread Ilya Kasnacheev
Hello!

I think that role names are per-JIRA global, we can't rename them on a per
project basis.

It exists for very large projects to put more contributors on, we don't use
it so I changed its meaning. You can mention it on the wiki if you know
where. I'm not sure if it belongs on "how to contribute" because most of
new contributors don't need new issies feed.

Slava, I have added you to the role also.

Regards,
-- 
Ilya Kasnacheev


вт, 27 апр. 2021 г. в 11:39, Dmitriy Pavlov :

> I guess so. It was always not clear for me why do we have 'contributors 1'
> role.
>
> It might worth to rename role itself to contibutors with notifications.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 26 апр. 2021 г., 13:01 Ivan Pavlukhin :
>
> > Hi Ilya,
> >
> > > I have added you to "Contributors 1" role. Everybody in this role will
> > still get those "issue created" e-mail.
> >
> > Thank you for that!
> >
> > Should not we mention this tweak with "Contributors 1" role somewhere
> > in advanced how-to-contribute page?
> >
> > 2021-04-26 12:28 GMT+03:00, Ilya Kasnacheev :
> > > Hello!
> > >
> > > I have added you to "Contributors 1" role. Everybody in this role will
> > > still get those "issue created" e-mail.
> > >
> > > Feel free in asking me to enlist.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > чт, 22 апр. 2021 г. в 18:16, Ivan Pavlukhin :
> > >
> > >> > All issues notifications are also sent to iss...@ignite.apache.org
> so
> > >> one can subscribe to this list in order to track the created tickets.
> > >>
> > >> Does not sound as useful advice. Issues list [1] looks like real
> > >> scrapyard, I doubt that it can be usable for anyone in current flavor.
> > >> Can we send only "Created" notifications there?
> > >>
> > >> [1] https://lists.apache.org/list.html?iss...@ignite.apache.org
> > >>
> > >> 2021-04-21 18:30 GMT+03:00, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >:
> > >> > Hello!
> > >> >
> > >> > INFRA ticket created:
> > https://issues.apache.org/jira/browse/INFRA-21762
> > >> >
> > >> > I have asked to keep sending the created issue notifications for
> > >> > "Contributors 1" role, which is empty at present. So if you wish to
> > >> > keep
> > >> > getting those e-mails, please add yourself to this role or tell me
> to
> > >> > do
> > >> so
> > >> > for you.
> > >> >
> > >> > Regards,
> > >> > --
> > >> > Ilya Kasnacheev
> > >> >
> > >> >
> > >> > ср, 21 апр. 2021 г. в 17:59, Alexey Goncharuk <
> > >> alexey.goncha...@gmail.com>:
> > >> >
> > >> >> I support the idea. All issues notifications are also sent to
> > >> >> iss...@ignite.apache.org so one can subscribe to this list in
> order
> > to
> > >> >> track the created tickets. The notifications trash the devlist
> > archive
> > >> UI
> > >> >> and make it extremely difficult to navigate.
> > >> >>
> > >> >> вт, 20 апр. 2021 г. в 18:35, Ilya Kasnacheev
> > >> >>  > >> >:
> > >> >>
> > >> >> > Hello, Maxim!
> > >> >> >
> > >> >> > You are free to revert any commit which has led to any new stable
> > >> >> > test
> > >> >> > failure, or new flaky test that was non-flaky before.
> > >> >> >
> > >> >> > Just revert the change and reopen the ticket.
> > >> >> >
> > >> >> > The problem here is that it's very hard to detect on the spot,
> most
> > >> >> > of
> > >> >> > MTCGA e-mails are false positives and even if they are not, it is
> > >> >> > not
> > >> >> > relevant for most of developers.
> > >> >> >
> > >> >> > WDYT? I'm also still waiting for more input.
> > >> >> >
> > >> >> > Regards,
> > >> >> > --
> > >> >> > Ilya Kasnacheev
> > >> >> >
> > >> >> >
> > >> >> > ср, 14 апр. 2021 г. в 21:26, Maxim Muzafarov  >:
> > >> >> >
> > >> >> > > +1 for new JIRA issues
> > >> >> > > -1 for MTCGA notifications
> > >> >> > >
> > >> >> > > Why we should hide errors from the dev-list? Who should take
> care
> > >> >> > > of
> > >> >> > > issues reported by MTCGA.Bot in this case?
> > >> >> > > We must apply stricter rules for such issues: a commit leading
> to
> > >> >> > > an
> > >> >> > > error must be reverted.
> > >> >> > >
> > >> >> > > On Wed, 14 Apr 2021 at 20:00, Denis Mekhanikov
> > >> >> > > 
> > >> >> > > wrote:
> > >> >> > > >
> > >> >> > > > Huge +1 to this.
> > >> >> > > >
> > >> >> > > > I've already brought up this topic in the past:
> > >> >> > > >
> > >> >> > >
> > >> >> >
> > >> >>
> > >>
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html
> > >> >> > > > I hope some day newcomers won't need to set up their email
> > >> >> > > > filters
> > >> >> when
> > >> >> > > > they come to the developers list.
> > >> >> > > >
> > >> >> > > > Denis
> > >> >> > > >
> > >> >> > > > ср, 14 апр. 2021 г. в 18:07, Atri Sharma :
> > >> >> > > >
> > >> >> > > > > +1 to move issues to the issues list.
> > >> >> > > > >
> > >> >> > > > > For MTCGA, maybe build@?
> > >> >> > > > >
> > >> >> > > > > On Wed, Apr 14, 2021 at 8:35 PM Ilya Kasnacheev
> > >> >> > > > > 
> > >> >> > > wrote:
> > >> >> > > > > 

Re: Stop sending IGNITE Created e-mails to dev@

2021-04-27 Thread Вячеслав Коптилин
Hello Ilya,

Could you please add me to the "Contributors 1" role?

Thanks,
S.

пн, 26 апр. 2021 г. в 12:29, Ilya Kasnacheev :

> Hello!
>
> I have added you to "Contributors 1" role. Everybody in this role will
> still get those "issue created" e-mail.
>
> Feel free in asking me to enlist.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 22 апр. 2021 г. в 18:16, Ivan Pavlukhin :
>
> > > All issues notifications are also sent to iss...@ignite.apache.org so
> > one can subscribe to this list in order to track the created tickets.
> >
> > Does not sound as useful advice. Issues list [1] looks like real
> > scrapyard, I doubt that it can be usable for anyone in current flavor.
> > Can we send only "Created" notifications there?
> >
> > [1] https://lists.apache.org/list.html?iss...@ignite.apache.org
> >
> > 2021-04-21 18:30 GMT+03:00, Ilya Kasnacheev :
> > > Hello!
> > >
> > > INFRA ticket created:
> https://issues.apache.org/jira/browse/INFRA-21762
> > >
> > > I have asked to keep sending the created issue notifications for
> > > "Contributors 1" role, which is empty at present. So if you wish to
> keep
> > > getting those e-mails, please add yourself to this role or tell me to
> do
> > so
> > > for you.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > ср, 21 апр. 2021 г. в 17:59, Alexey Goncharuk <
> > alexey.goncha...@gmail.com>:
> > >
> > >> I support the idea. All issues notifications are also sent to
> > >> iss...@ignite.apache.org so one can subscribe to this list in order
> to
> > >> track the created tickets. The notifications trash the devlist archive
> > UI
> > >> and make it extremely difficult to navigate.
> > >>
> > >> вт, 20 апр. 2021 г. в 18:35, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >:
> > >>
> > >> > Hello, Maxim!
> > >> >
> > >> > You are free to revert any commit which has led to any new stable
> test
> > >> > failure, or new flaky test that was non-flaky before.
> > >> >
> > >> > Just revert the change and reopen the ticket.
> > >> >
> > >> > The problem here is that it's very hard to detect on the spot, most
> of
> > >> > MTCGA e-mails are false positives and even if they are not, it is
> not
> > >> > relevant for most of developers.
> > >> >
> > >> > WDYT? I'm also still waiting for more input.
> > >> >
> > >> > Regards,
> > >> > --
> > >> > Ilya Kasnacheev
> > >> >
> > >> >
> > >> > ср, 14 апр. 2021 г. в 21:26, Maxim Muzafarov :
> > >> >
> > >> > > +1 for new JIRA issues
> > >> > > -1 for MTCGA notifications
> > >> > >
> > >> > > Why we should hide errors from the dev-list? Who should take care
> of
> > >> > > issues reported by MTCGA.Bot in this case?
> > >> > > We must apply stricter rules for such issues: a commit leading to
> an
> > >> > > error must be reverted.
> > >> > >
> > >> > > On Wed, 14 Apr 2021 at 20:00, Denis Mekhanikov
> > >> > > 
> > >> > > wrote:
> > >> > > >
> > >> > > > Huge +1 to this.
> > >> > > >
> > >> > > > I've already brought up this topic in the past:
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html
> > >> > > > I hope some day newcomers won't need to set up their email
> filters
> > >> when
> > >> > > > they come to the developers list.
> > >> > > >
> > >> > > > Denis
> > >> > > >
> > >> > > > ср, 14 апр. 2021 г. в 18:07, Atri Sharma :
> > >> > > >
> > >> > > > > +1 to move issues to the issues list.
> > >> > > > >
> > >> > > > > For MTCGA, maybe build@?
> > >> > > > >
> > >> > > > > On Wed, Apr 14, 2021 at 8:35 PM Ilya Kasnacheev
> > >> > > > > 
> > >> > > wrote:
> > >> > > > > >
> > >> > > > > > Hello!
> > >> > > > > >
> > >> > > > > > We have a discussion on how to ensure best engagement in
> dev@
> > >> > list,
> > >> > > and
> > >> > > > > it
> > >> > > > > > seems that Issue Created emails from IGNITE project consume
> a
> > >> > > > > > lot
> > >> > of
> > >> > > > > screen
> > >> > > > > > space, it's hard to spot genuine discussions in
> > >> > > > > > https://lists.apache.org/list.html?dev@ignite.apache.org
> for
> > >> > > example.
> > >> > > > > >
> > >> > > > > > We already have issues@ mailing list. I propose that we
> stop
> > >> > > sending any
> > >> > > > > > JIRA emails to dev@. If anyone wishes to get just Created
> > >> emails,
> > >> > > they
> > >> > > > > can
> > >> > > > > > subscribe to these messages in their JIRA account settings.
> I
> > >> > imagine
> > >> > > > > most
> > >> > > > > > of you already filter these messages out, so you may need to
> > >> adjust
> > >> > > your
> > >> > > > > > filters slightly.
> > >> > > > > >
> > >> > > > > > A distant second is MTCGA messages, which are also
> > >> > > > > > autogenerated
> > >> > and
> > >> > > not
> > >> > > > > > informative for most readers of the channel, since they are
> at
> > >> best
> > >> > > > > > targeted at a single committer and at worst flaky.
> > >> > > > > >
> > >> > > > > > Where could we move those? What is your opinion here, on
> both
> > >> > 

Re: IP Filtering in IPFinders

2021-04-27 Thread Atri Sharma
Hi Val and Ilya,

Thank you for taking the time to pursue this issue.

I have raised a new PR for the discussed approach. Please see and let
me know what you think:

https://github.com/apache/ignite/pull/9048

Regards,

Atri

On Thu, Apr 22, 2021 at 3:34 PM Ilya Kasnacheev
 wrote:
>
> Hello!
>
> I'm still not fully convinced, but Val's approach sounds rational to me.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 22 апр. 2021 г. в 12:45, Atri Sharma :
>
> > Hello!
> >
> > I actually saw the shared container scenario being tried by somebody
> > who wanted an external script to monitor all IPs being used by his
> > clusters and hence thought of this idea. Another thing that came in
> > was the Firewall blocking a few IP addresses, hence the idea.
> >
> > I feel that the footprint of this change is small, and can be useful
> > for esoteric use cases too without really interfering in any existing
> > code path. Val's suggestion seems the right way to go since it gives
> > the functionality without much change.
> >
> > Thoughts?
> >
> > On Thu, Apr 22, 2021 at 2:47 PM Ilya Kasnacheev
> >  wrote:
> > >
> > > Hello!
> > >
> > > AFAIK, a S3 container, Azure blob container, etc, is a relatively
> > > lightweight entity, similar to a table in an SQL database. Why would
> > > different clusters need to share the same discovery storage container?
> > > When I tested Azure IP finder, it created several blob containers for me
> > on
> > > demand, based on the parameter passed to IP finder. If I wanted to have
> > > more than one cluster it should have been seamless already.
> > >
> > > I can theoretically see how address filtering may be useful to remove
> > > public / private addresses or Docker gateway address, but it is usually
> > > handled by setting localHost setting, although requiring tuning it for
> > each
> > > instance individually. Overall benefit seems to small.
> > >
> > > This is why I am asking, do you have any specific scenario in mind where
> > > this feature is an enabler? How did you arrive at the conclusion to go
> > > forward with it?
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > чт, 22 апр. 2021 г. в 07:51, Atri Sharma :
> > >
> > > > Hi Val,
> > > >
> > > > Consider a scenario where multiple Ignite clusters are running and for
> > > > operational ease (and also compliance, in some cases, e.g. to make
> > > > auditing easier), people can configure cloud based IP finders to share
> > > > the same container (blob container in Azure, S3 container in AWS etc).
> > > >
> > > > In such a case, IPs for all clusters will be in the same container.
> > > > IPFinders of both the clusters will read the entire list. In this
> > > > case, address filtering will help ignore the irrelevant IP addresses.
> > > >
> > > > Thank you for pointing me to the alternate direction. Let me research
> > > > that and revert.
> > > >
> > > > Atri
> > > >
> > > > On Wed, Apr 21, 2021 at 10:46 PM Valentin Kulichenko
> > > >  wrote:
> > > > >
> > > > > Hi Atri,
> > > > >
> > > > > Can you describe the scenario in a little more detail? What exactly
> > do
> > > > you
> > > > > mean by a container shared by multiple clusters? What are the
> > > > consequences
> > > > > of this? How does the proposed solution solve the problem?
> > > > >
> > > > > Also, I would suggest revisiting the design - I'm not sure such
> > filtering
> > > > > should be done on the IP finder level. Why not do this on the SPI
> > level
> > > > > instead? I would simply add something like "addressFilter" to the
> > > > > TcpDiscoverySpi. The filter can be a generic IgnitePredicate, so you
> > will
> > > > > be able to provide any implementations, including regex or anything
> > else.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Wed, Apr 21, 2021 at 9:04 AM Atri Sharma  wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > When a container is shared by multiple clusters, then this can be
> > > > useful
> > > > > > for filtering IPs.
> > > > > >
> > > > > > Also, things like VPC based barriers can be circumvented using this
> > > > > > technique.
> > > > > >
> > > > > > On Wed, 21 Apr 2021, 15:49 Ilya Kasnacheev, <
> > ilya.kasnach...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > What are the expected use cases for this feature? Can you please
> > > > > > elaborate?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > >
> > > > > > > ср, 21 апр. 2021 г. в 08:23, Atri Sharma :
> > > > > > >
> > > > > > > > Hi All,
> > > > > > > >
> > > > > > > > I have opened the following JIRA for the said topic:
> > > > > > > >
> > > > > > > > https://issues.apache.org/jira/browse/IGNITE-14606
> > > > > > > >
> > > > > > > > The concept is to filter IPs based on a pattern or a blocklist
> > in
> > > > > > > > IPFinders while consuming IPs. This is more pertinent for cloud
> > > > based
> > > > > > > > IPFinders since they can have shared 

Re: Empty test results for Security Test Suite ran against master branch on Team City

2021-04-27 Thread Dmitriy Pavlov
Up!

Folks, who is owner/expert for this suite?

We have a number of tests not running.

чт, 22 апр. 2021 г., 18:01 Dmitry Pavlov :

> Hi,
>
> I guess it 's not correct since master tests count is 0. No reason to run
> a suite without tests.
>
> Folks, why it could be the case? I've checked SUITE_NAME and suite in the
> code and it seems to be mached.
>
> Sincerely,
> Dmitriy Pavlov
>
> On 2021/04/22 14:29:37, Shishkov Ilya  wrote:
> > Hello, Igniters!
> >
> > As I see, there are no test results for Security Test Suite run against
> > 'master' branch [1], for 'ignite-2.10' Security tests results are present
> > as expected [2].
> > Is this situation correct?
> >
> > 1.
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Security/5977426?buildTab=log=1878=1579
> > 2.
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Security/5976111?buildTab=log=67783=1599.68439.68448
> >
>


Re: Stop sending IGNITE Created e-mails to dev@

2021-04-27 Thread Dmitriy Pavlov
I guess so. It was always not clear for me why do we have 'contributors 1'
role.

It might worth to rename role itself to contibutors with notifications.

Sincerely,
Dmitriy Pavlov

пн, 26 апр. 2021 г., 13:01 Ivan Pavlukhin :

> Hi Ilya,
>
> > I have added you to "Contributors 1" role. Everybody in this role will
> still get those "issue created" e-mail.
>
> Thank you for that!
>
> Should not we mention this tweak with "Contributors 1" role somewhere
> in advanced how-to-contribute page?
>
> 2021-04-26 12:28 GMT+03:00, Ilya Kasnacheev :
> > Hello!
> >
> > I have added you to "Contributors 1" role. Everybody in this role will
> > still get those "issue created" e-mail.
> >
> > Feel free in asking me to enlist.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 22 апр. 2021 г. в 18:16, Ivan Pavlukhin :
> >
> >> > All issues notifications are also sent to iss...@ignite.apache.org so
> >> one can subscribe to this list in order to track the created tickets.
> >>
> >> Does not sound as useful advice. Issues list [1] looks like real
> >> scrapyard, I doubt that it can be usable for anyone in current flavor.
> >> Can we send only "Created" notifications there?
> >>
> >> [1] https://lists.apache.org/list.html?iss...@ignite.apache.org
> >>
> >> 2021-04-21 18:30 GMT+03:00, Ilya Kasnacheev  >:
> >> > Hello!
> >> >
> >> > INFRA ticket created:
> https://issues.apache.org/jira/browse/INFRA-21762
> >> >
> >> > I have asked to keep sending the created issue notifications for
> >> > "Contributors 1" role, which is empty at present. So if you wish to
> >> > keep
> >> > getting those e-mails, please add yourself to this role or tell me to
> >> > do
> >> so
> >> > for you.
> >> >
> >> > Regards,
> >> > --
> >> > Ilya Kasnacheev
> >> >
> >> >
> >> > ср, 21 апр. 2021 г. в 17:59, Alexey Goncharuk <
> >> alexey.goncha...@gmail.com>:
> >> >
> >> >> I support the idea. All issues notifications are also sent to
> >> >> iss...@ignite.apache.org so one can subscribe to this list in order
> to
> >> >> track the created tickets. The notifications trash the devlist
> archive
> >> UI
> >> >> and make it extremely difficult to navigate.
> >> >>
> >> >> вт, 20 апр. 2021 г. в 18:35, Ilya Kasnacheev
> >> >>  >> >:
> >> >>
> >> >> > Hello, Maxim!
> >> >> >
> >> >> > You are free to revert any commit which has led to any new stable
> >> >> > test
> >> >> > failure, or new flaky test that was non-flaky before.
> >> >> >
> >> >> > Just revert the change and reopen the ticket.
> >> >> >
> >> >> > The problem here is that it's very hard to detect on the spot, most
> >> >> > of
> >> >> > MTCGA e-mails are false positives and even if they are not, it is
> >> >> > not
> >> >> > relevant for most of developers.
> >> >> >
> >> >> > WDYT? I'm also still waiting for more input.
> >> >> >
> >> >> > Regards,
> >> >> > --
> >> >> > Ilya Kasnacheev
> >> >> >
> >> >> >
> >> >> > ср, 14 апр. 2021 г. в 21:26, Maxim Muzafarov :
> >> >> >
> >> >> > > +1 for new JIRA issues
> >> >> > > -1 for MTCGA notifications
> >> >> > >
> >> >> > > Why we should hide errors from the dev-list? Who should take care
> >> >> > > of
> >> >> > > issues reported by MTCGA.Bot in this case?
> >> >> > > We must apply stricter rules for such issues: a commit leading to
> >> >> > > an
> >> >> > > error must be reverted.
> >> >> > >
> >> >> > > On Wed, 14 Apr 2021 at 20:00, Denis Mekhanikov
> >> >> > > 
> >> >> > > wrote:
> >> >> > > >
> >> >> > > > Huge +1 to this.
> >> >> > > >
> >> >> > > > I've already brought up this topic in the past:
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html
> >> >> > > > I hope some day newcomers won't need to set up their email
> >> >> > > > filters
> >> >> when
> >> >> > > > they come to the developers list.
> >> >> > > >
> >> >> > > > Denis
> >> >> > > >
> >> >> > > > ср, 14 апр. 2021 г. в 18:07, Atri Sharma :
> >> >> > > >
> >> >> > > > > +1 to move issues to the issues list.
> >> >> > > > >
> >> >> > > > > For MTCGA, maybe build@?
> >> >> > > > >
> >> >> > > > > On Wed, Apr 14, 2021 at 8:35 PM Ilya Kasnacheev
> >> >> > > > > 
> >> >> > > wrote:
> >> >> > > > > >
> >> >> > > > > > Hello!
> >> >> > > > > >
> >> >> > > > > > We have a discussion on how to ensure best engagement in
> >> >> > > > > > dev@
> >> >> > list,
> >> >> > > and
> >> >> > > > > it
> >> >> > > > > > seems that Issue Created emails from IGNITE project consume
> >> >> > > > > > a
> >> >> > > > > > lot
> >> >> > of
> >> >> > > > > screen
> >> >> > > > > > space, it's hard to spot genuine discussions in
> >> >> > > > > > https://lists.apache.org/list.html?dev@ignite.apache.org
> for
> >> >> > > example.
> >> >> > > > > >
> >> >> > > > > > We already have issues@ mailing list. I propose that we
> stop
> >> >> > > sending any
> >> >> > > > > > JIRA emails to dev@. If anyone wishes to get just Created
> >> >> emails,
> >> >> > > they
> >> >> > > > > can
> >> >> > > > > > subscribe to these