Re: [VOTE] Accept java-driver

[Anthony Grasso]

+1 (nb)

Thank you to everyone involved for making this happen.

Regards,

On Wed, 4 Oct 2023 at 10:34, Nate McCall  wrote:

> +1
>
> On Tue, Oct 3, 2023 at 5:53 PM Mick Semb Wever  wrote:
>
>> The donation of the java-driver is ready for its IP Clearance vote.
>> https://incubator.apache.org/ip-clearance/cassandra-java-driver.html
>>
>> The SGA has been sent to the ASF.  This does not require acknowledgement
>> before the vote.
>>
>> Once the vote passes, and the SGA has been filed by the ASF Secretary, we
>> will request ASF Infra to move the datastax/java-driver as-is to
>> apache/java-driver
>>
>> This means all branches and tags, with all their history, will be kept.
>> A cleaning effort has already cleaned up anything deemed not needed.
>>
>> Background for the donation is found in CEP-8:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
>>
>> PMC members, please take note of (and check) the IP Clearance
>> requirements when voting.
>>
>> The vote will be open for 72 hours (or longer). Votes by PMC members are
>> considered binding. A vote passes if there are at least three binding +1s
>> and no -1's.
>>
>> regards,
>> Mick
>>
>

Re: [DISCUSS] New data type for vector search

[Anthony Grasso]

It would be strange for this declaration to look different from other
collection types. We may want to reconsider using the collection syntax. I
also like the idea of the vector dimensions being declared with the VECTOR
keyword. An alternative syntax option to explore is:

VECTOR[size]

On Fri, 28 Apr 2023 at 10:49, Josh McKenzie  wrote:

> From a machine learning perspective, vectors are a well-known concept that
> are effectively immutable fixed-length n-dimensional values that are then
> later used either as part of a model or in conjunction with a model after
> the fact.
>
> While we could have this be non-frozen and not call it a vector, I'd be
> inclined to still make the argument for a layer of syntactic sugar on top
> that met ML users where they were with concepts they understood rather than
> forcing them through the cognitive lift of figuring out the Cassandra
> specific contortions to replicate something that's ubiquitous in their
> space. We did the same "Cassandra-first" approach with our JSON support and
> that didn't do us any favors in terms of adoption and usage as far as I
> know.
>
> So is the goal here to provide something specific and idiomatic for the ML
> community or is the goal to make a primitive that's C*-centric that then
> another layer can write to? I personally argue for the former; I don't see
> this specific data type going away any time soon.
>
> On Thu, Apr 27, 2023, at 12:39 PM, David Capwell wrote:
>
> but as you point out it has the problem of allowing nulls.
>
>
> If nulls are not allowed for the elements, then either we need  a) a new
> type, or b) add some way to say elements may not be null…. As much as I do
> like b, I am leaning towards new type for this use case.
>
> So, to flesh out the type requirements I have seen so far
>
> 1) represents a fixed size array of element type
> * on write path we will need to validate this
> 2) element may not be null
> * on write path we will need to validate this
> 3) “frozen” (is this really a requirement for the type or is this
> just simpler for the ANN work?  I feel that this shouldn’t be a requirement)
> 4) works for all types (my requirement; original proposal is float only,
> but could logically expand to primitive types)
>
> Anything else?
>
> The key thing about a vector is that unlike lists or tuples you really
> don't care about individual elements, you care about doing vector and
> matrix multiplications with the thing as a unit.
>
>
> That maybe true for this use case, but “should” this be true for the type
> itself?  I feel like no… if a user wants the Nth element of a vector why
> would we block them?  I am not saying the first patch, or even 5.0 adds
> support for index access, I am just trying to push back saying that the
> type should not block this.
>
> (Maybe this is making the case for VECTOR FLOAT[N] rather than FLOAT
> VECTOR[N].)
>
>
> Now that nulls are not allowed, I have mixed feelings about FLOAT[N], I
> prefer this syntax but that limitation may not be desired for all use
> cases… we could always add LIST and ARRAY later
> to address that case.
>
> In terms of syntax I have seen, here is my ordered preference:
>
> 1) TYPE[size] - have mixed feelings due to non-null, but still prefer it
> 2) QUALIFIER TYPE[size] - QUALIFIER is just a Term we use to denote this
> semantic…. Could even be NON NULL TYPE[size]
>
> On Apr 27, 2023, at 9:00 AM, Benedict  wrote:
>
>
> That’s a bounded ring buffer, not a fixed length array.
>
> This definitely isn’t a tuple because the types are all the same, which is
> pretty crucial for matrix operations. Matrix libraries generally work on
> arrays of known dimensionality, or sparse representations.
>
> Whether we draw any semantic link between the frozen list and whatever we
> do here, it is fundamentally a frozen list with a restriction on its size.
> What we’re defining here are “statically” sized arrays, whereas a frozen
> list is essentially a dynamically sized array.
>
> I do not think vector is a good name because vector is used in some other
> popular languages to mean a (dynamic) list, which is confusing when we also
> have a list concept.
>
> I’m fine with just using the FLOAT[N] syntax, and drawing no direct link
> with list. Though it is a bit strange that this particular type declaration
> looks so different to other collection types.
>
> On 27 Apr 2023, at 16:48, Jeff Jirsa  wrote:
>
> 
>
>
> On Thu, Apr 27, 2023 at 7:39 AM Jonathan Ellis  wrote:
>
> It's been a while, so I may be missing something, but do we already have
> fixed-size lists?  If not, I don't see why we'd try to make this fit into a
> List-shaped problem.
>
>
> We do not. The proposal got closed as wont-fix
> https://issues.apache.org/jira/browse/CASSANDRA-9110
>
>
>
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Anthony Grasso]

Congratulations, Patrick!

Well deserved given all the work you do for the community.

Kind regards,

On Mon, 6 Feb 2023 at 11:39, Paulo Motta  wrote:

> Congratulations for this well deserved recognition, Patrick! Thank you for
> all the energy you inject into this community! :-)
>
> On Sun, Feb 5, 2023 at 7:17 PM Patrick McFadin  wrote:
>
>> Thank you everyone for all the well wishes here and in other parts of the
>> interwebs. It's always a privilege to work with the people in our community.
>>
>> Patrick
>>
>> On Fri, Feb 3, 2023 at 11:24 AM C. Scott Andreas 
>> wrote:
>>
>>> Congratulations, Patrick!
>>>
>>> On Feb 2, 2023, at 9:46 PM, Berenguer Blasi 
>>> wrote:
>>>
>>>
>>> Welcome!
>>> On 3/2/23 4:09, Vinay Chella wrote:
>>>
>>> Well deserved one, Congratulations, Patrick.
>>>
>>> On Fri, Feb 3, 2023 at 4:01 AM Josh McKenzie 
>>> wrote:
>>>
 Congrats Patrick! Well deserved.

 On Thu, Feb 2, 2023, at 5:25 PM, Molly Monroy wrote:

 Congrats, Patrick... much deserved!

 On Thu, Feb 2, 2023 at 1:59 PM Derek Chen-Becker 
 wrote:

 Congrats!

 On Thu, Feb 2, 2023 at 10:58 AM Benjamin Lerer 
 wrote:

 The PMC members are pleased to announce that Patrick McFadin has
 accepted
 the invitation to become committer today.

 Thanks a lot, Patrick, for everything you have done for this project
 and its community through the years.

 Congratulations and welcome!

 The Apache Cassandra PMC members



 --
 +---+
 | Derek Chen-Becker |
 | GPG Key available at https://keybase.io/dchenbecker and   |
 | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
 | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
 +---+


 --
>>>
>>>
>>> Thanks,
>>> Vinay Chella
>>>
>>>

Re: Should we change 4.1 to G1 and offheap_objects ?

[Anthony Grasso]

+1 to switching to G1 as well. Most production clusters I've seen are
typically running with a heap size of 16 GB or higher which works well with
G1.

I agree with Elliott's comment; I think this change should go into 4.1
onwards (i.e. no change to the default JVM settings in 4.0).

On Fri, 11 Nov 2022 at 08:50, Mick Semb Wever  wrote:

> In case of GC, reasonably extensive performance testing should be the
>> expectations. Potentially revisiting some of the G1 params for the 4.1
>> reality - quite a lot has changed since those optional defaults where
>> picked.
>>
>
>
> I've put our battle-tested g1 opts (from consultants at TLP and DataStax)
> in the patch for CASSANDRA-18027
>
> In reality it is really not much of a change, g1 does make it simple.
> Picking the correct ParallelGCThreads and ConcGCThreads and the floor to
> the new heap (XX:NewSize) is still required, though we could do a much
> better job of dynamic defaults to them.
>
> Alex Dejanovski's blog is a starting point:
> https://thelastpickle.com/blog/2020/06/29/cassandra_4-0_garbage_collectors_performance_benchmarks.html
> where this gc opt set was used (though it doesn't prove why those options
> are chosen)
>
> The bar for objection to sneaking these into 4.1 was intended to be low,
> and I stand by those that raise concerns.
>
>

Re: Thanks to Nate for his service as PMC Chair

[Anthony Grasso]

Thank you, Nate, for all the work you did! Congratulations Mick; you'll do
a great job!

On Tue, 12 Jul 2022 at 18:46, Benjamin Lerer  wrote:

