Giters

elastic / rally

Macrobenchmarking framework for Elasticsearch

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support --track-repository=https://github.com/user/repo

pquentin opened this issue · comments

commented

By default, Rally uses the default track repository to lookup a given track, load it and run it. To use a different track repository, you need two steps.

This is not going away, but to automate the use of Rally and allow quick experiments with different track repositories, the first step is annoying. We could instead allow users to invoke Rally with --track-repository=git@github.com:pquentin/rally-tracks.git or --track-repository=https://github.com/pquentin/rally-tracks. Rally would then infer that pquentin/rally-tracks is the label and clone the repository under ~/.rally/benchmarks/tracks/pquentin/rally-tracks.

Implementation notes

  • If having sub-directories is an issue, we can always try to make a single directory like pquentin_rally-tracks but we could run into ambiguity issues, such as pquentin_rally/tracks resolving to the same directory. Having sub-directories avoids thinking about those edge cases.
  • We need to be very clear about what URLs are supported.
    • Should it be only GitHub or allow eg. GitLab? It feels bad to restrict to GitHub but it's already a de-facto Rally dependency. Maybe restricting to user@host:user/repo.git and https://host/user/repo will work for more providers.
    • Only SSH or also HTTPS or event the git protocol? SSH is harder to use but with HTTPS you risk getting asked credentials which defeats the purpose of automation.
  • The track repository is currently read as cfg.opts("track", "repository.name") in GitTrackRepository.__init__ and used to fetch the url with cfg.opts("tracks", "%s.url" % repo_name, mandatory=False). This sounds like a good place to insert the above logic (possibly using a classmethod) to define the correct repo_name and remote_url.
commented
  • SSH is harder to use but with HTTPS you risk getting asked credentials which defeats the purpose of automation.

For environments relying on automation, we could recommend using something like:

$ git config --global url.ssh://git@github.com/.insteadOf https://github.com/
$ cat ~/.gitconfig
[url "ssh://git@github.com/"]
        insteadOf = https://github.com/

which automatically turns HTTPS to SSH