Extend TcpDiscoveryVmIpFinder functionality

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Extend TcpDiscoveryVmIpFinder functionality

Sergey Kozlov
Hi Igniters

I found that TcpDiscoveryVmIpFinder could be improved for Spring
configuration by introducing new format: *address/mask:port(port range) or
address/prefix:port(port range)*. From my standpoint it will reduce the
efforts for ignite deployment and administration.
For instance if we've a dedicated network for the grid and not able to use
multicast way we should put each IP to the address list:

<property name="ipFinder">
  <bean
class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
    <property name="addresses">
      <list>
        <value>10.0.0.1:48500</value>
        <value>10.0.0.2:48500</value>
        <value>10.0.0.3:48500</value>
        ...
        <value>10.0.0.100:48500</value>
      </list>
    </property>
  </bean>
</property>

but can be simplified to

1) with using of the netmask

<property name="ipFinder">
  <bean
class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
    <property name="addresses">
      <list>
        <value>10.0.0.1/255.255.255.0:48500</value>
      </list>
    </property>
  </bean>
</property>

2) with using of the network prefix

<property name="ipFinder">
  <bean
class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
    <property name="addresses">
      <list>
        <value>10.0.0.1/24:48500</value>
      </list>
    </property>
  </bean>
</property>

Any comments/objections are welcome


--
Sergey Kozlov
Reply | Threaded
Open this post in threaded view
|

Re: Extend TcpDiscoveryVmIpFinder functionality

Vladimir Ozerov
Sergey,

This could be very dangerous in terms of node startup time. The very first
node in topology will have to scan the whole range trying to find any other
node. It might take significant time not only on Windows, but on Linux
environments as well, especially when some addresses are not available.

On Mon, Jan 9, 2017 at 12:25 PM, Sergey Kozlov <[hidden email]> wrote:

> Hi Igniters
>
> I found that TcpDiscoveryVmIpFinder could be improved for Spring
> configuration by introducing new format: *address/mask:port(port range) or
> address/prefix:port(port range)*. From my standpoint it will reduce the
> efforts for ignite deployment and administration.
> For instance if we've a dedicated network for the grid and not able to use
> multicast way we should put each IP to the address list:
>
> <property name="ipFinder">
>   <bean
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.
> TcpDiscoveryVmIpFinder">
>     <property name="addresses">
>       <list>
>         <value>10.0.0.1:48500</value>
>         <value>10.0.0.2:48500</value>
>         <value>10.0.0.3:48500</value>
>         ...
>         <value>10.0.0.100:48500</value>
>       </list>
>     </property>
>   </bean>
> </property>
>
> but can be simplified to
>
> 1) with using of the netmask
>
> <property name="ipFinder">
>   <bean
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.
> TcpDiscoveryVmIpFinder">
>     <property name="addresses">
>       <list>
>         <value>10.0.0.1/255.255.255.0:48500</value>
>       </list>
>     </property>
>   </bean>
> </property>
>
> 2) with using of the network prefix
>
> <property name="ipFinder">
>   <bean
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.
> TcpDiscoveryVmIpFinder">
>     <property name="addresses">
>       <list>
>         <value>10.0.0.1/24:48500</value>
>       </list>
>     </property>
>   </bean>
> </property>
>
> Any comments/objections are welcome
>
>
> --
> Sergey Kozlov
>
Reply | Threaded
Open this post in threaded view
|

Re: Extend TcpDiscoveryVmIpFinder functionality

yzhdanov
Agree with Vladimir.

However, this functionality maybe useful in some cases. As far as I
remember we support port range notation, e.g. 127.0.0.1:47500..47509, but
we don't have this for addresses. If we implement this I would suggest the
same approach, e.g 192.168.0.1..5:47500

Thoughts?

--Yakov
Reply | Threaded
Open this post in threaded view
|

Re: Extend TcpDiscoveryVmIpFinder functionality

Vladimir Ozerov
+1

On Mon, Jan 9, 2017 at 2:11 PM, Yakov Zhdanov <[hidden email]> wrote:

> Agree with Vladimir.
>
> However, this functionality maybe useful in some cases. As far as I
> remember we support port range notation, e.g. 127.0.0.1:47500..47509, but
> we don't have this for addresses. If we implement this I would suggest the
> same approach, e.g 192.168.0.1..5:47500
>
> Thoughts?
>
> --Yakov
>
Reply | Threaded
Open this post in threaded view
|

Re: Extend TcpDiscoveryVmIpFinder functionality

Sergey Kozlov
Hi

Thanks Yakov and Vladimir!

In general I'm ok for Yakov's suggestion though a bit not clear why
discovery by network mask will take long time. Is the discovery spi
single-threaded and Ignite processes the addresses consequentially?


On Mon, Jan 9, 2017 at 2:39 PM, Vladimir Ozerov <[hidden email]>
wrote:

> +1
>
> On Mon, Jan 9, 2017 at 2:11 PM, Yakov Zhdanov <[hidden email]> wrote:
>
> > Agree with Vladimir.
> >
> > However, this functionality maybe useful in some cases. As far as I
> > remember we support port range notation, e.g. 127.0.0.1:47500..47509,
> but
> > we don't have this for addresses. If we implement this I would suggest
> the
> > same approach, e.g 192.168.0.1..5:47500
> >
> > Thoughts?
> >
> > --Yakov
> >
>



--
Sergey Kozlov
GridGain Systems
www.gridgain.com
Reply | Threaded
Open this post in threaded view
|

Re: Extend TcpDiscoveryVmIpFinder functionality

dsetrakyan
On Mon, Jan 9, 2017 at 12:19 PM, Sergey Kozlov <[hidden email]> wrote:

