ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Kozlov <skoz...@gridgain.com>
Subject Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)
Date Mon, 19 Dec 2016 20:07:26 GMT
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 <skozlov@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 <dmagda@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 <skozlov@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 <
>> dsetrakyan@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 <dmagda@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 <skozlov@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 <dmagda@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 <
>> >> dsetrakyan@apache.org>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> On Sun, Dec 18, 2016 at 2:53 AM, Oleg Ostanin <
>> oostanin@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
<
>> >>>>> dsetrakyan@apache.org
>> >>>>>>>>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> Oleg, what does ignite-yardstick module do?
>> >>>>>>>>
>> >>>>>>>> On Fri, Dec 16, 2016 at 12:37 AM, Oleg Ostanin <
>> >>> oostanin@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message