> Thank you Nate for all your work! Congratulations Mick!
>
> Le mar. 12 juil. 2022 à 06:59, Berenguer Blasi 
> a écrit :
>
>> Thanks Nate and congrats Mick!
>> On 12/7/22 5:24, Charles Cao wrote:
>>
>> Thanks Nate and Congrats Mike for the new role!
>>
>> ~Charles
>>
>> On Jul 11, 2022, at 08:03, Mick Semb Wever 
>>  wrote:
>>
>> 
>> Thank you Nate, and Paulo and everyone!  
>>
>>
>> On Mon, 11 Jul 2022 at 15:57, Ekaterina Dimitrova 
>> wrote:
>>
>>> Thanks Nate and all the best with your new role Mick!
>>>
>>> On Mon, 11 Jul 2022 at 9:01, Jeremiah Jordan 
>>> wrote:
>>>
 Thanks Nate! And welcome to the role Mick!

 On Jul 11, 2022, at 7:54 AM, Paulo Motta  wrote:

 

 Hi,

 I wanted to announce on behalf of the Apache Cassandra Project
 Management Committee (PMC) that Nate McCall (zznate) has stepped down from
 the PMC chair role. Thank you Nate for all the work you did as the PMC
 chair!

 The Apache Cassandra PMC has nominated Mick Semb Wever (mck) as the new
 PMC chair. Congratulations and good luck on the new role Mick!

 The chair is an administrative position that interfaces with the Apache
 Software Foundation Board, by submitting regular reports about project
 status and health. Read more about the PMC chair role on Apache projects:
 - https://www.apache.org/foundation/how-it-works.html#pmc
 - https://www.apache.org/foundation/how-it-works.html#pmc-chair
 -
 https://www.apache.org/foundation/faq.html#why-are-PMC-chairs-officers

 The PMC as a whole is the entity that oversees and leads the project
 and any PMC member can be approached as a representative of the committee.
 A list of Apache Cassandra PMC members can be found on:
 https://cassandra.apache.org/_/community.html

 Kind regards,

 Paulo

Re: Adding RSS feed to the Apache Cassandra website.

[Anthony Grasso]

This is a good idea!

I think option 2 is the best way to go. Currently, there are manual steps
involved to publish a post to the blog. I would like to avoid adding more
manual work.

We could implement option 2 either by:

   - Bolting on JavaScript for Anotra to use to generate the RSS XML
   - Adding a Python script that gets called (probably after the HTML is
   generated) to generate the RSS XML

The Python script would be the easiest to implement and maintain.

Regards,

On Tue, 31 May 2022 at 10:12, Erick Ramirez 
wrote:

> Thanks for coordinating this. I'm happy to incorporate the manual process
> (option 1) in my workflow when reviewing/publishing blog PRs immediately as
> a quick solution if our intention is to go with option 2.
>
> FWIW by "workflow" I mean step 6 of the Pipeline Overview documented in
> the wiki here -- https://cwiki.apache.org/confluence/x/-6rkCw. Cheers!
>

Re: Welcome Aleksandr Sorokoumov as Cassandra committer

[Anthony Grasso]

Congratulations Aleksandr! Thank you for your work on the project.

On Thu, 17 Mar 2022 at 12:33, Erick Ramirez 
wrote:

> Congratulations Aleksandr and welcome aboard! 
>
> On Thu, 17 Mar 2022 at 00:15, Benjamin Lerer  wrote:
>
>> The PMC members are pleased to announce that Aleksandr Sorokoumov has
>> accepted
>> the invitation to become committer.
>>
>> Thanks a lot, Aleksandr , for everything you have done for the project.
>>
>> Congratulations and welcome
>>
>> The Apache Cassandra PMC members
>>
>

Re: [FOR REVIEW] Blog post: An Interview with Project Contributor, Lorina Poland

[Anthony Grasso]

+1

On Wed, 16 Mar 2022 at 21:58, bened...@apache.org 
wrote:

> +1
>
>
>
> *From: *Erick Ramirez 
> *Date: *Tuesday, 15 March 2022 at 22:08
> *To: *dev@cassandra.apache.org 
> *Subject: *Re: [FOR REVIEW] Blog post: An Interview with Project
> Contributor, Lorina Poland
>
> Looks good to me! 
>
>
>
> On Wed, 16 Mar 2022 at 08:17, Chris Thornett  wrote:
>
> As requested, I'm posting content contributions for community review on
> the ML for those that might not spot them on Slack.
>
>
>
> We're currently mid-review for our first contributor Q which is with
> Lorina Poland:
>
>
> https://docs.google.com/document/d/1nnH4V1XvTcfTeeUdZ_mjSxlNlWTbSXFu_qKtJRQUFBk/edit.
> Please add edits or suggests as comments.
>
>
>
> Thanks!
>
> --
>
>
>
> Chris Thornett
>
> senior content strategist, Constantia.io
>
> ch...@constantia.io
>
>

Re: [DISCUSS] Cleaning up docs, completing CASSANDRA-16763

[Anthony Grasso]

Hi Stefan and Ekaterina,

First point to note is CASSANDRA-16763 is now closed. A big thank you to
Lorina Poland for converting the Cassandra documentation from
reStructuredText to AsciiDoc and to Mick Semb Wever for working over the
holiday period to get the ticket over the line! We are now at a point where
we can start documentation back-porting work thanks to those efforts.

I do like Stefan's idea of tagging tickets that had documentation changes
with a label like "need-docs-backported". As Ekaterina points out, if we
reopen old tickets, this would get confusing to people unfamiliar with the
documentation work going on. The alternative is to create a new ticket for
each old ticket. From a practical perspective, I think labelling and
reopening an old ticket is the lesser of two evils.

However, we should approach this from the point of view of any other
piece of work in the project. That is, consider the case where ticket
CASSANDRA-xyz had a committed patch, was resolved, but was later found to
have an issue due to the implementation of a feature that was later added.
Would we reopen it to fix the problem or would we open a new ticket? Do we
have project guidelines around this? I would think in this scenario a new
ticket would be created?

In anycase, I feel we need to resolve the issue on how to track the work
first before we figure out how to divide it up.

Kind regards,
Anthony

On Thu, 14 Oct 2021 at 02:57, Ekaterina Dimitrova 
wrote:

> Hey Stefan,
>
> Thank you for your support and spending the time to think about this.
>
> If I understand you correctly, you suggest reopening the old tickets to
> finish the docs, I have two concerns:
> - we might work a few times on one and the same doc until we bring it to
> the latest state instead of getting a doc to latest state at once. I think
> that’s what Anthony was trying to take care of in his approach, to save
> some time? No?
> - Reopening old tickets which primary goal is not the docs brings more
> confusion, in my opinion.
>
> Otherwise, I think we have a required field for Testing and docs but
> splitting those in two and being more diligent around that might be a good
> idea?
>
> Thanks again,
> Ekaterina
>
> On Wed, 13 Oct 2021 at 3:27, Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
>
> > Hey,
> >
> > I got an idea how this might be simplified.
> >
> > Every commit in Cassandra repository belongs to a ticket (except
> > ninjas but they are irrelevant here).
> >
> > So if you look over the commits, what about looking at what Jira
> > ticket they belong to (this information is in each commit message) and
> > then go to that Jira and label that with "need-docs-backported" or
> > something like that?
> >
> > The idea here is that we can filter tickets like these and if we fix
> > it / backport it (under the same Jira ticket number), we will just
> > remove that label and the work is done if there are no tickets with
> > such label anymore.
> >
> > Hence we do not create any additional ticket at all, we may even
> > reopen tickets which are resolved now.
> >
> > Regards
> >
> > On Mon, 11 Oct 2021 at 01:06, Anthony Grasso 
> > wrote:
> > >
> > > Hi Stefan,
> > >
> > > I agree with your thoughts around grouping together changes touching a
> > > subsystem. This is exactly how I started doing the backporting work a
> few
> > > weeks ago. For example I started by looking at all the changes in the
> > > 'doc/source/architecture' folder of the rST docs, and back ported only
> > > those.
> > >
> > > I propose every subsection (child folder in doc/source/; e.g.
> > > 'architecture', 'configuration', 'cql') that has rST doc changes dating
> > > back to June 2020 has a ticket. Each ticket would list the commit
> hashes
> > > that need to be backported. For commit hashes that span multiple
> > > subsections we pick a single ticket for that hash to be done under.
> This
> > > will allow us to divide up the work fairly easily with minimal
> conflicts
> > > when merging.
> > >
> > > This process would need to be done for both Cassandra 3.11 and
> 4.0/trunk.
> > >
> > > We can use CASSANDRA-16761
> > > <https://issues.apache.org/jira/browse/CASSANDRA-16761> as the
> umbrella
> > > ticket for these changes. This epic was opened to capture all the work
> > > related to migrating from the old website and rTS docs to the new
> website
> > > and AsciiDoc. It is the ideal location for the tickets which will
> capture
> > > the backporting work.
> > >
> &g

Re: [DISCUSS] Cleaning up docs, completing CASSANDRA-16763

[Anthony Grasso]

Hi Stefan,

I agree with your thoughts around grouping together changes touching a
subsystem. This is exactly how I started doing the backporting work a few
weeks ago. For example I started by looking at all the changes in the
'doc/source/architecture' folder of the rST docs, and back ported only
those.

I propose every subsection (child folder in doc/source/; e.g.
'architecture', 'configuration', 'cql') that has rST doc changes dating
back to June 2020 has a ticket. Each ticket would list the commit hashes
that need to be backported. For commit hashes that span multiple
subsections we pick a single ticket for that hash to be done under. This
will allow us to divide up the work fairly easily with minimal conflicts
when merging.

This process would need to be done for both Cassandra 3.11 and 4.0/trunk.

