Defining repositories for rally_tracks and rally_teams

[xandmaga (Alexandre Gomes)]

We are adopting elasticsearch in our organization, today we have one cluster, a few indexes and two projects that use this cluster. We've started the benchmarking process of the cluster a few time ago, we define some tracks and will need to define some teams too. Following the example on rally's github, I've created two repos in my gitlab's institution one for the tracks and one for the teams. My question is:

Instead of creating these two repos and leave the tracks and teams shared across the organization, is it better leave theirs definition inside the repositories of that two projects using the elasticsearch and for which the tracks and temas were created for? Or am I taking a better approach on creating those repos and putting the tracks and teams in them to be reused, if necessary, by other people in the organization?

Thanks.

[baz (Michael Basnight)]

The rally-teams and rally-tracks repos use a different branching model than the rally repo, because we use one Rally version on potentially multiple different Elasticsearch clusters over differing versions. So for us, it makes sense to split it into a different repo. If a new version of Elasticsearch comes out that has different settings, you could use these branches to test your dataset against it. I think this makes it worthwhile to follow a branching model that mirrors Elasticsearch, and you likely do not want to put that in a repository where you already have versioning defined. But this functionality is advanced, and not always needed. If you have just one Elasticsearch cluster, it may be overkill to want to test against different versions.

Teams are composable. Multiple teams can refer to the same base config. In this aspect, it might make sense to keep all of your teams in a single repository. But this is also advanced usage if you only have one Elasticsearch cluster you test against.

That said, If you don't think any other internal orgs will find use out of Rally, and will likely never create their own tracks or teams, and you likely wont use any versioning strategies like the aforementioned (they are optional), then in my opinion it is perfectly acceptable to have them just put right into your project next to your other code.

[xandmaga (Alexandre Gomes)]

In our case is very likely that other people create at least theirs own tracks. I think that creation of other teams will be more rare but it still can happen, so I'll keep these repositories separated. Thank you.

[Alvar1o]

You can define more than one repository for resolving dependencies!