Hi Yakov, Currently TC agents defended by Docker virtual network, that's why we don't see intersection between several clusters, but in case of any step aside (running several suites on one agent, running several tests on one machine and so on) we will have problems and return back to this conversation. I'm voting for simplifying and speeding up testing process. It will also reduce the number of copy-paste in ton of tests, where Vm Ip Finder is used explicitly. As developer I'm confusing when I see in a test VmIpFinder and in other test Multicast without any reason or comment. If you care about test coverage of MulticastIpFinder you can pick several suites where number of starting/stopping is most frequent and leave multicast there, but in general it's not necessary to have it everywhere.
2018-08-02 0:54 GMT+03:00 Yakov Zhdanov <yzhda...@gridgain.com>: > It should be true, otherwise we would have nodes from all agents > intersecting. No? > > And multicast IP finder is the defailt one, so I would not reduce its test > volume. > > Yakov Zhdanov > www.gridgain.com > > 2018-08-02 0:32 GMT+03:00 Dmitriy Pavlov <dpavlov....@gmail.com>: > > > Hi Yakov, > > > > Regarding Each TC agent use own multicast: I'm not sure it is true, TC > > admins tried to do so, but not succeded. > > > > One more reason is speed of tests run. Why do we need to scan something > if > > we always will connect localhost. TC tests do not use multicast in almost > > every test. > > > > Sincerely, > > Dmitriy Pavlov > > > > чт, 2 авг. 2018 г. в 0:27, Yakov Zhdanov <yzhda...@apache.org>: > > > > > I disagree. Probably, no change required. Each TC agent use own > multicast > > > group so nodes do not intersect. If any of the test does not properly > > clean > > > up and leaves nodes running this dhould be flagged as test fail which > is > > > the case. > > > > > > Please provide strong reasons to start with this. > > > > > > --Yakov > > > > > >