We can use CASSANDRA-16761
<https://issues.apache.org/jira/browse/CASSANDRA-16761> as the umbrella
ticket for these changes. This epic was opened to capture all the work
related to migrating from the old website and rTS docs to the new website
and AsciiDoc. It is the ideal location for the tickets which will capture
the backporting work.

Kind regards,
Anthony



On Sat, 9 Oct 2021 at 04:02, Ekaterina Dimitrova 
wrote:

> Hey Stefan,
>
> Thank you for your response.
>
> “If it was feasible to gather all related changes touching a subsystem
> under one umbrella ticket, that would be very nice but I do not know
> if that makes sense from your point of view (what workflow you have).”
>
> It is up to us to decide what would be the most efficient way how to move
> forward as a community so any ideas are appreciated. I think Anthony had
> similar idea to what you said. Probably he can share more details.
>
> Best regards,
> Ekaterina
>
> On Thu, 7 Oct 2021 at 3:32, Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
>
> > Hi Lorina, Ekaterina,
> >
> > In general your approach sounds good to me. I am also +1 on not
> > creating too many tickets as I can see it will be easy to get lost in.
> >
> > If it was feasible to gather all related changes touching a subsystem
> > under one umbrella ticket, that would be very nice but I do not know
> > if that makes sense from your point of view (what workflow you have).
> >
> > Regards
> >
> > On Wed, 6 Oct 2021 at 23:56, Ekaterina Dimitrova 
> > wrote:
> > >
> > > Hey Lorina,
> > >
> > > First of all - thank you so much for all the work done by you and the
> > rest
> > > of the people! The website and the docs are our front door as a
> project!
> > >
> > > +1 on your proposal. My understanding is we need 1)+5) and then
> > everything
> > > else will be able to roll out and more people will be able to join the
> > > efforts so we can knock out 2) which seems the biggest work here, did I
> > get
> > > it correct?
> > >
> > > My only comment is about the tickets we will have to open. I can
> suggest
> > we
> > > don’t do 1:1 ticket for every small backport ticket/change but 1:1 for
> > > bigger bodies of work and 1:many where we see we can combine a few
> > smaller
> > > changes so we don’t deal with too many tickets. Does this sound
> > reasonable?
> > > Is there a different suggestion or plan?
> > >
> > > Thank you one more time. I will be happy to help with what I can do in
> > > order to bring this to the finish line. I am sure others will do too
> even
> > > with a ticket or two :-) In OSS every single contribution matter,
> right?
> > >
> > > Best regards,
> > > Ekaterina
> > >
> > > On Wed, 6 Oct 2021 at 8:22, Benjamin Lerer  wrote:
> > >
> > > > Thanks Lorina for all your work.
> > > >
> > > > +1 Your proposal makes sense to me.
> > > >
> > > > Le mer. 6 oct. 2021 à 00:34, Lorina Poland  a
> > écrit :
> > > >
> > > > > This is a discussion about how to tackle getting the docs “fixed”.
> > > > >
> > > > > As many of you know, I started months ago to convert the Apache
> > Cassandra
> > > > > in-tree docs
> > > > > from reStructedText (rST)to AsciiDoc. [1]
> > > > > The conversion required both the docs source files to be converted,
> > but
> > > > > also the cassandra-website
> > > > > source to be updated, to build the docs from AsciiDoc.[2] You all
> > have
> > > > seen
> > > > > the results of that
> > > > > conversion + the beautiful new design work accomplished.
> > >

Re: Supported upgrade path for 4.0

[Anthony Grasso]

Hi Josh,

This is a really good question. I agree with David about making sure this
is clearly documented.

As far as the supported upgrade path goes, I think we should officially
support only 3.11.x. I do understand the idea of giving users the
flexibility to upgrade from 3.0.x. However, the simpler we can make the
upgrade path the better. As you mentioned, historically there have been
numerous upgrade bugs. To that, having one upgrade path will make
maintenance and support easier.

Kind regards,

On Fri, 9 Oct 2020 at 07:36, David Capwell  wrote:

