I mean removing those configs from binary assembly, not from repository. On Tue, Dec 27, 2016 at 4:28 PM, Oleg Ostanin <oosta...@gridgain.com> wrote:
> Hello Igniters. > I think it would be better to remove some configuration files from > benchmarks/config: > > ignite-base-load-config.xml > ignite-cache-load-config.xml > ignite-failover-base-config.xml > ignite-failover-localhost-config.xml > benchmark-cache-load.properties > benchmark-cache-load-win.properties > benchmark-failover.properties > > because those configs do not relate to any of performance tests. > > On Tue, Dec 20, 2016 at 11:24 PM, Denis Magda <dma...@apache.org> wrote: > >> Summarized the discussion updating the ticket >> https://issues.apache.org/jira/browse/IGNITE-4212# < >> https://issues.apache.org/jira/browse/IGNITE-4212#> >> >> — >> Denis >> >> > On Dec 19, 2016, at 12:26 PM, Dmitriy Setrakyan <dsetrak...@apache.org> >> wrote: >> > >> > Sergey, >> > >> > I am not sure I like "extras". I am voting for "benchmarks" folder right >> > under the root folder. >> > >> > D. >> > >> > On Mon, Dec 19, 2016 at 12:07 PM, Sergey Kozlov <skoz...@gridgain.com> >> > wrote: >> > >> >> Formatting has cut lines: >> >> >> >> — apache_ignite_root_folder >> >> — bin >> >> — examples >> >> — extras >> >> — benchmarks >> >> — bin >> >> — src (benchmarks sources with pom.xml) >> >> — config >> >> — libs (compiled benchmarks) >> >> >> >> >> >> >> >> On Mon, Dec 19, 2016 at 11:04 PM, Sergey Kozlov <skoz...@gridgain.com> >> >> wrote: >> >> >> >>> Denis, >> >>> >> >>> Mostly yes. But I look ahead and think that we may include more >> things in >> >>> future than yardstick only. It's why I suggest something like that: >> >>> — apache_ignite_root_folder >> >>> — bin >> >>> — examples >> >>> — extras >> >>> — benchmarks >> >>> — bin >> >>> — src (benchmarks sources with pom.xml) >> >>> — config >> >>> — libs (compiled benchmarks) >> >>> >> >>> On Mon, Dec 19, 2016 at 10:15 PM, Denis Magda <dma...@apache.org> >> wrote: >> >>> >> >>>> Well, if to refer to Dmitriy suggestion we can have the following >> >>>> structure >> >>>> >> >>>> — apache_ignite_root_folder >> >>>> — examples >> >>>> — bin >> >>>> — benchmarks >> >>>> — bin >> >>>> — src (benchmarks sources with pom.xml) >> >>>> — config >> >>>> — libs (compiled benchmarks) >> >>>> >> >>>> Sergey, will it cover all the use case you’ve met previously? >> >>>> >> >>>> — >> >>>> Denis >> >>>> >> >>>>> On Dec 19, 2016, at 9:59 AM, Sergey Kozlov <skoz...@gridgain.com> >> >>>> wrote: >> >>>>> >> >>>>> Yardstick requires own scripts/configurations (/bin, /config, /libs) >> >> and >> >>>>> creates work/logs directory under yardstick root. "libs/optional" is >> >> for >> >>>>> optional modules but in general we can't say that for Yardstick. >> Also >> >> it >> >>>>> may break the current user understanding of "libs/optional" >> directory >> >> as >> >>>>> place for additonal functionality activated by copying in "libs". >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Mon, Dec 19, 2016 at 7:53 PM, Dmitriy Setrakyan < >> >>>> dsetrak...@apache.org> >> >>>>> wrote: >> >>>>> >> >>>>>> I would be against using libs/optional or libs/ folder for anything >> >>>>>> benchmark related. I am also against adding any yardstick libraries >> >>>> without >> >>>>>> providing code. >> >>>>>> >> >>>>>> In my view, if the community wants to include benchmarks in >> releases, >> >>>> then >> >>>>>> we should add a "benchmarks" folder, which provides everything >> >>>> benchmark >> >>>>>> related, from code to all the dependent libraries, and >> documentation >> >>>>>> instructions. >> >>>>>> >> >>>>>> D. >> >>>>>> >> >>>>>> On Mon, Dec 19, 2016 at 8:11 AM, Denis Magda <dma...@apache.org> >> >>>> wrote: >> >>>>>> >> >>>>>>> Actually, “libs/optional” is already a kind of extra for me. Why >> do >> >> we >> >>>>>>> need this new folder if “libs/optional” semantic works well? >> >>>>>>> >> >>>>>>> Is there anyone else who is concerned about “libs/optional”? If >> >>>> there’re >> >>>>>>> not, I would agree on this and get down to the implementation. >> >>>>>>> >> >>>>>>> — >> >>>>>>> Denis >> >>>>>>> >> >>>>>>>> On Dec 19, 2016, at 1:10 AM, Sergey Kozlov <skoz...@gridgain.com >> > >> >>>>>> wrote: >> >>>>>>>> >> >>>>>>>> Hi >> >>>>>>>> >> >>>>>>>> What's about to introduce the new root folder called 'extras' >> with >> >>>>>>>> subfolder 'ignite-yardstick' and put there yardstick binaries? >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Sun, Dec 18, 2016 at 10:02 PM, Denis Magda <dma...@apache.org >> > >> >>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> Dmitriy, >> >>>>>>>>> >> >>>>>>>>> Please have a look at IGNITE-4212 description ( >> >>>>>>> https://issues.apache.org/ >> >>>>>>>>> jira/browse/IGNITE-4212). >> >>>>>>>>> >> >>>>>>>>> The whole purpose of the ticket is to automate benchmarks >> >> execution >> >>>>>> for >> >>>>>>>>> the end user for a specific Ignite release. Now he/she needs to >> go >> >>>>>>> through >> >>>>>>>>> a number of steps like build, configure, run strictly following >> >>>>>> lengthy >> >>>>>>>>> Yardstick guidance. >> >>>>>>>>> >> >>>>>>>>> Ideally, once a specific release is downloaded it should be >> >> possible >> >>>>>> to >> >>>>>>>>> run a concrete benchmark with a ready-to-use script. The script >> >>>> needs >> >>>>>>>>> benchmarks' lib which makes sense to put under “libs/optional” >> >>>> folder. >> >>>>>>>>> >> >>>>>>>>> If someone wants to modify the source of an existed benchmark or >> >>>> add a >> >>>>>>> new >> >>>>>>>>> one then he/she needs to follow existed Yardstick guidance. So, >> no >> >>>>>> need >> >>>>>>> to >> >>>>>>>>> release benchmarks’s sources as a part of Ignite release. >> >>>>>>>>> >> >>>>>>>>> — >> >>>>>>>>> Denis >> >>>>>>>>> >> >>>>>>>>>> On Dec 18, 2016, at 7:08 AM, Dmitriy Setrakyan < >> >>>>>> dsetrak...@apache.org> >> >>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> On Sun, Dec 18, 2016 at 2:53 AM, Oleg Ostanin < >> >>>> oosta...@gridgain.com >> >>>>>>> >> >>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> Dmitriy, ignite-yardstick allows user to run plenty of useful >> >>>>>>> Yardstick >> >>>>>>>>>>> benchmarks, which can be used to check Ignite performance. >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> In that case, why would it be under the "libs" folder at all? >> Do >> >> we >> >>>>>>>>> really >> >>>>>>>>>> need to include benchmarks into Ignite? If yes, then I would >> >>>> create a >> >>>>>>>>>> benchmarks folder under "examples" and add all the benchmarks >> >>>> there. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On Fri, Dec 16, 2016 at 11:49 PM, Dmitriy Setrakyan < >> >>>>>>>>> dsetrak...@apache.org >> >>>>>>>>>>>> >> >>>>>>>>>>> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> Oleg, what does ignite-yardstick module do? >> >>>>>>>>>>>> >> >>>>>>>>>>>> On Fri, Dec 16, 2016 at 12:37 AM, Oleg Ostanin < >> >>>>>>> oosta...@gridgain.com> >> >>>>>>>>>>>> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>>> Hello Igniters! >> >>>>>>>>>>>>> I'm working on ticket IGNITE-4212 "Ignite Benchmarking >> >>>>>>> Simplification >> >>>>>>>>>>> and >> >>>>>>>>>>>>> Automation" and I'd like to ask your opinion about >> >>>>>> ignite-yardstick: >> >>>>>>>>>>>> where >> >>>>>>>>>>>>> do you think is the most appropriate place to put a compiled >> >>>>>>>>>>>>> ignite-yardstick module in the apache-ignite binary >> assembly? >> >> We >> >>>>>> can >> >>>>>>>>>>> put >> >>>>>>>>>>>> it >> >>>>>>>>>>>>> in the libs/optional along with an others optional >> libraries, >> >> or >> >>>>>> we >> >>>>>>>>> can >> >>>>>>>>>>>>> create a new directory named "tools" in the root directory >> and >> >>>> put >> >>>>>>>>>>>>> "ignite-yardstick" in it, or we can find another solution. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Best regards >> >>>>>>>>>>>>> Oleg >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Sergey Kozlov >> >>>>>>>> GridGain Systems >> >>>>>>>> www.gridgain.com >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Sergey Kozlov >> >>>>> GridGain Systems >> >>>>> www.gridgain.com >> >>>> >> >>>> >> >>> >> >>> >> >>> -- >> >>> Sergey Kozlov >> >>> GridGain Systems >> >>> www.gridgain.com >> >>> >> >> >> >> >> >> >> >> -- >> >> Sergey Kozlov >> >> GridGain Systems >> >> www.gridgain.com >> >> >> >> >