> Hi
>
> Thanks Yakov and Vladimir!
>
> In general I'm ok for Yakov's suggestion though a bit not clear why
> discovery by network mask will take long time. Is the discovery spi
> single-threaded and Ignite processes the addresses consequentially?
>

Sergey, I think trying out every address within the mask will take a while.
I like Yakov's suggestion as well.


>
>
> On Mon, Jan 9, 2017 at 2:39 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > +1
> >
> > On Mon, Jan 9, 2017 at 2:11 PM, Yakov Zhdanov <[hidden email]>
> wrote:
> >
> > > Agree with Vladimir.
> > >
> > > However, this functionality maybe useful in some cases. As far as I
> > > remember we support port range notation, e.g. 127.0.0.1:47500..47509,
> > but
> > > we don't have this for addresses. If we implement this I would suggest
> > the
> > > same approach, e.g 192.168.0.1..5:47500
> > >
> > > Thoughts?
> > >
> > > --Yakov
> > >
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Extend TcpDiscoveryVmIpFinder functionality

yzhdanov
Guys, before I file a ticket - should we support range notation for each
byte in IP address? I think we should.

--Yakov
Reply | Threaded
Open this post in threaded view
|

Re: Extend TcpDiscoveryVmIpFinder functionality

Sergey Kozlov
I like the idea to use the full range notation like 10.0.0.1..10.0.0.100.
One issue we may face is the using of the addresses from different networks
like 10.0.0.201..10.0.1.100.

On Tue, Jan 10, 2017 at 1:35 PM, Yakov Zhdanov <[hidden email]> wrote:

> Guys, before I file a ticket - should we support range notation for each
> byte in IP address? I think we should.
>
> --Yakov
>



--
Sergey Kozlov
GridGain Systems
www.gridgain.com
Reply | Threaded
Open this post in threaded view
|

Re: Extend TcpDiscoveryVmIpFinder functionality

dmagda
If to do this as flexible as possible we can support ranges for every byte applying a format like the one below.

10.0.0.[1-10]
[10-11].0.0.[1-10]
128.[165-165].10.[1-100]

What do you think?


Denis
 

> On Jan 10, 2017, at 3:08 AM, Sergey Kozlov <[hidden email]> wrote:
>
> I like the idea to use the full range notation like 10.0.0.1..10.0.0.100.
> One issue we may face is the using of the addresses from different networks
> like 10.0.0.201..10.0.1.100.
>
> On Tue, Jan 10, 2017 at 1:35 PM, Yakov Zhdanov <[hidden email]> wrote:
>
>> Guys, before I file a ticket - should we support range notation for each
>> byte in IP address? I think we should.
>>
>> --Yakov
>>
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com

Reply | Threaded
Open this post in threaded view
|

Re: Extend TcpDiscoveryVmIpFinder functionality

Sergey Kozlov
Denis

The initial idea was to have a simple ability to put ip address ranges.
Probably we need to google how other products implement ip address ranges
in its (Spring) configurations.

On Thu, Jan 12, 2017 at 1:28 AM, Denis Magda <[hidden email]> wrote:

> If to do this as flexible as possible we can support ranges for every byte
> applying a format like the one below.
>
> 10.0.0.[1-10]
> [10-11].0.0.[1-10]
> 128.[165-165].10.[1-100]
>
> What do you think?
>
> —
> Denis
>
> > On Jan 10, 2017, at 3:08 AM, Sergey Kozlov <[hidden email]> wrote:
> >
> > I like the idea to use the full range notation like 10.0.0.1..10.0.0.100.
> > One issue we may face is the using of the addresses from different
> networks
> > like 10.0.0.201..10.0.1.100.
> >
> > On Tue, Jan 10, 2017 at 1:35 PM, Yakov Zhdanov <[hidden email]>
> wrote:
> >
> >> Guys, before I file a ticket - should we support range notation for each
> >> byte in IP address? I think we should.
> >>
> >> --Yakov
> >>
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
>
>


--
Sergey Kozlov
GridGain Systems
www.gridgain.com
Reply | Threaded
Open this post in threaded view
|

Re: Extend TcpDiscoveryVmIpFinder functionality

yzhdanov
I would prefer simple range notation with ".." - 192.168.0.1..192.168.2.100

For all other cases user may implement their own IP finder or initialize IP
finders we provide programmatically.

--Yakov

2017-01-12 11:37 GMT+03:00 Sergey Kozlov <[hidden email]>:

> Denis
>
> The initial idea was to have a simple ability to put ip address ranges.
> Probably we need to google how other products implement ip address ranges
> in its (Spring) configurations.
>
> On Thu, Jan 12, 2017 at 1:28 AM, Denis Magda <[hidden email]> wrote:
>
> > If to do this as flexible as possible we can support ranges for every
> byte
> > applying a format like the one below.
> >
> > 10.0.0.[1-10]
> > [10-11].0.0.[1-10]
> > 128.[165-165].10.[1-100]
> >
> > What do you think?
> >
> > —
> > Denis
> >
> > > On Jan 10, 2017, at 3:08 AM, Sergey Kozlov <[hidden email]>
> wrote:
> > >
> > > I like the idea to use the full range notation like
> 10.0.0.1..10.0.0.100.
> > > One issue we may face is the using of the addresses from different
> > networks
> > > like 10.0.0.201..10.0.1.100.
> > >
> > > On Tue, Jan 10, 2017 at 1:35 PM, Yakov Zhdanov <[hidden email]>
> > wrote:
> > >
> > >> Guys, before I file a ticket - should we support range notation for
> each
> > >> byte in IP address? I think we should.
> > >>
> > >> --Yakov
> > >>
> > >
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> >
> >
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>