> Thanks for bringing this up, we really should document this and make sure
> the different upgrade paths are clearly documented and have proper
> coverage.
>
> There was a conversation in slack a while back (started from
> https://the-asf.slack.com/archives/CK23JSY2K/p1595906733435000) but not
> formal or voted on, but the current upgrade targets were 3.0.x and 3.11.x
> (do others feel we should support other versions as well and if so what?).
>
> For features, COMPACT STORAGE is getting a lot of attention right now, so
> would love to see clarity on how we go from a cluster with COMPACT STORAGE
> to 4.0 (is there min version support, what is the upgrade path, what about
> deleted rows, etc.).
>
> This is what I know about the current state of 4.0 upgrades at least.
>
> On Thu, Oct 8, 2020 at 11:48 AM Joshua McKenzie 
> wrote:
>
> > Related JIRA ticket:
> https://issues.apache.org/jira/browse/CASSANDRA-15588
> >
> > Description:
> >
> > "We've historically had numerous bugs concerning upgrading clusters from
> > one version to the other. Let's establish the supported upgrade path and
> > ensure that users can safely perform the upgrades in production."
> >
> > So the topic of discussion here: what is our supported upgrade path to
> 4.0?
> > Is this actually documented on our site or in our documentation? Spent a
> > few minutes poking around and didn't find anything.
> >
> > Anyone have an opinion here or any formal prior art for us to build on?
> >
>

Re: [DISCUSS] Updating the C* website design

[Anthony Grasso]

Hi Lorina and Mick,

I've raised CASSANDRA-16066
 to capture the
effort required to carry out the work of converting the markdown to
asciidoc. As part of the work, I think all content files should be moved to
cassandra/doc. This would give a clear separation of concerns;
 - cassandra/doc contains the material (asciidoc) that is converted to the
website content.
 - cassandra-website hosts the live content and contains all the UI
resources (html templates, css, js, images) that style the content.

Document authors only need to touch one repository to make content edits.
It also means they only need to run Antora in one location to generate the
content.

The proposal is a fairly common way of publishing content with Antora and
there are a number of examples out there of how to do this. Note, there
would be no alteration to design/content/layout of the website itself. The
only things changing would be the layout of the repositories and the tools
generating the content.

I'm happy to help with the changes if we think this is a good way to go.

Regards,
Anthony

On Thu, 6 Aug 2020 at 05:33, Lorina Poland  wrote:

> The one issue I see with your suggestion about versioned/non-versioned docs
> is that the cassandra/doc repo will have asciidoc files, and currently, all
> the items in the cassandra-website repo are in markdown. There are possible
> solutions (use antora for the website, put the non-versioned docs in their
> own repo which antora can use for building, for example), but that needs
> exploration.
>
> Lorina Poland
>
>
>
>
> On Wed, Aug 5, 2020 at 12:06 PM Michael Semb Wever  wrote:
>
> >
> >
> > > See that here:
> > >
> >
> https://docs.google.com/document/d/1aeNtgyPAsKcNa0GSKvl2ywlFEj30714ry4Sb5turWeE/edit?usp=sharing
> > >
> > > This outline is not complete, just my initial scribblings. Certainly
> > > collaboration would be welcome.
> >
> >
> > This is awesome Lorina. It would also be great to see all non-versioned
> > docs moved out of the cassandra repository and into the cassandra-website
> > repository (where they become easier to update).
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Committing `CASSANDRA-13701 Lower default num_tokens` and the dtest slowdown…

[Anthony Grasso]

Hi Mick,

No objections from me. It will be good to get this change into the 4.0
release.

Whilst the slow down of the dtests is annoying, I am happy to see this
change committed. As long as there are no regressions in the number of
tests that pass then it should be fine. The proposal to raise a follow up
ticket to accompany the commit is a good idea.

Regards,
Anthony

On Thu, 20 Aug 2020 at 02:49, Mick Semb Wever  wrote:

> It was agreed¹ that 4.0 should have the new configuration defaults of
>   num_tokens: 16
>   allocate_tokens_for_local_replication_factor: 3
>
> 13701's patches: against cassandra, cassandra-builds, cassandra-dtest, ccm;
> are reviewed, tested, and ready to commit. But the ccm and dtest patches
> required ccm having to now start nodes sequentially, and adding some longer
> timeout values in the dtests.
>
> The consequence of this is CI runs now take longer. ci-cassandra.a.o's
> dtests take ~30% longer, and circleci's dtests (with vnodes) have gone from
> ~22 to ~43 minutes. The general opinion (on slack²) is to commit, and work
> on improving ccm and dtest startup times in a subsequent ticket.
>
> 13701 was intended to be committed before the first beta release because of
> its user-facing changes. But these numbers are significant enough it makes
> sense to touch base with dev@
>
> Does anyone (strongly) object to the "commit + follow up ticket" approach?
>
> regards,
> Mick
>
>
> ¹ –
>
> https://lists.apache.org/thread.html/ra829084fcf344e9e96fa5c61cb31e909c8629091993471594b65ea89%40%3Cdev.cassandra.apache.org%3E
> ² – https://the-asf.slack.com/archives/CK23JSY2K/p1597747395032600 and
>
> https://the-asf.slack.com/archives/CK23JSY2K/p1597849774078200?thread_ts=1597762085.048300=CK23JSY2K
>

Re: Proof of concept for Cassandra docs conversion

[Anthony Grasso]

I agree as well. Nice work, Lorina!

This POC is a really good start. It has a bit more of a modern feel to it.
The navigation bar on the side makes the information very accessible. This
is a must for technical documentation.

Would it be possible to have a search bar somewhere on the site? I think
this would be useful to allow a user to navigate quickly to something they
know they are after e.g. a nodetool command or configuration setting.

Kind regards,

On Fri, 12 Jun 2020 at 02:02, Jon Haddad  wrote:

> Agreed.  This is an awesome POC in a pretty short period of time.
>
> I suspect with a little polish and cleanup this will be an improvement over
> the existing site in every way.
>
> Thanks for putting this together, Lorina!
>
> On Thu, Jun 11, 2020 at 7:36 AM Joshua McKenzie 
> wrote:
>
> > Left bar navigation and content navigation on top right are both
> > aesthetically and usability-wise quite superior IMO (comparing to
> > https://cassandra.apache.org/doc/latest/getting_started/configuring.html
> ).
> >
> > I'm a fan.
> >
> > On Wed, Jun 10, 2020 at 2:21 PM Lorina Poland 
> wrote:
> >
> > > Hello all!
> > >
> > > Based on an earlier discussion about moving the OSS C* docs to
> > > asciidoc, to allow more flexibility in maintaining the docs, I've done
> > > a proof of concept about what it would take to accomplish a
> > > conversion. I converted rSt files to asciidoc files using pandoc, did
> > > some additional editing, and use antora (antora.org) as a static site
> > > generator to build the docs. The result is here:
> > >
> > >
> >
> https://polandll.github.io/site/ASCIIDOC_POC/4.0/cassandra/getting_started/configuring.html#changing-the-location-of-directoriesThe
> > > editing of the docs is NOT complete, but I completed enough to feel
> > > confident that this process can be accomplished. Some YAML
> > > configuration for antora was required, and I did a minimum of UI
> > > configuration (added color banner, logo). Looking for feedback and
> > > questions anyone may have.
> > >
> > > Thanks,
> > >
> > > Lorina Poland (DataStax tech writer)
> > >
> >
>

Re: Staging website at cassandra.staged.apache.org

[Anthony Grasso]

Hi Murukesh,

That is a good question. To clarify, I meant that if we changed the site to
be serviced from the 'asf-site' branch the master branch would be cleaner
from that point forward.

However, now that you mention it, I do like the idea of cleaning the entire
master branch. Given that this alters the repository history, we might want
to do such a change in a phased approach. e.g.

1. Change production site to be served from 'asf-site' branch.
2. Make a copy of the master branch called master_archive (or something
similar) - this can be done sometime later after Step 1.
3. Clean master branch using bfg.
4. Keep the master_archive branch until we think it is no longer needed -
we could keep the branch anywhere from a few days to a few years.

Let me know what you think.

Regards,
Anthony

On Fri, 1 May 2020 at 18:18, Murukesh Mohanan 
wrote:

> For clarification, when you say "this would clean the master
> branch history", would the content directory be removed from past commits
> using bfg or similar tools?
>
> (I'm fine with either way; just curious.)
>
> On Fri, 1 May 2020, 07:12 Anthony Grasso, 
> wrote:
>
> > Hi everyone,
> >
> > Thanks to hard work by Mick every push to the cassandra-website *src/*
> > directory in master is now automatically deployed to
> > https://cassandra.staged.apache.org/. The automation is carried out by a
> > Jenkins job at https://ci-cassandra.apache.org/job/cassandra-website/.
> > This
> > is really useful because it allows us to preview our changes in the
> staging
> > site before we push them to the production site!
> >
> > With the above change in place, the process to deploy a change to the
> > production site is.
> > 1. Commit your change to the *src/* directory in the master branch.
> Jenkins
> > will now automatically generate the (HTML) site pages in *content/*
> > directory on the asf-staging branch.
> > 2. Preview your changes on the staging site:
> > https://cassandra.staged.apache.org/.
> > 3. If the changes look good, then merge the *content/* directory on the
> > asf-staging branch to the master branch using:
> >
> >
> > $ git merge asf-staging
> > $ git push
> >
> >
> > An issue with the above process is the master branch history is now going
> > to get polluted with the auto-generated content commits. Even without the
> > Jenkins automation, the process to publish to the production site still
> had
> > the issue where commits to the master branch included both the *src/* and
> > *content/* directory changes. A small one line change to the *src/*
> > directory, could result in changes to hundreds of pages in the *content/*
> > directory.
> >
> > Rather than serving the production site from the *content/* directory on
> > the master branch, is there any objection to serving it from the asf-site
> > branch? This would mean that the last step in the above process would be
> > performed on the asf-site branch rather than the master branch. In
> > addition, there would be no need to have a *content/* directory on the
> > master branch. The *content/* directory from which the production site is
> > served would live in the asf-site branch. This would clean the master
> > branch history, hiding the generated *content/* directory and the
> unwieldy
> > content changes generated by Jenkins user.
> >
> > Let me know what you think about the proposed change.
> >
> > Regards,
> > Anthony
> >
> > On Tue, 21 Apr 2020 at 16:40, Mick Semb Wever  wrote:
> >
> > > For our cassandra-website repository, any changes to our website can
> now
> > > first be staged at https://cassandra.staged.apache.org/
> > >
> > > The staged website comes from the content/ directory on the
> `asf-staging`
> > > branch.
> > >
> > > regards,
> > > Mick
> > >
> >
>

Re: Staging website at cassandra.staged.apache.org

[Anthony Grasso]

Hi everyone,

Thanks to hard work by Mick every push to the cassandra-website *src/*
directory in master is now automatically deployed to
https://cassandra.staged.apache.org/. The automation is carried out by a
Jenkins job at https://ci-cassandra.apache.org/job/cassandra-website/. This
is really useful because it allows us to preview our changes in the staging
site before we push them to the production site!

With the above change in place, the process to deploy a change to the
production site is.
1. Commit your change to the *src/* directory in the master branch. Jenkins
will now automatically generate the (HTML) site pages in *content/*
directory on the asf-staging branch.
2. Preview your changes on the staging site:
https://cassandra.staged.apache.org/.
3. If the changes look good, then merge the *content/* directory on the
asf-staging branch to the master branch using:


$ git merge asf-staging
$ git push


An issue with the above process is the master branch history is now going
to get polluted with the auto-generated content commits. Even without the
Jenkins automation, the process to publish to the production site still had
the issue where commits to the master branch included both the *src/* and
*content/* directory changes. A small one line change to the *src/*
directory, could result in changes to hundreds of pages in the *content/*
directory.

Rather than serving the production site from the *content/* directory on
the master branch, is there any objection to serving it from the asf-site
branch? This would mean that the last step in the above process would be
performed on the asf-site branch rather than the master branch. In
addition, there would be no need to have a *content/* directory on the
master branch. The *content/* directory from which the production site is
served would live in the asf-site branch. This would clean the master
branch history, hiding the generated *content/* directory and the unwieldy
content changes generated by Jenkins user.

Let me know what you think about the proposed change.

Regards,
Anthony

On Tue, 21 Apr 2020 at 16:40, Mick Semb Wever  wrote:

> For our cassandra-website repository, any changes to our website can now
> first be staged at https://cassandra.staged.apache.org/
>
> The staged website comes from the content/ directory on the `asf-staging`
> branch.
>
> regards,
> Mick
>

Re: [VOTE] Release Apache Cassandra 4.0-alpha3

[Anthony Grasso]

+1 (non-binding)

On Fri, 31 Jan 2020 at 08:48, Joshua McKenzie  wrote:

> +1
>
> On Thu, Jan 30, 2020 at 4:31 PM Brandon Williams  wrote:
>
> > +1
> >
> > On Thu, Jan 30, 2020 at 1:47 PM Mick Semb Wever  wrote:
> > >
> > > Proposing the test build of Cassandra 4.0-alpha3 for release.
> > >
> > > sha1: 5f7c88601c65cdf14ee68387ed68203f2603fc29
> > > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha3-tentative
> > > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1189/org/apache/cassandra/apache-cassandra/4.0-alpha3/
> > >
> > > The Source and Build Artifacts, and the Debian and RPM packages are
> > available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0-alpha3/
> > >
> > > The vote will be open for 72 hours (longer if needed). Everyone who has
> > tested the build is invited to vote. Votes by PMC members are considered
> > binding. A vote passes if there are at least three binding +1s.
> > >
> > > ** Please note this is my first time as release manager, and the
> release
> > process has been improved to deal with sha256|512 checksums as well as to
> > use the ASF dev dist staging location. So please be extra critical. **
> > >
> > >
> > > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha3-tentative
> > > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha3-tentative
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [Discuss] num_tokens default in Cassandra 4.0

[Anthony Grasso]

I think lowering the number of tokens is a great idea! Similar to Jon, when
I have reduced the number of tokens for clients it has been improvement in
repair performance.

I am concerned that the proposed default value for num_tokens is too low.
If you set up a cluster using the proposed defaults, you will get a
balanced cluster. However, if you decommission nodes you will start to see
large imbalances especially for small clusters (< 20 nodes). This is
because the allocate_tokens_for_local_replication_factor setting is only
applied during the bootstrap process.

I have recommended very low values for num_tokens to clients. This was
because it was very unlikely that they would reduce their cluster size and
I warned them of the caveats with using a small value for num_tokens.

The proposed num_token default value is fine for devs and operators that
know what they are doing. However, the general Cassandra community will be
unaware of the potential issue with such a low value. We should consider
setting num_tokens to 16 - 32 as the default. This will at least help
reduce the severity of the imbalance when decommissioning a node whilst
still providing the benefits of having a low number of tokens. In addition,
we can add a comment to num_tokens that clusters over 100 nodes (per
datacenter) should consider reducing it down to 4.

Cheers,
Anthony

On Fri, 31 Jan 2020 at 01:58, Jon Haddad  wrote:

> Larger clusters is where high token counts do the most damage. That's why
> it's such a problem. You start out with a small cluster using 256, as you
> grow into the hundreds it becomes more and more unstable.
>
>
> On Thu, Jan 30, 2020, 8:19 AM onmstester onmstester
>  wrote:
>
> > Shouldn't we consider the cluster size to configure num_tokens?
> >
> > For example is it OK to use num_tokens=4 for a cluster of more than 100
> of
> > nodes?
> >
> >
> >
> > Another question that is not so much relevant to this :
> >
> > When we use the token assignment algorithm (the new/non-random one) for a
> > specific keyspace, why should we use initial token for all the seeds,
> isn't
> > one seed enough and then just set the keyspace for all other nodes?
> >
> >
> >
> > Also i do not understand why should we consider rack topology and number
> > of racks for configuration of num_tokens?
> >
> >
> >
> > Sent using https://www.zoho.com/mail/
> >
> >
> >
> >
> >  On Thu, 30 Jan 2020 04:33:57 +0330 Jeremy Hanna <
> > jeremy.hanna1...@gmail.com> wrote 
> >
> >
> > The new default wouldn't be retroactively set for 3.x, but the same
> > principles apply.  The new algorithm is in 3.x as well as the
> > simplification of the configuration.  So no reason not to use the same
> > configuration on 3.x.
> >
> > > On Jan 30, 2020, at 4:34 AM, Chen-Becker, Derek  > dchen...@amazon.com.INVALID> wrote:
> > >
> > > Does the same guidance apply to 3.x clusters? I read through the JIRA
> > ticket linked below, along with tickets that it links to, but it's not
> > clear that the new allocation algorithm is available in 3.x or if there
> are
> > other reasons that this would be problematic.
> > >
> > > Thanks,
> > >
> > > Derek
> > >
> > > On 1/29/20, 9:54 AM, "Jon Haddad"  wrote:
> > >
> > >Ive put a lot of my previous clients on 4 tokens, all of which have
> > >resulted in a major improvement.
> > >
> > >I wouldn't use any more than 4 except under some pretty unusual
> > >circumstances.
> > >
> > >Jon
> > >
> > >On Wed, Jan 29, 2020, 11:18 AM Ben Bromhead  > b...@instaclustr.com> wrote:
> > >
> > >> +1 to reducing the number of tokens as low as possible for
> availability
> > >> issues. 4 lgtm
> > >>
> > >> On Wed, Jan 29, 2020 at 1:14 AM Dinesh Joshi  djo...@apache.org>
> > wrote:
> > >>
> > >>> Thanks for restarting this discussion Jeremy. I personally think 4 is
> > a
> > >>> good number as a default. I think whatever we pick, we should have
> > enough
> > >>> documentation for operators to make sense of the new defaults in 4.0.
> > >>>
> > >>> Dinesh
> > >>>
> >  On Jan 28, 2020, at 9:25 PM, Jeremy Hanna  > jeremy.hanna1...@gmail.com>
> > >>> wrote:
> > 
> >  I wanted to start a discussion about the default for num_tokens that
> > >>> we'd like for people starting in Cassandra 4.0.  This is for ticket
> > >>> CASSANDRA-13701 <
> https://issues.apache.org/jira/browse/CASSANDRA-13701>
> >
> > >>> (which has been duplicated a number of times, most recently by me).
> > 
> >  TLDR, based on availability concerns, skew concerns, operational
> > >>> concerns, and based on the fact that the new allocation algorithm can
> > be
> > >>> configured fairly simply now, this is a proposal to go with 4 as the
> > new
> > >>> default and the allocate_tokens_for_local_replication_factor set to
> 3.
> > >>> That gives a good experience out of the box for people and is the
> most
> > >>> conservative.  It does assume that racks and DCs have been configured
> > >>> correctly.  We would, 

Re: moving the site from SVN to git

[Anthony Grasso]

Hi Jon,

Thank you for actioning this!

The only trivial things that come to mind for me is to do with
documentation:

   - The README  file
   with the instructions to build the site points to SVN
   - The website Publication page
   
   and its source file
   

which
   point devs to the README file in SVN.

If we intend to keep SVN up for a while, I think it should be fine to move
the website over to the new Git repo. After the change over we could then
update the README file and website link. I am happy to make these changes
after we cut over to the Git repo.

Cheers,
Anthony

On Wed, 25 Sep 2019 at 06:44, Jon Haddad  wrote:

> While at apachecon I spoke with the folks at the INFRA desk to find out
> about moving the website from SVN to Git, and it's pretty straightforward.
> Here's the process:
>
> 1. Create a new Git repo fort the site
> 2. Copy the files over.  I don't think we care about history.  Unless
> someone speaks up, I'll just copy over what's current.
> 3. File a ticket and point them to the new repo
>
> Are there any dependencies currently pointing to the SVN repo that we'll
> need to update that would block me from taking care of this?
>
> Jon
>

Re: TLP tools for stress testing and building test clusters in AWS

[Anthony Grasso]

Hi Stefan.

Sorry for the late reply. Just wanted to close the loop on this.

Glad you found the demo useful.

On related node, we found out what the issues was when we were going
through the demo. It was to do with one of the AZs in our account being
unavailable. Even though AWS says an AZ exists, it may still be unavailable
for use. When provisioning a cluster, you might get an error like this in
the log:

aws_instance.cassandra.3: Error launching source instance: Unsupported:
> Your requested instance type (r3.2xlarge) is not supported in your
> requested Availability Zone (us-west-2d). Please retry your request by not
> specifying an Availability Zone or choosing us-west-2c, us-west-2a,
> us-west-2b.


To address this, we've added an --azs flag which can be used as a
workaround when an AZ unavailable. You can use it by supplying the letter
of the AZ you want. For example --azs abc.

Regards,
Anthony


On Wed, 17 Apr 2019 at 15:49, Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:

> Thanks Anthony for going that proverbial extra mile to cover people in
> different time zones too.
>
> I believe other people will find your talk as helpful as we did.
>
> Regards
>
> On Wed, 17 Apr 2019 at 10:08, Anthony Grasso 
> wrote:
> >
> > Hi Stefan and devs,
> >
> > I have set up a zoom link for the TLP tool set intro that will be on in
> an
> > hours time (17 April 2019 @ 11:00AM AEST): https://zoom.us/j/272648772
> >
> > This link is open so if anyone else wishes to join they are welcome to do
> > so. I will be covering the same topics Jon is covering in his meeting
> > tomorrow.
> >
> > Regards,
> > Anthony
> >
> >
> > On Wed, 17 Apr 2019 at 08:29, Anthony Grasso 
> > wrote:
> >
> > > Hi Stefan,
> > >
> > > Thanks for sending the invite out!
> > >
> > > Just wondering what do you think of the idea of having a Zoom meeting
> that
> > > anyone can join? This way anyone else interested can join us as well.
> I can
> > > set that up if you like?
> > >
> > > Cheers,
> > > Anthony
> > >
> > > On Tue, 16 Apr 2019 at 21:24, Stefan Miklosovic <
> > > stefan.mikloso...@instaclustr.com> wrote:
> > >
> > >> Hi Anthony,
> > >>
> > >> sounds good. I ve sent you Hangouts meeting invitation privately.
> > >>
> > >> Regards
> > >>
> > >> On Tue, 16 Apr 2019 at 14:53, Anthony Grasso <
> anthony.gra...@gmail.com>
> > >> wrote:
> > >> >
> > >> > Hi Stefan,
> > >> >
> > >> > I have been working with Jon on developing the tool set. I can do a
> Zoom
> > >> > call tomorrow (Wednesday) at 11am AEST if that works for you? We
> can go
> > >> > through all the same information that Jon is going to go through in
> his
> > >> > call. Note that I am in the same timezone as you, so if tomorrow
> > >> morning is
> > >> > no good we can always do the afternoon.
> > >> >
> > >> > Cheers,
> > >> > Anthony
> > >> >
> > >> >
> > >> > On Sat, 13 Apr 2019 at 22:38, Stefan Miklosovic <
> > >> > stefan.mikloso...@instaclustr.com> wrote:
> > >> >
> > >> > > Hi Jon,
> > >> > >
> > >> > > I would like be on that call too but I am off on Thursday.
> > >> > >
> > >> > > I am from Australia so 5pm London time is ours 2am next day so
> your
> > >> > > Wednesday morning is my Thursday night. Wednesday early morning so
> > >> > > your Tuesday morning and London's afternoon would be the best.
> > >> > >
> > >> > > Recording the thing would be definitely helpful too.
> > >> > >
> > >> > > On Sat, 13 Apr 2019 at 07:45, Jon Haddad 
> wrote:
> > >> > > >
> > >> > > > I'd be more than happy to hop on a call next week to give you
> both
> > >> > > > (and anyone else interested) a tour of our dev tools.  Maybe
> > >> something
> > >> > > > early morning on my end, which should be your evening, could
> work?
> > >> > > >
> > >> > > > I can set up a Zoom conference to get everyone acquainted.  We
> can
> > >> > > > record and post it for any who can't make it.
> > >> > > >
> > >> > > > I'm thinking Tue

Re: TLP tools for stress testing and building test clusters in AWS

[Anthony Grasso]

Hi Stefan and devs,

I have set up a zoom link for the TLP tool set intro that will be on in an
hours time (17 April 2019 @ 11:00AM AEST): https://zoom.us/j/272648772

This link is open so if anyone else wishes to join they are welcome to do
so. I will be covering the same topics Jon is covering in his meeting
tomorrow.

Regards,
Anthony


On Wed, 17 Apr 2019 at 08:29, Anthony Grasso 
wrote:

> Hi Stefan,
>
> Thanks for sending the invite out!
>
> Just wondering what do you think of the idea of having a Zoom meeting that
> anyone can join? This way anyone else interested can join us as well. I can
> set that up if you like?
>
> Cheers,
> Anthony
>
> On Tue, 16 Apr 2019 at 21:24, Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
>
>> Hi Anthony,
>>
>> sounds good. I ve sent you Hangouts meeting invitation privately.
>>
>> Regards
>>
>> On Tue, 16 Apr 2019 at 14:53, Anthony Grasso 
>> wrote:
>> >
>> > Hi Stefan,
>> >
>> > I have been working with Jon on developing the tool set. I can do a Zoom
>> > call tomorrow (Wednesday) at 11am AEST if that works for you? We can go
>> > through all the same information that Jon is going to go through in his
>> > call. Note that I am in the same timezone as you, so if tomorrow
>> morning is
>> > no good we can always do the afternoon.
>> >
>> > Cheers,
>> > Anthony
>> >
>> >
>> > On Sat, 13 Apr 2019 at 22:38, Stefan Miklosovic <
>> > stefan.mikloso...@instaclustr.com> wrote:
>> >
>> > > Hi Jon,
>> > >
>> > > I would like be on that call too but I am off on Thursday.
>> > >
>> > > I am from Australia so 5pm London time is ours 2am next day so your
>> > > Wednesday morning is my Thursday night. Wednesday early morning so
>> > > your Tuesday morning and London's afternoon would be the best.
>> > >
>> > > Recording the thing would be definitely helpful too.
>> > >
>> > > On Sat, 13 Apr 2019 at 07:45, Jon Haddad  wrote:
>> > > >
>> > > > I'd be more than happy to hop on a call next week to give you both
>> > > > (and anyone else interested) a tour of our dev tools.  Maybe
>> something
>> > > > early morning on my end, which should be your evening, could work?
>> > > >
>> > > > I can set up a Zoom conference to get everyone acquainted.  We can
>> > > > record and post it for any who can't make it.
>> > > >
>> > > > I'm thinking Tuesday, Wednesday, or Thursday morning, 9AM Pacific
>> (5pm
>> > > > London)?  If anyone's interested please reply with what dates work.
>> > > > I'll be sure to post the details back here with the zoom link in
>> case
>> > > > anyone wants to join that didn't get a chance to reply, as well as a
>> > > > link to the recorded call.
>> > > >
>> > > > Jon
>> > > >
>> > > > On Fri, Apr 12, 2019 at 10:41 AM Benedict Elliott Smith
>> > > >  wrote:
>> > > > >
>> > > > > +1
>> > > > >
>> > > > > I’m also just as excited to see some standardised workloads and
>> test
>> > > bed.  At the moment we’re benefiting from some large contributors
>> doing
>> > > their own proprietary performance testing, which is super valuable and
>> > > something we’ve lacked before.  But I’m also keen to see some more
>> > > representative workloads that are reproducible by anybody in the
>> community
>> > > take shape.
>> > > > >
>> > > > >
>> > > > > > On 12 Apr 2019, at 18:09, Aleksey Yeshchenko
>> > >  wrote:
>> > > > > >
>> > > > > > Hey Jon,
>> > > > > >
>> > > > > > This sounds exciting and pretty useful, thanks.
>> > > > > >
>> > > > > > Looking forward to using tlp-stress for validating 15066
>> performance.
>> > > > > >
>> > > > > > We should touch base some time next week to pick a
>> comprehensive set
>> > > of workloads and versions, perhaps?
>> > > > > >
>> > > > > >
>> > > > > >> On 12 Apr 2019, at 16:34, Jon Haddad 
>> wrote:
>> > > > > >>
>> > > > > >> I don't want t

Re: TLP tools for stress testing and building test clusters in AWS

[Anthony Grasso]

Hi Stefan,

Thanks for sending the invite out!

Just wondering what do you think of the idea of having a Zoom meeting that
anyone can join? This way anyone else interested can join us as well. I can
set that up if you like?

Cheers,
Anthony

On Tue, 16 Apr 2019 at 21:24, Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:

> Hi Anthony,
>
> sounds good. I ve sent you Hangouts meeting invitation privately.
>
> Regards
>
> On Tue, 16 Apr 2019 at 14:53, Anthony Grasso 
> wrote:
> >
> > Hi Stefan,
> >
> > I have been working with Jon on developing the tool set. I can do a Zoom
> > call tomorrow (Wednesday) at 11am AEST if that works for you? We can go
> > through all the same information that Jon is going to go through in his
> > call. Note that I am in the same timezone as you, so if tomorrow morning
> is
> > no good we can always do the afternoon.
> >
> > Cheers,
> > Anthony
> >
> >
> > On Sat, 13 Apr 2019 at 22:38, Stefan Miklosovic <
> > stefan.mikloso...@instaclustr.com> wrote:
> >
> > > Hi Jon,
> > >
> > > I would like be on that call too but I am off on Thursday.
> > >
> > > I am from Australia so 5pm London time is ours 2am next day so your
> > > Wednesday morning is my Thursday night. Wednesday early morning so
> > > your Tuesday morning and London's afternoon would be the best.
> > >
> > > Recording the thing would be definitely helpful too.
> > >
> > > On Sat, 13 Apr 2019 at 07:45, Jon Haddad  wrote:
> > > >
> > > > I'd be more than happy to hop on a call next week to give you both
> > > > (and anyone else interested) a tour of our dev tools.  Maybe
> something
> > > > early morning on my end, which should be your evening, could work?
> > > >
> > > > I can set up a Zoom conference to get everyone acquainted.  We can
> > > > record and post it for any who can't make it.
> > > >
> > > > I'm thinking Tuesday, Wednesday, or Thursday morning, 9AM Pacific
> (5pm
> > > > London)?  If anyone's interested please reply with what dates work.
> > > > I'll be sure to post the details back here with the zoom link in case
> > > > anyone wants to join that didn't get a chance to reply, as well as a
> > > > link to the recorded call.
> > > >
> > > > Jon
> > > >
> > > > On Fri, Apr 12, 2019 at 10:41 AM Benedict Elliott Smith
> > > >  wrote:
> > > > >
> > > > > +1
> > > > >
> > > > > I’m also just as excited to see some standardised workloads and
> test
> > > bed.  At the moment we’re benefiting from some large contributors doing
> > > their own proprietary performance testing, which is super valuable and
> > > something we’ve lacked before.  But I’m also keen to see some more
> > > representative workloads that are reproducible by anybody in the
> community
> > > take shape.
> > > > >
> > > > >
> > > > > > On 12 Apr 2019, at 18:09, Aleksey Yeshchenko
> > >  wrote:
> > > > > >
> > > > > > Hey Jon,
> > > > > >
> > > > > > This sounds exciting and pretty useful, thanks.
> > > > > >
> > > > > > Looking forward to using tlp-stress for validating 15066
> performance.
> > > > > >
> > > > > > We should touch base some time next week to pick a comprehensive
> set
> > > of workloads and versions, perhaps?
> > > > > >
> > > > > >
> > > > > >> On 12 Apr 2019, at 16:34, Jon Haddad  wrote:
> > > > > >>
> > > > > >> I don't want to derail the discussion about Stabilizing
> Internode
> > > > > >> Messaging, so I'm starting this as a separate thread.  There
> was a
> > > > > >> comment that Josh made [1] about doing performance testing with
> real
> > > > > >> clusters as well as a lot of microbenchmarks, and I'm 100% in
> > > support
> > > > > >> of this.  We've been working on some tooling at TLP for the last
> > > > > >> several months to make this a lot easier.  One of the goals has
> been
> > > > > >> to help improve the 4.0 testing process.
> > > > > >>
> > > > > >> The first tool we have is tlp-stress [2].  It's designed with a
> "get
> > > &g

Re: TLP tools for stress testing and building test clusters in AWS

[Anthony Grasso]

Hi Stefan,

I have been working with Jon on developing the tool set. I can do a Zoom
call tomorrow (Wednesday) at 11am AEST if that works for you? We can go
through all the same information that Jon is going to go through in his
call. Note that I am in the same timezone as you, so if tomorrow morning is
no good we can always do the afternoon.

Cheers,
Anthony


On Sat, 13 Apr 2019 at 22:38, Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:

> Hi Jon,
>
> I would like be on that call too but I am off on Thursday.
>
> I am from Australia so 5pm London time is ours 2am next day so your
> Wednesday morning is my Thursday night. Wednesday early morning so
> your Tuesday morning and London's afternoon would be the best.
>
> Recording the thing would be definitely helpful too.
>
> On Sat, 13 Apr 2019 at 07:45, Jon Haddad  wrote:
> >
> > I'd be more than happy to hop on a call next week to give you both
> > (and anyone else interested) a tour of our dev tools.  Maybe something
> > early morning on my end, which should be your evening, could work?
> >
> > I can set up a Zoom conference to get everyone acquainted.  We can
> > record and post it for any who can't make it.
> >
> > I'm thinking Tuesday, Wednesday, or Thursday morning, 9AM Pacific (5pm
> > London)?  If anyone's interested please reply with what dates work.
> > I'll be sure to post the details back here with the zoom link in case
> > anyone wants to join that didn't get a chance to reply, as well as a
> > link to the recorded call.
> >
> > Jon
> >
> > On Fri, Apr 12, 2019 at 10:41 AM Benedict Elliott Smith
> >  wrote:
> > >
> > > +1
> > >
> > > I’m also just as excited to see some standardised workloads and test
> bed.  At the moment we’re benefiting from some large contributors doing
> their own proprietary performance testing, which is super valuable and
> something we’ve lacked before.  But I’m also keen to see some more
> representative workloads that are reproducible by anybody in the community
> take shape.
> > >
> > >
> > > > On 12 Apr 2019, at 18:09, Aleksey Yeshchenko
>  wrote:
> > > >
> > > > Hey Jon,
> > > >
> > > > This sounds exciting and pretty useful, thanks.
> > > >
> > > > Looking forward to using tlp-stress for validating 15066 performance.
> > > >
> > > > We should touch base some time next week to pick a comprehensive set
> of workloads and versions, perhaps?
> > > >
> > > >
> > > >> On 12 Apr 2019, at 16:34, Jon Haddad  wrote:
> > > >>
> > > >> I don't want to derail the discussion about Stabilizing Internode
> > > >> Messaging, so I'm starting this as a separate thread.  There was a
> > > >> comment that Josh made [1] about doing performance testing with real
> > > >> clusters as well as a lot of microbenchmarks, and I'm 100% in
> support
> > > >> of this.  We've been working on some tooling at TLP for the last
> > > >> several months to make this a lot easier.  One of the goals has been
> > > >> to help improve the 4.0 testing process.
> > > >>
> > > >> The first tool we have is tlp-stress [2].  It's designed with a "get
> > > >> started in 5 minutes" mindset.  My goal was to ship a stress tool
> that
> > > >> ships with real workloads out of the box that can be easily tweaked,
> > > >> similar to how fio allows you to design a disk workload and tweak it
> > > >> with paramaters.  Included are stress workloads that stress LWTs
> (two
> > > >> different types), materialized views, counters, time series, and
> > > >> key-value workloads.  Each workload can be modified easily to change
> > > >> compaction strategies, concurrent operations, number of partitions.
> > > >> We can run workloads for a set number of iterations or a custom
> > > >> duration.  We've used this *extensively* at TLP to help our
> customers
> > > >> and most of our blog posts that discuss performance use it as well.
> > > >> It exports data to both a CSV format and auto sets up prometheus for
> > > >> metrics collection / aggregation.  As an example, we were able to
> > > >> determine that the compression length set on the paxos tables
> imposes
> > > >> a significant overhead when using the Locking LWT workload, which
> > > >> simulates locking and unlocking of rows.  See CASSANDRA-15080 for
> > > >> details.
> > > >>
> > > >> We have documentation [3] on the TLP website.
> > > >>
> > > >> The second tool we've been working on is tlp-cluster [4].  This tool
> > > >> is designed to help provision AWS instances for the purposes of
> > > >> testing.  To be clear, I don't expect, or want, this tool to be used
> > > >> for production environments.  It's designed to assist with the
> > > >> Cassandra build process by generating deb packages or re-using the
> > > >> ones that have already been uploaded.  Here's a short list of the
> > > >> things you'll care about:
> > > >>
> > > >> 1. Create instances in AWS for Cassandra using any instance size and
> > > >> number of nodes.  Also create tlp-stress instances and a box for
> > > >> monitoring
> > > >> 2. 

Re: [VOTE] Release Apache Cassandra 2.1.21

[Anthony Grasso]

Hi Michael,

What you and Jon said makes sense.

You have addressed a follow up concern I had about making sure the site was
updated if we go ahead with making 2.1 EOL. I'm happy to help with site
changes if needed.

Cheers,
Anthony

On Mon, 4 Feb 2019 at 11:31, Michael Shuler  wrote:

> My first couple sentences in the vote email were intended as a
> statement, based on a lack of concerns voiced on EOL of 2.1.
>
> I made a request for comment on EOL of 2.1 series a month ago, in
> "Subject: EOL 2.1 series?":
>
> https://lists.apache.org/thread.html/87ee2e3d13ea96744545ed8612496a93f8235747c4f60d0084b37bae@%3Cdev.cassandra.apache.org%3E
>
> Yes, I'm aware our download page states we support 2.1 until 4.0, but we
> do not really do so.
>
> The reality is that developers have been actively ignoring the branch,
> even when suggested to commit to the 2.1 branch. I can go dig up IRC
> logs and commits, but I really don't feel like it adds any value to the
> conversation. As Jonathan Haddad says, let's just be honest with users
> about what has already been happening independently.
>
> To continue stating we actively support 2.1 until 4.0 and actually
> follow through, the project should audit fixed bugs in 2.2+ and see if
> they still exist in 2.1, unfixed. I imagine there are a few. I know for
> sure of one that was not committed. Alternatively, we sunset the branch,
> make that change on the download page, and move on. I don't think it's
> right to continue telling users we are doing something, if we aren't and
> haven't been.
>
> Michael
>
> On 2/3/19 5:24 PM, Anthony Grasso wrote:
> > +1 non-binding, for the release of 2.1.21
> >
> > Regarding EOL of 2.1.x, did we announce in the past that 2.1.21 would be
> > the final release?
> >
> > According to the download <http://cassandra.apache.org/download/> page
> 2.1
> > is meant to be supported with critical fixes only until 4.0 is released.
> I
> > suspect that people may be relying on this, as I have seen a number 2.1.x
> > clusters still in production use.
> >
> > On Mon, 4 Feb 2019 at 07:09, Jonathan Haddad  wrote:
> >
> >> I think having the discussion around EOL is pretty important, in order
> to
> >> set the right expectations for the community.
> >>
> >> Looking at the commits for 2.1, there's hardly any activity going on,
> >> meaning it's effectively been EOL'ed for a long time now.  I think it's
> >> better that we be honest with folks about it.
> >>
> >> On Sun, Feb 3, 2019 at 9:34 AM Nate McCall  wrote:
> >>
> >>> +1 on the release of 2.1.21 (let's focus on that in the spirit of
> >>> these other votes we have up right now).
> >>>
> >>> I don't feel the need to be absolutist about something being EOL.
> >>>
> >>> On Sun, Feb 3, 2019 at 1:47 AM Stefan Podkowinski 
> >> wrote:
> >>>>
> >>>> What are we voting on here? Releasing the 2.1.21 candidate, or that
> 2.1
> >>>> would become EOL? Please let's have separate votes on that, if you
> want
> >>>> to propose putting 2.1 EOL (which I'm strongly -1).
> >>>>
> >>>>
> >>>> On 03.02.19 01:32, Michael Shuler wrote:
> >>>>> *EOL* release for the 2.1 series. There will be no new releases from
> >>> the
> >>>>> 'cassandra-2.1' branch after this release.
> >>>>>
> >>>>> 
> >>>>>
> >>>>> I propose the following artifacts for release as 2.1.21.
> >>>>>
> >>>>> sha1: 9bb75358dfdf1b9824f9a454e70ee2c02bc64a45
> >>>>> Git:
> >>>>>
> >>>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.21-tentative
> >>>>> Artifacts:
> >>>>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1173/org/apache/cassandra/apache-cassandra/2.1.21/
> >>>>> Staging repository:
> >>>>>
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1173/
> >>>>>
> >>>>> The Debian and RPM packages are available here:
> >>>>> http://people.apache.org/~mshuler
> >>>>>
> >>>>> The vote will be open for 72 hours (longer if needed).
> >>>>>
> >>>>> [1]: CHANGES.txt:
> >>>>>
> >>>
> >>
> https://gitbox.apache.org/repo

Re: [VOTE] Release Apache Cassandra 2.1.21

[Anthony Grasso]

+1 non-binding, for the release of 2.1.21

Regarding EOL of 2.1.x, did we announce in the past that 2.1.21 would be
the final release?

According to the download  page 2.1
is meant to be supported with critical fixes only until 4.0 is released. I
suspect that people may be relying on this, as I have seen a number 2.1.x
clusters still in production use.

On Mon, 4 Feb 2019 at 07:09, Jonathan Haddad  wrote:

> I think having the discussion around EOL is pretty important, in order to
> set the right expectations for the community.
>
> Looking at the commits for 2.1, there's hardly any activity going on,
> meaning it's effectively been EOL'ed for a long time now.  I think it's
> better that we be honest with folks about it.
>
> On Sun, Feb 3, 2019 at 9:34 AM Nate McCall  wrote:
>
> > +1 on the release of 2.1.21 (let's focus on that in the spirit of
> > these other votes we have up right now).
> >
> > I don't feel the need to be absolutist about something being EOL.
> >
> > On Sun, Feb 3, 2019 at 1:47 AM Stefan Podkowinski 
> wrote:
> > >
> > > What are we voting on here? Releasing the 2.1.21 candidate, or that 2.1
> > > would become EOL? Please let's have separate votes on that, if you want
> > > to propose putting 2.1 EOL (which I'm strongly -1).
> > >
> > >
> > > On 03.02.19 01:32, Michael Shuler wrote:
> > > > *EOL* release for the 2.1 series. There will be no new releases from
> > the
> > > > 'cassandra-2.1' branch after this release.
> > > >
> > > > 
> > > >
> > > > I propose the following artifacts for release as 2.1.21.
> > > >
> > > > sha1: 9bb75358dfdf1b9824f9a454e70ee2c02bc64a45
> > > > Git:
> > > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.21-tentative
> > > > Artifacts:
> > > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1173/org/apache/cassandra/apache-cassandra/2.1.21/
> > > > Staging repository:
> > > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1173/
> > > >
> > > > The Debian and RPM packages are available here:
> > > > http://people.apache.org/~mshuler
> > > >
> > > > The vote will be open for 72 hours (longer if needed).
> > > >
> > > > [1]: CHANGES.txt:
> > > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
> > > > [2]: NEWS.txt:
> > > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>

Re: [VOTE] Release Apache Cassandra 3.0.18

[Anthony Grasso]

+1 non-binding

On Mon, 4 Feb 2019 at 05:52, Jonathan Haddad  wrote:

> +1
>
> On Sun, Feb 3, 2019 at 9:44 AM Nate McCall  wrote:
>
> > On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler 
> > wrote:
> > >
> > > I propose the following artifacts for release as 3.0.18.
> > >
> > > sha1: edd52cef50a6242609a20d0d84c8eb74c580035e
> > > Git:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.18-tentative
> > > Artifacts:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1171/org/apache/cassandra/apache-cassandra/3.0.18/
> > > Staging repository:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1171/
> > >
> > > The Debian and RPM packages are available here:
> > > http://people.apache.org/~mshuler
> > >
> > > The vote will be open for 72 hours (longer if needed).
> > >
> > > [1]: CHANGES.txt:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-tentative
> > > [2]: NEWS.txt:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-tentative
> > >
> >
> > +1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>

Re: [VOTE] Release Apache Cassandra 3.11.4

[Anthony Grasso]

+1 non-binding

On Mon, 4 Feb 2019 at 06:19, Jonathan Haddad  wrote:

> +1
>
> On Sun, Feb 3, 2019 at 9:35 AM Nate McCall  wrote:
>
> > On Sat, Feb 2, 2019 at 4:38 PM Michael Shuler 
> > wrote:
> > >
> > > I propose the following artifacts for release as 3.11.4.
> > >
> > > sha1: fd47391aae13bcf4ee995abcde1b0e180372d193
> > > Git:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.4-tentative
> > > Artifacts:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1170/org/apache/cassandra/apache-cassandra/3.11.4/
> > > Staging repository:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1170/
> > >
> > > The Debian and RPM packages are available here:
> > > http://people.apache.org/~mshuler
> > >
> > > The vote will be open for 72 hours (longer if needed).
> > >
> > > [1]: CHANGES.txt:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-tentative
> > > [2]: NEWS.txt:
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-tentative
> > >
> >
> > +1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>

Re: [VOTE] Release Apache Cassandra 2.2.14

[Anthony Grasso]

+1 non-binding

On Mon, 4 Feb 2019 at 04:39, Nate McCall  wrote:

> On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler 
> wrote:
> >
> > I propose the following artifacts for release as 2.2.14.
> >
> > sha1: af91658353ba601fc8cd08627e8d36bac62e936a
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.14-tentative
> > Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1172/org/apache/cassandra/apache-cassandra/2.2.14/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1172/
> >
> > The Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-tentative
> >
>
> +1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: unsubscribe

[Anthony Grasso]

Hi Yang Su Li,

To unsubscribe, simply send an email to dev-unsubscr...@cassandra.apache.org
.

Note, replying to this email does nothing to remove your email address from
the list.

For further information, please see
http://apache.org/foundation/mailinglists.html.

Kind regards,
Anthony

On 23 April 2017 at 10:18, 杨苏立 Yang Su Li  wrote:

> unsubscribe
> On Thu, Apr 6, 2017 at 11:57 AM, Nitija Patil  wrote:
>
> > unsubscribe
> >
> > On Thu, Apr 6, 2017 at 10:25 PM, Vineet Gadodia 
> > wrote:
> >
> > > unsubscribe
> > >
> > > On Wed, Apr 5, 2017 at 1:51 AM, Ksawery Glab 
> > > wrote:
> > >
> > > > unsubscribe
> > > >
> > > > 2017-04-05 9:45 GMT+01:00 Nitija Patil :
> > > >
> > > > > unsubscribe
> > > > >
> > > > > On Wed, Apr 5, 2017 at 2:05 PM, 郑蒙家(蒙家)
>  > > com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > unsubscribe
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Suli Yang
>
> Department of Physics
> University of Wisconsin Madison
>
> 4257 Chamberlin Hall
> Madison WI 53703
>

Re: splitting CQL parser & spec into separate repo

[Anthony Grasso]

This is a great idea

+1 (non-binding)

On 22 March 2017 at 07:04, Edward Capriolo  wrote:

> On Tue, Mar 21, 2017 at 3:24 PM, Mark Dewey  wrote:
>
> > I can immediately think of a project I would use that in. +1
> >
> > On Tue, Mar 21, 2017 at 12:18 PM Jonathan Haddad 
> > wrote:
> >
> > > I created CASSANDRA-13284 a few days ago with the intent of starting a
> > > discussion around the topic of breaking the CQL parser out into a
> > separate
> > > project.  I see a few benefits to doing it and was wondering what the
> > folks
> > > here thought as well.
> > >
> > > First off, the Java CQL parser would obviously continue to be the
> > reference
> > > parser.  I'd love to see other languages have CQL parsers as well, but
> > the
> > > intent here isn't for the OSS C* team to be responsible for maintaining
> > > that.  My vision here is simply the ability to have some high level
> > > CQLParser.parse(statement) call that returns the parse tree, nothing
> > more.
> > >
> > > It would be nice to be able to leverage that parser in other projects
> > such
> > > as IDEs, code gen tools, etc.  It would be outstanding to be able to
> > create
> > > the parser tests in such a way that they can be referenced by other
> > parsers
> > > in other languages.  Yay code reuse.  It also has the benefit of making
> > the
> > > codebase a little more modular and a bit easier to understand.
> > >
> > > Thoughts?
> > >
> > > Jon
> > >
> >
>
> It turns out that a similar thing was done with Hive.
>
> https://calcite.apache.org/
>
> https://calcite.apache.org/community/#apache-calcite-one-planner-fits-all
>
> The challenge is typically adoption. The elevator pitch is like:
> "EVERYONE WILL SHARE THIS AND IT WILL BE AWESOME". Maybe this is the wrong
> word, but lets just say frenemies
> exist and they do not like control of something moving to a shared medium.
> Technical issues like ANTLR 3 vs ANTRL 4 etc.
> For something like Hive the challenge is the parser/planner needs only be
> fast enough for analytic queries but that would not
> be the right move for say CQL.
>

Re: Can we kill the wiki?

[Anthony Grasso]

+1 to killing the wiki as well. If that is not possible, we should at least
put a note on there saying it is deprecated and point people to the new
docs.

On 18 March 2017 at 08:09, Jonathan Haddad  wrote:

> +1 to killing the wiki.
>
> On Fri, Mar 17, 2017 at 2:08 PM Blake Eggleston 
> wrote:
>
> > With CASSANDRA-8700, docs were moved in tree, with the intention that
> they
> > would replace the wiki. However, it looks like we’re still getting
> regular
> > requests to edit the wiki. It seems like we should be directing these
> folks
> > to the in tree docs and either disabling edits for the wiki, or just
> > removing it entirely, and replacing it with a link to the hosted docs.
> I'd
> > prefer we just remove it myself, makes things less confusing for
> newcomers.
> >
> > Does that seem reasonable to everyone?
>

Re: Contribute to the Cassandra wiki

[Anthony Grasso]

On 14 March 2017 at 03:55, Jonathan Haddad  wrote:

>
> I urge you to try giving the in-tree docs a chance.  It may not be the way
> *you* want it but I have to point out that they're the best we've seen in
> Cassandra world.  Making them prettier won't help anything.
>

Agreed


>
> Part of CASSANDRA-8700 was to shut down the wiki.  I still advocate for
> this. At the very minimum we should make it read only with a big notice
> that points people to the in-tree docs.
>

Agreed. Am unable to see the value that the old wiki provides. We should at
the very least change it to say it is deprecated and point to the in-tree
docs. I am more than happy to make these changes if we think this is a good
idea.


>
> On Mon, Mar 13, 2017 at 8:49 AM Jeremy Hanna 
> wrote:
>
> > The moinmoin wiki was preferred but because of spam, images couldn’t be
> > attached.  The options were to use confluence or have a moderated list of
> > individuals be approved to update the wiki.  The decision was made to go
> > with the latter because of the preference to stick with moinmoin rather
> > than confluence.  That’s my understanding of the history there.  I don’t
> > know if people would like to revisit using one or the other at this
> point,
> > though it would take a bit of work to convert.
> >
> > > On Mar 13, 2017, at 9:42 AM, Nate McCall  wrote:
> > >
> > >> Isn't there a way to split tech docs (aka reference) and more
> > >> user-generated and use-case related/content oriented docs? And maybe
> to
> > use
> > >> a more modern WIKI software or scheme. The CS wiki looks like 1998.
> > >
> > > The wiki is what ASF Infra provides by default. Agree that it is a bit
> > > "old-school."
> > >
> > > I'll ask around about what other projects are doing (or folks who are
> > > involved in other ASF projects, please chime in).
> >
> >
>

Contribute to the Cassandra wiki

[Anthony Grasso]

Hi

My username is AnthonyGrasso and I would like to contribute to the
Cassandra wiki please.

Kind regards,
Anthony