Great addition in the tool set!
A separate repo would be better.
Grouping repos together only to be easier indexed does not seems to be a strong
supportive reason. Just my 2 cents.
- Yifan
- Yifan
From: Dinesh Joshi
Sent: Thursday, August 22, 2019 11:42 AM
To
+1 on a discrete repo.
Dinesh
> On Aug 22, 2019, at 9:14 AM, Michael Shuler wrote:
>
> CI git polling for changes on a separate repository (if/when CI is needed) is
> probably a better way to go. I don't believe there are any issues with INFRA
> on us having discrete repos, and creating them
Markus,
This is great and very helpful for anyone running Cassandra in production
and have peace of mind to roll out upgrades. Thank you !
*Director, Cloud Data Engineering*
*Regards,Roopa Tangirala*
On Thu, Aug 22, 2019 at 9:14 AM Michael Shuler
wrote:
> CI git polling for changes on a se
CI git polling for changes on a separate repository (if/when CI is
needed) is probably a better way to go. I don't believe there are any
issues with INFRA on us having discrete repos, and creating them with
the self-help web tool is quick and easy.
Thanks for the neat looking utility!
Michael
A different repo will be better
> On Aug 22, 2019, at 6:16 AM, Per Otterström
> wrote:
>
> Very powerful tool indeed, thanks for sharing!
>
> I believe it is best to keep tools like this in different repos since
> different tools will probably have different life cycles and tool chains.
>
Very powerful tool indeed, thanks for sharing!
I believe it is best to keep tools like this in different repos since different
tools will probably have different life cycles and tool chains. Yes, that could
be handled in a single repo, but with different repos we'd get natural
boundaries.
No hard preference on the repo, but just excited about this tool! Looking
forward to employing this for upgrade testing (very timely :))
On Thu, Aug 22, 2019 at 3:38 AM Sam Tunnicliffe wrote:
> My own weak preference would be for a dedicated repo in the first
> instance. If/when additional tools
My own weak preference would be for a dedicated repo in the first instance.
If/when additional tools are contributed we should look at co-locating common
stuff, but rushing toward a monorepo would be a mistake IMO.
> On 22 Aug 2019, at 11:10, Jeff Jirsa wrote:
>
> I weakly prefer contrib.
>
>
I weakly prefer contrib.
On Thu, Aug 22, 2019 at 12:09 PM Marcus Eriksson wrote:
> Hi, we are about to open source our tooling for comparing two cassandra
> clusters and want to get some feedback where to push it. I think the
> options are: (name bike-shedding welcome)
>
> 1. create repos/asf/c
Great addition! Thanks Marcus.
+1 for cassandra-compare as said by Jeremy.
We can also think about other features like:
- Comparing just the count between 2 tables. In some cases, It will be
enough to say that our copy is OK.
- Making a difference on a set of partition ==> This will avoid compa
It’s great to contribute such a tool. The change between 2.x and 3.0 brought a
translation layer from thrift to cql that is hard to validate on real clusters
without something like this. Thank you.
As for naming, perhaps cassandra-compare might be clearer as diff is an
overloaded word but that’
This is a great addition to our Cassandra validation framework/tools. I can
see many teams in the community get benefited from tooling like this.
I like the idea of the generic repo (repos/asf/cassandra-contrib.git
or *whatever
the name is*) for tools like this, for the following 2 main reasons.
12 matches
Mail list logo
