Re: CI's working, and repeatable !!

2024-04-29 Thread Michael Shuler
! Amazing work - thanks so much for posting the details, Mick, and Josh
is right on. Kinda bummed I haven't been following C* CI dev, being more on
the ops side lately. Posting this up has me intrigued, so I may just have
to go poke around some and scratch an itch :)

Warm regards,
Michael


On Sun, Apr 28, 2024 at 9:08 PM Josh McKenzie  wrote:

> A huge amount of work and time went into this and it's going to have a big
> impact on the project. I want to offer a heartfelt thanks to all involved
> for the focus and energy that went into this!
>
> As the author of the system David lovingly dubbed "JoshCI" (/sigh), I
> definitely want to see us all move to converge as much as possible on the
> CI code we're running. While I remain convinced something like
> CASSANDRA-18731 is vital for hygiene in the long run (unit testing our CI,
> declaratively defining atoms of build logic independently from flow), I
> also think there'd be significant value in more of us moving towards using
> the JenkinsFile where at all possible.
>
> Seriously - thanks again for all this work everyone. CI on Cassandra is a
> Big Data Problem, and not an easy one.
>
> On Sun, Apr 28, 2024, at 10:22 AM, Mick Semb Wever wrote:
>
>
> Good news.
>
> CI on 5.0 and trunk is working again, after an unexpected 6 weeks
> hiatus (and a string of general problems since last year).
> This includes pre-commit for 5.0 and trunk working again.
>
>
> More info…
>
> From 5.0 we now have in-tree a Jenkinsfile that only relies on the in-tree
> scripts – it does not depend upon cassandra-builds and all the individual
> dsl created stage jobs. This aligns how pre-commit and post-commit works.
> More importantly, it makes our CI repeatable regardless of the fork/branch
> of the code, or the jenkins installation.
>
> For 5.0+ pre-commit use the Cassandra-devbranch-5 and make sure your patch
> is after sha 3c85def
> The jenkinsfile now comes with pre-defined profiles, it's recommended to
> use "skinny" until you need the final "pre-commit".  You can also use the
> custom profile with a regexp when you need just specific test types.
> See https://ci-cassandra.apache.org/job/Cassandra-devbranch-5/build
>
> For pre-commit on older branches, you now use Cassandra-devbranch-before-5
>
> For both pre- and post-commit builds, each build now creates two new
> sharable artefacts: ci_summary.html and results_details.tar.xz
> These are based on what apple contributors were sharing from builds from
> their internal CI system.  The format and contents of these files is
> expected to evolve.
>
> Each build now archives its results and logs all under one location in
> nightlies.
>
> e.g. https://nightlies.apache.org/cassandra/Cassandra-5.0/227/
>
>
>
> The post-commit pipeline profile remains *very* heavy, at 130k+ tests.
> These were previously ramped up to include everything in their pipelines,
> given everything that's happening in both branches.   So they take time and
> saturate everything they touch.  We need to re-evaluate what we need to be
> testing to alleviate this.  There'll also be a new pattern of timeouts and
> infra/script -related flakies, as happens whenever there's such a
> significant change, all the patience and help possible is appreciated!
>
>
>
> Now that the jenkinsfile can now be used on any jenkins server for any
> fork/branch, the next work-in-progress is CASSANDRA-18145, to be able to
> run the full pipeline with a single command line (given a k8s context
> (~/.kube/config)).
>
> We already have most of this working – it's possible to make a clone
> ci-cassandra.apache.org on k8s using this wip helm chart:
> https://github.com/thelastpickle/Cassius
> And we are already using this on an auto-scaling gke k8s cluster – you
> might have seen me posting the ci_summary.html and results_details.tar.xz
> files to tickets for pre-commit CI instead of using the ci-cassandra.a.o or
> circleci pre-commit liks.  Already, we have a full pipeline time down to
> two hours and less than a third of the cost of CircleCI, and there's lhf to
> further improve this.  For serious pre-commit testing we are still missing
> and need repeatable test runs, ref CASSANDRA-18942.  On all this I'd like
> to give a special shout out to Aleksandr Volochnev who was instrumental in
> the final (and helm based) work of 18145 which was needed to be able to
> test its prerequisite ticket CASSANDRA-18594 – ci-cassandra.a.o would not
> be running again today without his recent time spent on it.
>
> On a separate note, this new jenkinsfile is designed in preparation for
> CASSANDRA-18731 ('Add declarative root CI structure'), to make it easier to
> define profiles, tests, and their infrastructural requirements.
>
>
> To the community…
>   We are now in a place where we are looking and requesting further
> donations of servers to the ci-cassandra.apache.org jenkins cluster.  We
> can now also use cloud/instance credits to host auto-scaling k8s-based
> ci-cassandra.a.o clones that would 

Re: Plans for switching to logback 1.3.x/1.4.x?

2024-01-15 Thread Michael Shuler
Although I have not searched jira, I'd bet plans could use help, if they 
exist. I recall the jog4j -> logback transition, and it was not super 
complex, and reading through the logback docs, some defaults were 
updated and the project gained a nice feature bump. I would think a 
minor version rev of logback should be straightforward. I would suggest 
dropping in a new version, fix what needs fixing (if anything, read the 
upstream changelog), and if you get it to work, push a branch for a pull 
request. License updates, etc can get updated with a reviewer, if you 
miss any details. Sounds like a good contribution :)


Kind regards,
Michael

On 1/15/24 03:22, Alexander Shusherov wrote:

Hello Cassandra Developers!

Recently we explored the behavior of logback in Cassandra 4.1 (there
was a hypothesis about a bug in SizeAndTimeBasedRollingPolicy, however
it was not confirmed).

As part of this activity it was noticed that there exist some logback
issues that were fixed in 1.3.x/1.4.x, but still present in 1.2.x
(e.g. https://jira.qos.ch/browse/LOGBACK-1361)

At this moment Cassandra 4.1 and 5.0 still use logback 1.2.x and I
haven't found any tickets addressing switching to logback 1.3.x/1.4.x.
Could you please share if there are any plans for switching to logback
1.3.x/1.4.x?


Regards,
   Alexander


Re: [VOTE] Accept java-driver

2023-10-12 Thread Michael Shuler

+1

(late to the vote, but wanted to publicly note my support)

Kind regards,
Michael

On 10/2/23 23:52, 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: [VOTE] CEP-8 Datastax Drivers Donation

2023-06-13 Thread Michael Shuler

+1

On 6/13/23 09:14, Jeremy Hanna wrote:

Calling for a vote on CEP-8 [1].

To clarify the intent, as Benjamin said in the discussion thread [2], 
the goal of this vote is simply to ensure that the community is in favor 
of the donation. Nothing more.
The plan is to introduce the drivers, one by one. Each driver donation 
will need to be accepted first by the PMC members, as it is the case for 
any donation. Therefore the PMC should have full control on the pace at 
which new drivers are accepted.


If this vote passes, we can start this process for the Java driver under 
the direction of the PMC.


Jeremy

1. 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation 
2. https://lists.apache.org/thread/opt630do09phh7hlt28odztxdv6g58dp 



Re: [VOTE] CEP-30 ANN Vector Search

2023-05-26 Thread Michael Shuler

+1, this is cool.

On 5/25/23 10:45, Jonathan Ellis wrote:

Let's make this official.

CEP: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-30%3A+Approximate+Nearest+Neighbor%28ANN%29+Vector+Search+via+Storage-Attached+Indexes 


POC that demonstrates all the big rocks, including distributed queries: 
https://github.com/datastax/cassandra/tree/cep-vsearch 



--
Jonathan Ellis
co-founder, http://www.datastax.com 
@spyced


Re: Should we change 4.1 to G1 and offheap_objects ?

2023-01-13 Thread Michael Shuler

On 1/13/23 05:50, Mick Semb Wever wrote:
Thanks for the support Brad, you're definitely not alone. Alas the 
project works in a consensus model, i.e. off the objections made - which 
have been all sound. A good compromise has been offered that I will move 
forward on, and I'll also update the commented out G1 settings in 4.1.1 
to match those becoming the default in trunk.


+1 to G1 default in trunk and a recommendation in 4.1.1 NEWS.txt. I 
agree with Aleksey and others, trunk is the right place to change defaults.


Kind regards,
Michael


Re: Dropping Python 3.6 support in 4.1

2022-04-06 Thread Michael Shuler
This. RHEL8 is going to be around for a long while, so I'd say 
python-3.6 should not be dropped for a long while. 2029 EOL is the date 
I see on the RHEL8 Planning Guide[0]..


I saw the RHEL7/CentOS7 comments earlier and immediately thought about 
RHEL8 and python-3.6, since I'm working in that OS environment lately, 
along with C* being one small component of the system..


[0] https://access.redhat.com/support/policy/updates/errata

Kind regards,
Michael

On 4/6/22 11:13, Gerald Henriksen wrote:

On Tue, 5 Apr 2022 12:20:49 +0100, you wrote:


I would strongly recommend keeping Python 3.6 compatibility until
2024-06-30 when the CentOS 7 maintenance updates is stopped.


I would point out that the RHEL 8.* (as seen on Rocky Linux 8.5)
releases come with Python 3.6 and I don't see anything newer in the
EPEL repository for the 8.* series of releases.


Re: [VOTE] CEP-19: Trie memtable implementation

2022-02-16 Thread Michael Shuler

+1

On 2/16/22 02:57, Branimir Lambov wrote:

Hi everyone,

I'd like to propose CEP-19 for approval.

Proposal: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation 

Discussion: 
https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty 



The vote will be open for 72 hours.
Votes by committers are considered binding.
A vote passes if there are at least three binding +1s and no binding vetoes.

Thank you,
Branimir


Re: [VOTE] Formalizing our CI process

2022-01-12 Thread Michael Shuler

(still) +1 as amended

Michael

On 1/12/22 11:54, Caleb Rackliffe wrote:

+1 w/ Joey's amendment

On Wed, Jan 12, 2022 at 11:04 AM Joshua McKenzie > wrote:


I'd say an amendment with a directional poll would be fine. I don't
think this is controversial.

That's me taking "the spirit of the law" rather than the letter
though. I'm good either way.

~Josh

On Wed, Jan 12, 2022 at 11:51 AM Joseph Lynch mailto:joe.e.ly...@gmail.com>> wrote:

On Wed, Jan 12, 2022 at 11:43 AM Joshua McKenzie
mailto:jmcken...@apache.org>> wrote:
 >
 > I fully concede your point and concern Joey but I propose we
phrase that differently to emphasize the importance of clean tests.
 >
 > "All releases by default are expected to have a green test
run on ci-cassandra Jenkins. In exceptional circumstances
(security incidents, data loss, etc requiring hotfix), members
with binding votes on a release may choose to approve a release
with known failing tests."

I like the balance that strikes. Should we re-vote or should I
propose
that text as an amendment after this vote (since a simple majority
will likely be reached)?

-Joey



Re: [VOTE] Formalizing our CI process

2022-01-10 Thread Michael Shuler

+1

Michael

On 1/10/22 13:00, Joshua McKenzie wrote:
Wiki draft article here: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280 



The vote will be open for 72 hours (it's short + early indication on 
discussion was consensus).

Committer  / pmc votes binding.
Simple majority passes.

References:
Background: original ML thread here: 
https://lists.apache.org/thread/bq470ml17g106pwxpvwgws2stxc6d7b9 

Project governance guidelines here: 
https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance 



~Josh


Re: unable to connect to apache ccassandra

2021-12-30 Thread Michael Shuler
Reply-to set to user@ mailing list address, which would the best place 
to seek this type of help; dev@ bcc'ed.


Is cassandra running, did you start it? Is the process listening on 
localhost (127.0.0.1) port 9042?


`ss -ltn | grep 9042` would be a good way to check if the process is 
listening. If you did indeed start the cassandra service and it is not 
listening, then something threw an error and the logs under 
/var/log/cassandra or under ~/logs/ in the cassandra tree (depending on 
how you installed cassandra) should give hints on the error.


There needs to be a lot more detail to really help you well - how did 
you install cassandra? how did you start the service? was it previously 
running and you could connect? etc.


If you have not gone through the Installing and Configuring sections of 
the Getting Started guide, start there!


https://cassandra.apache.org/doc/latest/cassandra/getting_started/index.html

(It is very quiet over the holidays, so thanks for your patience for 
replies :) )


Kind regards,
Michael


On 12/26/21 6:26 AM, Dorian ROSSE wrote:

|Hello,


I fall on error following :

root@ubuntu-ThinkPad-X250:/etc/apt/sources.list.d# cqlsh
Connection error: ('Unable to connect to any servers', {'127.0.0.1': 
error(111, "Tried connecting to [('127.0.0.1', 9042)]. Last error: 
Connection refused")})

|

how to run fully apache cassandra ?

Thank you in advance,

Regards.


Dorian ROSSE.


Re: [VOTE] CEP-3: Guardrails

2021-11-11 Thread Michael Shuler

+1

Kind regards,
Michael Shuler

On 11/11/21 5:29 AM, Andrés de la Peña wrote:

Hi everyone,

I would like to start a vote on this CEP.

Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-3%3A+Guardrails

Discussion:
https://lists.apache.org/thread/7f6lntfdnkpqr7o0h2d2jlg8q7gf54w2
https://lists.apache.org/thread/0bd6fo4hdnwc8q2sq4xwvv4nqpxw10ds

The vote will be open for 72 hours.
A vote passes if there are at least three binding +1s and no binding vetoes.

Thanks,



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Cassandra site broken links

2021-11-06 Thread Michael Shuler

I overwrote the result link - much better, no more 429s.

https://12.am/tmp/cassandra.apache.org_muffet.log.txt

- lots of page anchor problems
- quite a few busted links
- quite a few hosts that are gone
- one link timeout
- (a few "error" reports are each 200s, just headers)

$ egrep '^\sid #' c*.log.txt |wc -l
1416
$ egrep '^\s4' c*.log.txt |wc -l
55
$ egrep '^\slookup' c*.log.txt |wc -l
20
$ egrep '^\stimeout' c*.log.txt |wc -l
1

Warm regards,
Michael

On 11/6/21 11:59 AM, Michael Shuler wrote:
FYI - I'm going to try to slow down the checks, since I just noticed a 
bunch of the 4xx errors are "HTTP 429 Too Many Requests"


Kind regards,
Michael

On 11/6/21 11:52 AM, Michael Shuler wrote:
(Sending to dev@ which seems a better place to discuss; updated 
subject. Thanks OP!)


I ran a couple link checking tools on the site and there are lots more 
problems than the couple noted. This seems like a good task for a 
non-dev to make a substantial project impact. Muffet [0] seemed the 
quickest way to get some decent output. I grabbed the v2.4.4 binary 
release [1]; tar xzvf .., and:


$ ./muffet https://cassandra.apache.org/ \
  | tee -a cassandra.apache.org_muffet.log.txt

result (2950 lines):
https://12.am/tmp/cassandra.apache.org_muffet.log.txt

$ egrep '^\s4' cassandra.apache.org_muffet.log.txt \
  | wc -l
841
$ egrep '^\sid #' cassandra.apache.org_muffet.log.txt \
  | wc -l
1401

[0] https://github.com/raviqqe/muffet
[1] https://github.com/raviqqe/muffet/releases

Kind regards,
Michael

On 11/5/21 4:09 PM, Greg Stein wrote:

see below:

-- Forwarded message -
From: *Hubert Kulas* <mailto:hubertzku...@gmail.com>>

Date: Fri, Nov 5, 2021 at 1:29 PM
Subject: Not working links
To: mailto:webmas...@apache.org>>


Hi,

I am writing my thesis about big data and I was doing some research 
about real-world use cases of Cassandra. While doing that I found 
that after clicking "read more" under 'Coursera'  leads us to 
DataStax website where we are greeted with "You do not have access to 
view this page" message. To reproduce it just go to 
https://cassandra.apache.org/_/case-studies.html 
<https://cassandra.apache.org/_/case-studies.html> and then find 
Coursera and click "read more".  Then after trying to find a way to 
contact you guys about the problem I encountered another problem on 
this part of the website 
https://cassandra.apache.org/doc/3.11.5/contactus.html 
<https://cassandra.apache.org/doc/3.11.5/contactus.html>
After clicking the icon leads us to 
https://cassandra.apache.org/feed.xml 
<https://cassandra.apache.org/feed.xml> which gives us the 404 Not 
Found message.

2021-11-05_19h26_44.png

Best Regards,
Hubert Kulas


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Cassandra site broken links

2021-11-06 Thread Michael Shuler
FYI - I'm going to try to slow down the checks, since I just noticed a 
bunch of the 4xx errors are "HTTP 429 Too Many Requests"


Kind regards,
Michael

On 11/6/21 11:52 AM, Michael Shuler wrote:
(Sending to dev@ which seems a better place to discuss; updated subject. 
Thanks OP!)


I ran a couple link checking tools on the site and there are lots more 
problems than the couple noted. This seems like a good task for a 
non-dev to make a substantial project impact. Muffet [0] seemed the 
quickest way to get some decent output. I grabbed the v2.4.4 binary 
release [1]; tar xzvf .., and:


$ ./muffet https://cassandra.apache.org/ \
  | tee -a cassandra.apache.org_muffet.log.txt

result (2950 lines):
https://12.am/tmp/cassandra.apache.org_muffet.log.txt

$ egrep '^\s4' cassandra.apache.org_muffet.log.txt \
  | wc -l
841
$ egrep '^\sid #' cassandra.apache.org_muffet.log.txt \
  | wc -l
1401

[0] https://github.com/raviqqe/muffet
[1] https://github.com/raviqqe/muffet/releases

Kind regards,
Michael

On 11/5/21 4:09 PM, Greg Stein wrote:

see below:

-- Forwarded message -
From: *Hubert Kulas* <mailto:hubertzku...@gmail.com>>

Date: Fri, Nov 5, 2021 at 1:29 PM
Subject: Not working links
To: mailto:webmas...@apache.org>>


Hi,

I am writing my thesis about big data and I was doing some research 
about real-world use cases of Cassandra. While doing that I found that 
after clicking "read more" under 'Coursera'  leads us to DataStax 
website where we are greeted with "You do not have access to view this 
page" message. To reproduce it just go to 
https://cassandra.apache.org/_/case-studies.html 
<https://cassandra.apache.org/_/case-studies.html> and then find 
Coursera and click "read more".  Then after trying to find a way to 
contact you guys about the problem I encountered another problem on 
this part of the website 
https://cassandra.apache.org/doc/3.11.5/contactus.html 
<https://cassandra.apache.org/doc/3.11.5/contactus.html>
After clicking the icon leads us to 
https://cassandra.apache.org/feed.xml 
<https://cassandra.apache.org/feed.xml> which gives us the 404 Not 
Found message.

2021-11-05_19h26_44.png

Best Regards,
Hubert Kulas


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Cassandra site broken links

2021-11-06 Thread Michael Shuler
(Sending to dev@ which seems a better place to discuss; updated subject. 
Thanks OP!)


I ran a couple link checking tools on the site and there are lots more 
problems than the couple noted. This seems like a good task for a 
non-dev to make a substantial project impact. Muffet [0] seemed the 
quickest way to get some decent output. I grabbed the v2.4.4 binary 
release [1]; tar xzvf .., and:


$ ./muffet https://cassandra.apache.org/ \
 | tee -a cassandra.apache.org_muffet.log.txt

result (2950 lines):
https://12.am/tmp/cassandra.apache.org_muffet.log.txt

$ egrep '^\s4' cassandra.apache.org_muffet.log.txt \
 | wc -l
841
$ egrep '^\sid #' cassandra.apache.org_muffet.log.txt \
 | wc -l
1401

[0] https://github.com/raviqqe/muffet
[1] https://github.com/raviqqe/muffet/releases

Kind regards,
Michael

On 11/5/21 4:09 PM, Greg Stein wrote:

see below:

-- Forwarded message -
From: *Hubert Kulas* >

Date: Fri, Nov 5, 2021 at 1:29 PM
Subject: Not working links
To: mailto:webmas...@apache.org>>


Hi,

I am writing my thesis about big data and I was doing some research 
about real-world use cases of Cassandra. While doing that I found that 
after clicking "read more" under 'Coursera'  leads us to DataStax 
website where we are greeted with "You do not have access to view this 
page" message. To reproduce it just go to 
https://cassandra.apache.org/_/case-studies.html 
 and then find 
Coursera and click "read more".  Then after trying to find a way to 
contact you guys about the problem I encountered another problem on this 
part of the website 
https://cassandra.apache.org/doc/3.11.5/contactus.html 

After clicking the icon leads us to 
https://cassandra.apache.org/feed.xml 
 which gives us the 404 Not Found 
message.

2021-11-05_19h26_44.png

Best Regards,
Hubert Kulas


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] CEP-15: General Purpose Transactions

2021-10-15 Thread Michael Shuler

1. +1
2. +1
3. +1

On 10/14/21 11:31 AM, bened...@apache.org wrote:

Hi everyone,

I would like to start a vote on this CEP, split into three sub-decisions, as 
discussion has been circular for some time.

1. Do you support adopting this CEP?
2. Do you support the transaction semantics proposed by the CEP for Cassandra?
3. Do you support an incremental approach to developing transactions in 
Cassandra, leaving scope for future development?

The first vote is a consensus vote of all committers, the second and third 
however are about project direction and therefore are simple majority votes of 
the PMC.

Recall that all -1 votes must be accompanied by an explanation. If you reject 
the CEP only on grounds (2) or (3) you should not veto the proposal. If a 
majority reject grounds (2) or (3) then transaction developments will halt for 
the time being.

This vote will be open for 72 hours.



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] CEP-16 - Auth Plugin Support for CQLSH

2021-10-11 Thread Michael Shuler

+1

On 10/11/21 4:47 AM, Stefan Miklosovic wrote:

Hi list,

based on the discussion thread about CEP-16 (1), I would like to have
a vote on that.

It seems to me CEP-16 is so straightforward there is more or less
nothing to discuss in more depth as the feedback it gathered was
mostly formal and nobody has had any objections so far having the
discussion thread open for such a long time.

The vote is open for 72 hours based on the guidelines, it needs at
least 3 binding +1's and no vetoes.

I am +1 on this.

Regards

(1) 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-16%3A+Auth+Plugin+Support+for+CQLSH

-
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: [VOTE] Release Apache Cassandra 3.0.25

2021-07-26 Thread Michael Shuler

+1

Kind regards,
Michael

On 7/25/21 12:40 PM, Brandon Williams wrote:

I am proposing the test build of Cassandra 3.0.25 for release.

sha1: 06235e93e16d1f483a3b03ba02f8fb29e33305fa
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.25-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1245/org/apache/cassandra/cassandra-all/3.0.25/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/3.0.25/

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 and no -1's.

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.25-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.25-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: [VOTE] Release Apache Cassandra 3.11.11

2021-07-26 Thread Michael Shuler

+1

Kind regards,
Michael

On 7/25/21 2:06 PM, Brandon Williams wrote:

I am proposing the test build of Cassandra 3.11.11 for release.

sha1: 4cafe2288e56e1135d65e76adbcd6c2de9306d6b
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.11-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1246/org/apache/cassandra/cassandra-all/3.11.11/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/3.11.11/
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 and no -1's.

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.11-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.11-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: [VOTE] Release Apache Cassandra 4.0.0 (third time is the charm)

2021-07-26 Thread Michael Shuler

+1

Kind regards,
Michael

On 7/22/21 5:40 PM, Brandon Williams wrote:

I am proposing the test build of Cassandra 4.0.0 for release.

sha1: 902b4d31772eaa84f05ffdc1e4f4b7a66d5b17e6
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1244/org/apache/cassandra/cassandra-all/4.0.0/

The Source and Build Artifacts, and Debian and RPM packages and
repositories are available here:
https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/

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 and no -1's.

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-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: Regarding JIRA Cassandra-14227

2020-06-12 Thread Michael Shuler
I updated the severity and complexity of this ticket. It is not a 
trivial fix, but I agree that as time goes on, this is becoming higher 
priority to focus some effort on it.


(fyi, I'm not volunteering, is way beyond my means :) )

Kind regards,
Michael

On 6/10/20 11:55 PM, manish khandelwal wrote:

Hi Team

We are not able to insert data with large TTLs (expiration time beyond
2038-01-19T03:14:06+00:00).

Even though https://jira.apache.org/jira/browse/CASSANDRA-14092 prevented a
workaround to avoid data loss, the permanent fix is still pending. I can
see that the JIRA: https://jira.apache.org/jira/browse/CASSANDRA-14227 which
was open for permanent fix is still in unassigned state. I think it’s a
high priority issue as the timestamp limit is continuously reducing as we
approach 2038.


Are there any plans to prioritize this JIRA ticket :
https://jira.apache.org/jira/browse/CASSANDRA-14227


Regards

Manish



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 4.0-alpha4

2020-04-13 Thread Michael Shuler

+1

On 4/10/20 6:02 PM, Mick Semb Wever wrote:

Proposing the test build of Cassandra 4.0-alpha4 for release.

sha1: d00c004cc10986fc41c2070f9c5d0007e03a45c3
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha4-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1202/org/apache/cassandra/cassandra-all/4.0-alpha4/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/4.0-alpha4/

The vote will be open for at least 96 hours (longer than normal,
because of Easter holidays for many). 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.

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha4-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha4-tentative


regards,
Mick

-
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: CircleCI config change?

2020-03-25 Thread Michael Shuler
It has been a few years, but I think we came to basically the same 
conclusion on build/test skipping in autojobs for CassCI. Most wanted 
the job runs all the time, but a few wanted to skip runs for scratch or 
WIP branches, in order to preserve resources when they didn't care what 
the result was.


I don't know the details of CircleCI regex, if it will grok both leading 
and trailing wildcards, or we could be slightly more strict and skip 
/nobuild-.*/ for any branches that match 'nobuild-*' - this would give 
everyone a single standard name scheme to follow.


User-defined skipping has been useful for a few people in the past to 
allow them to do what they wanted, which is nice. When they were ready 
for a final build/test check before setting 'Patch Available', they just 
pushed a new branch without the CI-skip name. Done, off it goes running 
test builds.


This seems like a pretty easy yaml change that should tick the box for 
users that want to push scratch/WIP branches without using testing 
resources.


-1 for disabling by default.

Michael

On 3/25/20 11:33 AM, David Capwell wrote:


we should probably just look into further Circle config and/or local
scripting to flip bits in the config on branch creation for people that
want auto testing on push disabled



If there are improvements we can make to the config to allow opt-out, I
am +1 to adding them (not uncommon to flag a PR as Preview or WIP and omit
CI, as long as this gets reverted once ready).  If there are ways to change
the defaults in the Circle CI site I am +1 to documenting these steps.

On Wed, Mar 25, 2020 at 8:43 AM Joshua McKenzie 
wrote:


Seems there's not an easy consensus. Rather than digging into any data and
reasoning behind the differing opinions that have been shared, we should
probably just look into further Circle config and/or local scripting to
flip bits in the config on branch creation for people that want auto
testing on push disabled. Seems like the fastest path to resolution here.

Any dissent?


On Wed, Mar 25, 2020 at 11:21 AM Jon Haddad  wrote:


I think there's more we can do to customize the circie setup, and am

also a

hard -1 on disabling testing by default.  We should figure out a way to

opt

out of it, but the default should be on.


On Wed, Mar 25, 2020 at 7:51 AM Oleksandr Petrov <
oleksandr.pet...@gmail.com>
wrote:


If you just want to disable them for your own branch/branches - I don't

see

any problem with that, I'm just not sure if it's a good default.

In a similar spirit, I know that some folks are running the script to

set

up HIGHRES environment for circle ci every time they create a branch

even

though it's not a default.

On Wed, Mar 25, 2020 at 2:26 PM  wrote:


Hi Aleks,
Thanks for those fixes and pointing out this issue.
I didn’t ask for tests not to be used and disabled. I asked whether

we

can

make them not to run on every single push to circleci as they are not
always needed. Intermediate pushes just to save pieces of work do not
require immediate CI run. That was my point.
Ekaterina

Sent from my iPhone


On 25 Mar 2020, at 9:07, Oleksandr Petrov <

oleksandr.pet...@gmail.com>

wrote:


I recently had to fix at least two problems that could've been

prevented by

running tests and checks that are about to be turned off by default

([1]

and [2]).

I'd like to point out that this has happened while checks were
theoretically enabled, and both problems could've been prevented.

This

doesn't seem to be a merge problem, or something that showed up

only

after

the merge.

I might be misunderstanding motivation for this, but my impression

was

that

we, as a community, are striving to be able to have working version

on

every commit merged to master, and possibly even block merging in

case

tests don't pass. It'd be great to hear more about why this could

be

helpful.

[1] Ninja fix: fix eclipse warnings that were broken during

CASSANDRA-15528

<







https://github.com/apache/cassandra/commit/a01d05d9a73211fb91c068e133d78ef8ccf34b4e


[2] Ninja fix: Fix unit tests that were broken during

CASSANDRA-15303.

<







https://github.com/apache/cassandra/commit/b29af2925cddacb4ab8b429b31917748781fbe5d




On Tue, Mar 24, 2020 at 9:01 PM Joshua McKenzie <

jmcken...@apache.org



wrote:

Am I understanding correctly - this isn't disabling tests, just

changing

when they're triggered (i.e. automatic to manual)?

So, for instance, smaller interim commits don't trigger a CI run

and

thus

costs?

On Tue, Mar 24, 2020 at 3:34 PM David Capwell 


wrote:




I want to change it so it could be a manual choice whether to do

it

or

not.


Could you explain the motivations for disabling the tests by

default?

My

personal stance is all tests should run (we disable a lot, at

least

HIGHER

should enable all...), not a fan of disabling tests.

On Tue, Mar 24, 2020 at 12:14 PM Ekaterina Dimitrova <
ekaterina.dimitr...@datastax.com> wrote:


Hello everyone,
Hope this email finds you 

Re: [VOTE] Release dtest-api 0.0.3

2020-03-20 Thread Michael Shuler

updated vote: -1
Thanks for the run through, Mick.

On 3/20/20 12:01 PM, Michael Shuler wrote:

+1

Code link is actually a branch at:
https://github.com/apache/cassandra-in-jvm-dtest-api/tree/CASSANDRA-15539

Just curious why master isn't the active dev branch, since there's 
nothing but a license and blank readme there. No biggie, just had to go 
look for it when I followed the link.


Michael

On 3/20/20 11:34 AM, David Capwell wrote:

+1 (non binding)

Sent from my iPhone

On Mar 20, 2020, at 9:32 AM, Oleksandr Petrov 
 wrote:


This is a somewhat special vote that requires at least minimal
understanding of the patch it is related to [1], since it's also the 
first

release.

This version has to be released _before_ Cassandra version that its 
future

versions are released, since we can't rely on unreleased artifact in
Cassandra, since any change in dtest api would break Cassandra builds,
which we'd like to avoid. There's a detailed description of the release
plan in 15539.

If you have any questions and/or concerns, now is the second-best 
time to

raise them.

Code: https://github.com/apache/cassandra-in-jvm-dtest-api
Artifact:
https://repository.apache.org/content/repositories/orgapachecassandra-1195/org/apache/cassandra/dtest-api/0.0.3/ 



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.

-- Alex

[1] https://issues.apache.org/jira/browse/CASSANDRA-15539


-
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: [VOTE] Release dtest-api 0.0.3

2020-03-20 Thread Michael Shuler

+1

Code link is actually a branch at:
https://github.com/apache/cassandra-in-jvm-dtest-api/tree/CASSANDRA-15539

Just curious why master isn't the active dev branch, since there's 
nothing but a license and blank readme there. No biggie, just had to go 
look for it when I followed the link.


Michael

On 3/20/20 11:34 AM, David Capwell wrote:

+1 (non binding)

Sent from my iPhone


On Mar 20, 2020, at 9:32 AM, Oleksandr Petrov  
wrote:

This is a somewhat special vote that requires at least minimal
understanding of the patch it is related to [1], since it's also the first
release.

This version has to be released _before_ Cassandra version that its future
versions are released, since we can't rely on unreleased artifact in
Cassandra, since any change in dtest api would break Cassandra builds,
which we'd like to avoid. There's a detailed description of the release
plan in 15539.

If you have any questions and/or concerns, now is the second-best time to
raise them.

Code: https://github.com/apache/cassandra-in-jvm-dtest-api
Artifact:
https://repository.apache.org/content/repositories/orgapachecassandra-1195/org/apache/cassandra/dtest-api/0.0.3/

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.

-- Alex

[1] https://issues.apache.org/jira/browse/CASSANDRA-15539


-
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: CASSANDRA-15586 4.0 quality testing: Cluster Setup and Maintenance

2020-03-18 Thread Michael Shuler

On 3/18/20 11:15 AM, Ekaterina Dimitrova wrote:

Hello everyone,
I am interested to help with "CASSANDRA-15586 4.0 quality testing: Cluster
Setup and Maintenance"


Awesome!


There was a short discussion last night on Slack but I know that not
everyone keeps an eye on those chats so I decided to move it to the dev
list.

For now I understand that this Jira is "free", no one did anything and it
was added during the last conference in Las Vegas

The second part of the description mentions packaging. We could start by
validating that C* 4.0 can be started on all supported platforms (with the
proper docs how to do that)?

Also, I didn't find a comprehensive list of supported platforms on the
cassandra web page. Anyone knows of such one posted anywhere?


The basics are:
Linux with python-2.7 for cqlsh support. Python-3 support is in the 
works, but incomplete. (didn't spot the JIRA#, if someone has that.)


The beginnings of python-3-only distro releases has started, but so far 
pretty minor sub-distros and 2.7 is still doable with a little work, so 
I'm not listing those as excluded. Tar/deb/rpm packages mean a pretty 
wide distro support, and realistically, users should only be using 
vendor-supported releases and get off of ancient EOL versions, but 
people and organizations can be slow to upgrade, so I'm just listing 
them all back to first python-2.7 introduction. Java versions aren't 
considered, since the JDK version needed by Cassandra is usually 
installable as a third-party package (Oracle) or using the vendor 
OpenJDK, whatever works. From a testing perspective, it makes no sense 
to spend any effort on validating OS vendor EOL releases. It also makes 
little sense to test short-lived releases, such as non-LTS Ubuntu 
versions (but they could be interesting to validate, just because they 
are pre-LTS).


The big Linux distros that are generally "supported" with the above in 
mind, just based on first python-2.7 default/availability and popularity:

  Debian > 7.0 (wheezy)+
  Ubuntu > 12.04 LTS+ (we highly suggest LTS releases)
  Centos/RHEL > 7.0+

Any Linux distro that a tarball with dependencies met, could be, in 
theory, "supported", but perhaps only the most popular could arbitrarily 
be chosen for release validation testing, such as Arch or Slackware, 
which I've seen a few users post questions about over the years. There 
may be some others, but the Cassandra tar.gz just a tarball, so OS at 
that point doesn't really matter much, since it's self-contained, data 
and all. If the tarball works on an existing debuntos CI slave, for 
instance, it should "just work" on other Linuxes (Linuxi, Lini?)


OS X is basically dev-only, but works well with tarballs and a lot of 
devs have mac laptops for work, so it's pretty self-supporting. I don't 
think I've ever heard of prod cluster of XServes, but they are dead anyway.


There are also a handful of FreeBSD users that have been self-supporting 
with submitted patches from time to time, in order to keep their OS of 
choice functional. I don't think we've ever tested on *BSD.


Windows has historically been "best effort supported" by the project 
*only* as a development platform, if that's all you got to work with. 
There was a long push to clean up Windows issues a few years back, and 
it remains pretty functional, with periodic "X.Y release broke my 
Windows thing, fix it." sort of bug reports. We ask for self-support 
from these users, but generally Cassandra devs that have time and 
expertise can figure it out and fix it for the next round. We did, at 
one time, have some legit Windows test hosts, but dropped them a few 
years back, since they are kind of a bitch to maintain for CI.


Hope that helps! OS distro and versions are a moving target, so the 
project has never really dictated what we "support" officially. If the 
dependencies can be met, and the OS is supported by the vendor, no 
worries, we'll look a the bug report. Datastax has maintained an 
official OS support list for DSE for a long time, and it's worth a look 
for a general idea, but it has also lagged sometimes for newer OS 
releases, due purely to testing time to validate, even when the newer 
"stable" OS was a fine choice and worked flawlessly.



If no one has different views/suggestions I will open a sub-ticket to start
testing on different platforms. Also, how was this done before for major
versions? Any lessons learned? Or I am free to improvise :-)


It's your ticket, if you want to work on it in a way that suits you :)

Improvising is fine on this one, I think, since much of what is being 
suggested has never been officially done or documented. Do ask on the 
dev@ list here or slack for advice as you go along. It's a group effort.


My $0.02!
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: another alpha?

2020-03-03 Thread Michael Shuler



On 3/3/20 12:16 AM, Mick Semb Wever wrote:


I'm happy to cut a release later this week or next, once these and
others yet to be mentioned get merged. We need to do another round on
the release process to wrap up CASSANDRA-14970.
Great! I have a little availability over the next week or two, once 
15358 gets committed and can review release bits.


Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RELEASE] Apache Cassandra 3.11.6 released

2020-02-14 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache 
Cassandra version 3.11.6.


Apache Cassandra is a fully distributed database. It is the right choice 
when you need scalability and high availability without compromising 
performance.


 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download 
section:


 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.11 series. As always, 
please pay attention to the release notes[2] and Let us know[3] if you 
were to encounter any problem.


Enjoy!

[1]: CHANGES.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.11.6
[2]: NEWS.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.11.6

[3]: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RELEASE] Apache Cassandra 3.0.20 released

2020-02-14 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache 
Cassandra version 3.0.20.


Apache Cassandra is a fully distributed database. It is the right choice 
when you need scalability and high availability without compromising 
performance.


 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download 
section:


 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.0 series. As always, 
please pay attention to the release notes[2] and Let us know[3] if you 
were to encounter any problem.


Enjoy!

[1]: CHANGES.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.0.20
[2]: NEWS.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.0.20

[3]: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RELEASE] Apache Cassandra 2.2.16 released

2020-02-14 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache 
Cassandra version 2.2.16.


Apache Cassandra is a fully distributed database. It is the right choice 
when you need scalability and high availability without compromising 
performance.


 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download 
section:


 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 2.2 series. As always, 
please pay attention to the release notes[2] and Let us know[3] if you 
were to encounter any problem.


Enjoy!

[1]: CHANGES.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-2.2.16
[2]: NEWS.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-2.2.16

[3]: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 2.2.16

2020-02-12 Thread Michael Shuler

+1

On 2/10/20 2:31 PM, Mick Semb Wever wrote:


Proposing the test build of Cassandra 2.2.16 for release.

sha1: c4d9e9ca4ade40b956e37935bce68737b0c063b9
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.16-tentative
Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1191/org/apache/cassandra/cassandra-all/2.2.16/

The Source and Build Artifacts, and the Debian and RPM packages are available 
here: https://dist.apache.org/repos/dist/dev/cassandra/2.2.16/

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.

Again note the release process is undergoing improvements to deal with 
sha256|512 checksums and to use the ASF dev dist staging location. Please be 
extra critical. The deb and rpm repositories are also now available to verify 
before the vote.


[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.16-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.16-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: [VOTE] Release Apache Cassandra 3.0.20

2020-02-12 Thread Michael Shuler

+1

On 2/11/20 2:36 AM, Mick Semb Wever wrote:


Proposing the test build of Cassandra 3.0.20 for release.

sha1: 89edf5073ba4181dd2f70294cdbcb47f5a45c82e
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.20-tentative
Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1193/org/apache/cassandra/cassandra-all/3.0.20/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/3.0.20/

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.

Again note the release process is undergoing improvements to deal with 
sha256|512 checksums and to use the ASF dev dist staging location. Please be 
extra critical. The deb and rpm repositories are also now available to verify 
before the vote.


[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.20-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.20-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: [VOTE] Release Apache Cassandra 3.11.6

2020-02-12 Thread Michael Shuler

+1

On 2/11/20 2:38 AM, Mick Semb Wever wrote:


Proposing the test build of Cassandra 3.11.6 for release.

sha1: cb779ab9a631c13a245926f55320392c4468c6f0
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.6-tentative
Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1194/org/apache/cassandra/cassandra-all/3.11.6/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/3.11.6/

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.

Again note the release process is undergoing improvements to deal with 
sha256|512 checksums and to use the ASF dev dist staging location. Please be 
extra critical. The deb and rpm repositories are also now available to verify 
before the vote.


[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.6-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.6-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: Ideas for Cassandra 2020 - Remote Meetups / Mastermind

2020-02-10 Thread Michael Shuler
This is great, thanks, the project appreciates the effort. 2019 is over, 
don't worry about the past. Moving forward in little or large steps is 
the goal. :)


If you didn't get a chance to attend the first Contributor Meeting, 
there will be more. Patrick sent out a survey last week for feedback, so 
I imagine these will continue at a regular interval with continued 
interest and attendance. Perhaps you could schedule some in-person 
meetup thing to coincide, as an idea, or just get the word out to others 
that might be interested in listening in?


(Next one has not been scheduled yet, but will show up here on dev@ list.)

https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting

Michael

On 2/8/20 10:06 PM, Rahul Singh wrote:

Folks, (Initially meant for User , but realized after I wrote it , it’s more 
sausage making talk which en users probably don’t care about)

I took on a bunch of work and finally starting to get my head out of the sand 
and realized I failed to deliver on some promises last year I made to myself 
and others to contribute to this community. I wanted to resurface a few 
thoughts on which I would like to contribute.

We had a conversation on here a while ago to try doing a virtual conference.. 
which I think is a bit too ambitious. I also spoke to Dinesh last year briefly 
about doing periodic development meetings which focused on the development 
planning and execution.

I’d like to help this project but I don’t know where to start. I tried getting 
some Jr. members internally at Anant who had time to make fixes on content and 
docs but it didn’t get looked at or reviewed so they lost interest. There’s 
only so much they would want to do based on my requests. The failure to deliver 
on better documentation organization was mainly mine because I didn’t commit 
enough time into it.

I don’t think our community does a good enough job communicating the Cassandra 
value proposition to the enterprise community whether they are developers, 
architects, or directors. I’ve been meeting with many folks that haven’t 
touched their clusters since installing 2.1 (because it’s pretty damn good for 
most people!). When I ask them why, it’s a combination of team member churn but 
also because the knowledge is not as accessible.

This year as January closes I am recommitting myself to some ideas and would 
LOVE your feedback. If somethings like this are in progress, I will help.


1. Cassandra Lunch - I’ve been seeing a colleague getting together with his 
fellow practitioners for a weekly “Sitecore Lunch” and I found it a very easy 
way to get people talking that normally wouldn’t be interacting with each other 
in realtime.
2. Coordinated Remote Meetup - I think this would be way easier to organize and 
get cross promoted as a quarterly event with the help of local organizers. I’m 
currently organizing DC / Chicago and have been cross promoting virtual talks 
to both and have gotten a good show with people curious about Cassandra.
3. Documentation - I know I said I’d help last year. I underestimated my free 
time and over estimated my capacity to focus. That being said , this is one of 
my passions and I help a lot of orgs get their [blank] together on how to 
manage their people, process, info and systems and the first thing is always 
knowledge management. If there’s someone I can shadow and apprentice under to 
help with Cassandra.Apache.org I really want to help revitalize our site.


These may still be overestimating my capacity but I’m willing to fail and try 
again. :)


rahul.xavier.si...@gmail.com

http://cassandra.link
The Apache Cassandra Knowledge Base.



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Do we need Javadoc in binary distribution? Was: [RELEASE] Apache Cassandra 4.0-alpha3 released

2020-02-08 Thread Michael Shuler
I like this idea for keeping binary deployment size down. I'm not sure 
how to handle it for the tarballs, but we could certainly split the docs 
out of the debian and rpm packages to add 
cassandra-docs_.{deb,rpm} packages, so they are installable 
separately, if the user wants them. This is common when docs get large. 
I suppose the same could be done for 
apache-cassandra-docs-,tar.gz, but I'm not sure about the 
release policy part of things here. Needs research.


Please, open a JIRA on this as a packaging improvement.

Kind regards,
Michael

On 2/8/20 3:06 AM, Alex Ott wrote:

Hi

I've unpacked binary distribution & noticed that we ship many files in the
javadoc directory - more than 5 thousand files, that occupy 99Mb on disk
out of 149Mb for whole unpacked Cassandra.

If we look from practical standpoint - do we expect that people who run
Cassandra will use javadoc for any purpose?  I know that it often contains
useful details about implementation, but if we talk about day-to-day work,
imho, these files aren't required, at least not on every machine that has
Cassandra on it.

Maybe we can generate a separate artifact for Javadoc files?

Mick Semb Wever  at "Fri, 07 Feb 2020 21:02:09 +0100" wrote:
  MSW> The Cassandra team is pleased to announce the release of Apache 
Cassandra version 4.0-alpha3.

  MSW> Apache Cassandra is a fully distributed database. It is the right choice 
when you need scalability and high availability without compromising performance.

  MSW>  http://cassandra.apache.org/

  MSW> Downloads of source and binary distributions are listed in our download 
section:
  MSW>  http://cassandra.apache.org/download/


  MSW> Downloads of source and binary distributions:
  MSW> 
http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-bin.tar.gz
  MSW> 
http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-src.tar.gz

  MSW> Debian and Redhat configurations.

  MSW>   sources.list:
  MSW>   deb http://www.apache.org/dist/cassandra/debian 40x main

  MSW>   yum config:
  MSW>   baseurl=https://www.apache.org/dist/cassandra/redhat/40x/

  MSW> See http://cassandra.apache.org/download/ for full install instructions.

  MSW> This is an ALPHA version! It is not intended for production use, however
  MSW> the project would appreciate your testing and feedback to make the final
  MSW> release better. As always, please pay attention to the release notes[2]
  MSW> and let us know[3] if you encounter any problems.

  MSW> Enjoy!

  MSW> [1]: CHANGES.txt 
?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-alpha3
  MSW> [2]: NEWS.txt 
?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-alpha3
  MSW> [3]: https://issues.apache.org/jira/browse/CASSANDRA

  MSW> -
  MSW> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
  MSW> For additional commands, e-mail: user-h...@cassandra.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 4.0-alpha3

2020-02-05 Thread Michael Shuler



On 2/4/20 3:59 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.



This vote has passed after 5 days with 4 binding votes and 3 non-binding votes.

The publishing of the release needs to be handed over to a PMC to do, but in 
coordination with the improvements to the release process being done in 
CASSANDRA-14970, so a little patience please. Once this is done I will address 
CASSANDRA-15541  and then am hoping to cut and raise the votes for the releases 
for 2.2.16, 3.0.20, 3.11.6. If no one objects.


Mick pinged me on slack, so fyi here, too - I'll work on this in the 
morning if I can't get it in tonight.


--
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 4.0-alpha3

2020-02-03 Thread Michael Shuler

On 2/3/20 5:21 PM, Mick Semb Wever wrote:



Summary of notes:
- Artifact set checks out OK with regards to key sigs and checksums.
- CASSANDRA-14962 is an issue when not using the current deb build
method (using new docker method results in different source artifact
creation & use). The docker rpm build suffers the same source problem
and the src.rpm is significantly larger, since I think it copies all the
downloaded maven artifacts in. It's fine for now, though :)
- UNRELEASED deb build



Thanks for the thorough review Michael.

I did not know about CASSANDRA-14962, but it should be easy to fix now that the 
-src.tar.gz is in the dev dist location and easy to re-use. I'll see if I can 
create a patch for that (aiming to use it on alpha4).


Yep! Similarly, the rpm build has been wrong all along, but it's what we 
have. The -src.tar.gz should get copied to /$build/$path/SOURCE dir, I 
think it is(?). I think that might cure the larger .src.rpm.



And I was unaware of the UNRELEASED version issue. I can put a patch in for 
that too, going into the prepare_release.sh script.


`dch -r` is usually a step I do before building, also checking NEWS and 
CHANGES and build.xml versions all align. Then the correct commit gets 
-tentative tagged. Building `dch -r` in would be OK, if all the other 
ducks are in a row.



Next step
would be to do each package-type install and startup functional testing,
but I don't have that time right now :)



I'm going to presume others that have voted have done package-type installs and 
the basic testing, and move ahead. If I close the vote, I will need your help 
Michael with the final steps running the patched finish_release.sh from the 
`mck/14970_sha512-checksums` branch, found in 
https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/
     Because only PMC can `svn move` the files into 
dist.apache.org/repos/dist/release/


I usually do this before vote. I don't know how many other people, if 
any, test that all the packages can install and start.



And for the upload_bintray.sh script, how do I get credentials, an infra ticket 
i presume? (ie to https://bintray.com/apache )


If I recall, I did an infra ticket with my github user id - this is how 
I log in. Once logged into bintray, you can find a token down in the 
user profile somewhere, which is used in the script.


Thanks again for walking through these steps.

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Fwd: [CI] What are the troubles projects face with CI and Infra

2020-02-03 Thread Michael Shuler
Only have a moment to respond, but Mick hit the higlights with 
containerization, parallelization, these help solve cleanup, speed, and 
cascading failures. Dynamic disposable slaves would be icing on that 
cake, which may require a dedicated master.


One more note on jobs, or more correctly unnecessary jobs - pipelines 
have a `changeset` build condition we should tinker with. There is zero 
reason to run a job with no actual code diff. For instance, I committed 
to 2.1 this morning and merged `-s ours` nothing to the newer branches - 
there's really no reason to run and take up valuable resources with no 
actual diff changes.

https://jenkins.io/doc/book/pipeline/syntax/#built-in-conditions

Michael

On 2/3/20 3:45 PM, Nate McCall wrote:

Mick, this is fantastic!

I'll wait another day to see if anyone else chimes in. (Would also love to
hear from CassCI folks, anyone else really who has wrestled with this even
for internal forks).

On Tue, Feb 4, 2020 at 10:37 AM Mick Semb Wever  wrote:


Nate, I leave it to you to forward what-you-chose to the board@'s thread.



Are there still troubles and what are they?



TL;DR
   the ASF could provide the Cassandra community with an isolated jenkins
installation: so that we can manage and control the Jenkins master,  as
well as ensure all donated hardware for Jenkins agents are dedicated and
isolated to us.


The long writeup…

For Cassandra's use of ASF's Jenkins I see the following problems.

** Lack of trust (aka reliability)

The Jenkins agents re-use their workspaces, as opposed to using new
containers per test run, leading to broken agents, disks, git clones, etc.
One broken test run, or a broken agent, too easily affects subsequent test
executions.

The complexity (and flakiness) around our tests is a real problem.  CI on
a project like Cassandra is a beast and the community is very limited in
what it can do, it really needs the help of larger companies. Effort is
required in fixing the broken, the flakey, and the ignored tests.
Parallelising the tests will help by better isolating failures, but tests
(and their execution scripts) also need to be better at cleaning up after
themselves, or a more container approach needs to be taken.

Another issue is that other projects sometimes using the agents, and Infra
sometimes edits our build configurations (out of necessity).


** Lack of resources (throughput and response)

Having only 9 agents: none of which can run the large dtests; is a
problem. All 9 are from Instaclustr, much kudos! Three companies recently
have said they will donate resources, this is work in progress.

We have four release branches where we would like to provide per-commit
post-commit testing. Each complete test execution currently take 24hr+.
Parallelising tests atm won't help much as the agents are generally
saturated (with the pipelines doing the top-level parallelisation). Once we
get more hardware in place: for the sake of improving throughput; it will
make sense to look into parallelising the tests more.

The throughput of tests will also improve with effort put into
removing/rewriting long running and inefficient tests. Also, and i think
this is LHF, throughput could be improved by using (or taking inspiration
from) Apache Yetus so to only run tests on what it relevant in the
patch/commit. Ref:
http://yetus.apache.org/documentation/0.11.1/precommit-basic/


** Difficulty in use

Jenkins is clumsy to use compared to the CI systems we use more often
today: Travis, CircleCI, GH Actions.

One of the complaints has been that only committers can kick off CI for
patches (ie pre-commit CI runs).  But I don't believe this to be a crucial
issue for a number of reasons.

1. Thorough CI testing of a patch only needs to happen during the review
process, to which a committer needs to be involved in anyway.
2.  We don't have enough jenkins agents to handle the amount of throughput
that automated branch/patch/pull-request testing would require.
3. Our tests could allow unknown contributors to take ownership of the
agent servers (eg via the execution of bash scripts).
4. We have CircleCI working that provides basic testing for
work-in-progress patches.


Focusing on post-commit CI and having canonical results for our release
branches, i think then it boils down to the stability and throughput of
tests, and the persistence and permanence of results.

The persistence and permanence of results is a bug bear for me. It has
been partially addressed with posting the build results to the builds@
ML. But this only provides a (pretty raw) summary of the results. I'm keen
to take the next step of the posting of CI results back to committed jira
tickets (but am waiting on seeing Jenkins run stable for a while).  If we
had our own Jenkins master we could then look into retaining more/all build
results. Being able to see the longer term trends of test results and well
as execution times I hope would add the incentive to get more folk involved.

Looping back to 

Re: [VOTE] Release Apache Cassandra 4.0-alpha3

2020-02-01 Thread Michael Shuler
# we're using different source artifacts to build debs from, here, and this is 
not a *.orig.tar.gz

mshuler@hana:~/tmp/cassandra-4.0-alpha3$ tar -tzvf 
apache-cassandra-4.0-alpha3-src.tar.gz | head -1
drwxr-xr-x 0/0   0 2020-01-30 11:34 
apache-cassandra-4.0-alpha3-src/.circleci/

mshuler@hana:~/tmp/cassandra-4.0-alpha3$ tar -tzvf cassandra_4.0~alpha3.tar.gz 
| head -1
drwxrwxr-x 0/0   0 2019-10-29 16:16 apache-cassandra-4.0-alpha3-src/

# odd permissions and different timestamps..

mshuler@hana:~/tmp/cassandra-4.0-alpha3$ tar -xzf 
apache-cassandra-4.0-alpha3-src.tar.gz
mshuler@hana:~/tmp/cassandra-4.0-alpha3$ mv apache-cassandra-4.0-alpha3-src/ 
apache-cassandra-4.0-alpha3-src_srctgz

mshuler@hana:~/tmp/cassandra-4.0-alpha3$ tar -xzf cassandra_4.0~alpha3.tar.gz
mshuler@hana:~/tmp/cassandra-4.0-alpha3$ mv apache-cassandra-4.0-alpha3-src/ 
apache-cassandra-4.0-alpha3-src_deborigtgz

mshuler@hana:~/tmp/cassandra-4.0-alpha3$ diff -r 
apache-cassandra-4.0-alpha3-src_srctgz/ 
apache-cassandra-4.0-alpha3-src_deborigtgz/
Only in 
apache-cassandra-4.0-alpha3-src_srctgz/src/resources/org/apache/cassandra: 
config

mshuler@hana:~/tmp/cassandra-4.0-alpha3$ ls -la 
apache-cassandra-4.0-alpha3-src_srctgz/src/resources/org/apache/cassandra/config
total 12
drwxr-xr-x 2 mshuler mshuler 4096 Feb  1 11:15 .
drwxr-xr-x 5 mshuler mshuler 4096 Jan 30 11:35 ..
-rw-r--r-- 1 mshuler mshuler   62 Jan 30 11:35 version.properties

mshuler@hana:~/tmp/cassandra-4.0-alpha3$ cat 
apache-cassandra-4.0-alpha3-src_srctgz/src/resources/org/apache/cassandra/config/version.properties
#Fri, 31 Jan 2020 04:35:08 +1100

CassandraVersion=4.0-alpha3

# ok, then.



mshuler@hana:~/tmp/cassandra-4.0-alpha3$ dscverify *.dsc *.changes
cassandra_4.0~alpha3.dsc:
dscverify: cassandra_4.0~alpha3.dsc failed signature check:
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: Signature made Thu 30 Jan 2020 12:27:19 PM CST
gpg:using RSA key A4C465FEA0C552561A392A61E91335D77E3E87CB
gpg: Can't check signature: No public key
cassandra_4.0~alpha3_amd64.changes:
dscverify: cassandra_4.0~alpha3_amd64.changes failed signature check:
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: Signature made Thu 30 Jan 2020 12:27:19 PM CST
gpg:using RSA key A4C465FEA0C552561A392A61E91335D77E3E87CB
gpg: Can't check signature: No public key
Validation FAILED!!

# lgtm (I have not `apt-key add`ed key..)



mshuler@hana:~/tmp/cassandra-4.0-alpha3$ egrep 'Date:|Changed-By:' *.changes ; 
grep -A3 Changes: *.changes
Date: Tue, 29 Oct 2019 16:16:36 -0500
Changed-By: Michael Shuler 
Changes:
 cassandra (4.0~alpha3) UNRELEASED; urgency=medium
 .
   * New release

# UNRELEASED version, wrong build date and human (needs a run of `dch -r` and 
commit to be tagged, so these details align properly)




-
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

2020-01-31 Thread Michael Shuler

On 1/31/20 9:58 AM, Dimitar Dimitrov wrote:

one corollary of the way the algorithm works (or more
precisely might not work) with multiple seeds or simultaneous
multi-node bootstraps or decommissions, is that a lot of dtests
start failing due to deterministic token conflicts. I wasn't
able to fix that by changing solely ccm and the dtests
I appreciate all the detailed discussion. For a little historic context, 
since I brought up this topic in the contributors zoom meeting, unstable 
dtests was precisely the reason we moved the dtest configurations to 
'num_tokens: 32'. That value has been used in CI dtest since something 
like 2014, when we found that this helped stabilize a large segment of 
flaky dtest failures. No real science there, other than "this hurts less."


I have no real opinion on the suggestions of using 4 or 16, other than I 
believe most "default config using" new users are starting with smaller 
numbers of nodes. The small-but-growing users and veteran large cluster 
admins should be gaining more operational knowledge and be able to 
adjust their own config choices according to their needs (and good 
comment suggestions in the yaml). Whatever default config value is 
chosen for num_tokens, I think it should suit the new users with smaller 
clusters. The suggestion Mick makes that 16 makes a better choice for 
small numbers of nodes, well, that would seem to be the better choice 
for those users we are trying to help the most with the default.


I fully agree that science, maths, and support/ops experience should 
guide the choice, but I don't believe that large/giant clusters and 
admins are the target audience for the value we select.


--
Kind regards,
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [DISCUSS] Switch to using GitHub pull requests?

2020-01-23 Thread Michael Shuler

On 1/23/20 3:53 PM, David Capwell wrote:


2) Nightly build email to dev@?


Nope. builds@c.a.o is where these go.
https://lists.apache.org/list.html?bui...@cassandra.apache.org

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [DISCUSS] Switch to using GitHub pull requests?

2020-01-23 Thread Michael Shuler

On 1/23/20 2:13 PM, Mick Semb Wever wrote:



ASF policy is that patches from contributors that haven't a ICLA
filed can not have their patches automatically run through any ASF CI
system. It's up to a committer (or someone who has filed a ICLA) to
trigger the test run on the patch.


I couldn't find this CI+ICLA policy info in the general ASF docs nor a
google search to locate it. Link?



https://issues.apache.org/jira/browse/INFRA-18748?focusedCommentId=16885091=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16885091


Well, OK then. This would appear to negate the "PRs make things easier 
for non-committer contributors" feature request, at least with regards 
to ASF CI. Darn, I was hoping we could hook into builds.a.o with PRs at 
some point to actually make build/test easier for everyone, which is 
generally where this thread started.


Thanks for the JIRA link - would be good to see this formalized 
somewhere in policy docs, if it's what INFRA is actually enforcing.


Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Cassandra CI Status

2020-01-11 Thread Michael Shuler




On 1/11/20 10:02 AM, Mick Semb Wever wrote:



This brings up the issue that links to builds on tickets should
ideally refer to information that is permanent. This could be
done by configuring builds to keep status and logs but not the
built artefacts (and/or adding bigger disks). I will now update
the builds to discard their artefacts quicker, since (afaik) no
one us using artefacts built by jenkins.


This is already being done, we only keep the latest job's
artifacts.



It was only being done for the artifact builds. I applied the same
artifactNumToKeep setting to all the builds in 5528779




If we wanted a more permanent place to keep results, we would need
some sort of result upload to somewhere. IMO, a jira comment on
some CASSANDRA-123456 that just showed up in CHANGES.txt that "this
patch passed/failed, here's that info" could be that permanent
place? If the link to the job 404s at some point, who cares, we
already have the feedback and could be re-run, if someone desires.



I'd rather not link, if the link will always quickly be stale.

Uploading a complete summary is a good idea. It's particularly the
test report that is of interest to me. Would each of the different
builds each upload their report to the jira ticket? That's a few
comments to append… Maybe something will come out the devbranch
pipeline build that i've been playing with for patches, an aggregated
summary would be nice, along with a link to "rebuild" that sha in the
pipeline build.


First, it takes commit discipline to trigger the correct ticket number, 
but we do that already for the most part in the commit message.


Moving to pure pipeline jobs with all build & test runs in one pipeline, 
wiht a final single JIRA comment post operation of all the results in 
one comment would be the only way I can think of to prevent the 
multi-post problem. (Which does get super annoying pretty quickly)


--
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Cassandra CI Status

2020-01-11 Thread Michael Shuler




On 1/11/20 9:17 AM, Michael Shuler wrote:



On 1/11/20 4:48 AM, Mick Semb Wever wrote:


This brings up the issue that links to builds on tickets should 
ideally refer to information that is permanent.
This could be done by configuring builds to keep status and logs but 
not the built artefacts (and/or adding bigger disks). I will now 
update the builds to discard their artefacts quicker, since (afaik) no 
one us using artefacts built by jenkins.


This is already being done, we only keep the latest job's artifacts. We 
are also keeping 5x more log history than INFRA really wants on 
builds.a.o. I got the ok to keep this many for our jobs, since they 
occasionally run scripts to globally modify job configs outside of DSL 
definitions. Basically, I've considered nothing on builds.a.o to remain 
permanent and I've had to run the DSL seed to rebuild jobs when they've 
been randomly edited by INFRA.


Job templates have:

     logRotator {
     numToKeep(50)
     artifactNumToKeep(1)
     }

If we wanted a more permanent place to keep results, we would need some 
sort of result upload to somewhere. IMO, a jira comment on some 
CASSANDRA-123456 that just showed up in CHANGES.txt that "this patch 
passed/failed, here's that info" could be that permanent place? If the 
link to the job 404s at some point, who cares, we already have the 
feedback and could be re-run, if someone desires.


Sorry, I was looking at the artifacts job template, which is the set of 
jobs that archive significant size on disk. I see you added 
artifactNumToKeep(1) to test run templates. Those jobs do not save much, 
other than the raw test output to debug test failures, so didn't take up 
much disk space compared to the artifact tarballs.


The disk space taken up by artifacts archiving is on the Jenkins master, 
so slave disk size (other than actual job run needs) plays no part in 
job history stuff.


Sorry I was on the wrong track.

--
Michael


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Cassandra CI Status

2020-01-11 Thread Michael Shuler




On 1/11/20 4:48 AM, Mick Semb Wever wrote:


This brings up the issue that links to builds on tickets should ideally refer 
to information that is permanent.
This could be done by configuring builds to keep status and logs but not the 
built artefacts (and/or adding bigger disks). I will now update the builds to 
discard their artefacts quicker, since (afaik) no one us using artefacts built 
by jenkins.


This is already being done, we only keep the latest job's artifacts. We 
are also keeping 5x more log history than INFRA really wants on 
builds.a.o. I got the ok to keep this many for our jobs, since they 
occasionally run scripts to globally modify job configs outside of DSL 
definitions. Basically, I've considered nothing on builds.a.o to remain 
permanent and I've had to run the DSL seed to rebuild jobs when they've 
been randomly edited by INFRA.


Job templates have:

logRotator {
numToKeep(50)
artifactNumToKeep(1)
}

If we wanted a more permanent place to keep results, we would need some 
sort of result upload to somewhere. IMO, a jira comment on some 
CASSANDRA-123456 that just showed up in CHANGES.txt that "this patch 
passed/failed, here's that info" could be that permanent place? If the 
link to the job 404s at some point, who cares, we already have the 
feedback and could be re-run, if someone desires.


--
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: putting the alphas on the website downloads section

2019-11-04 Thread Michael Shuler

wiki != project website

I think this sounds completely reasonable for a wiki page, and anyone 
can edit easily. Good suggestion.


Michael

On 11/4/19 3:18 PM, Joshua McKenzie wrote:

Is there an opportunity to consider a separate "upcoming release testing"
type page with downloads to alpha releases? Sounds like, as per letter of
the law, we wouldn't that on the official project page but getting
something going where we can have project-wide "test out this alpha" or
where individual devs could post builds of a feature they're working on at
similar milestones (alpha, beta, etc) might be helpful in terms of getting
a healthier dev <-> user feedback cycle going on some things. Maybe a wiki
page with this type of information?

Ultimately I'd like to see a way for us to reduce friction to users getting
involved in the testing of C* if possible without crossing that line into
risking people running alpha code on accident in a production environment.

On Mon, Nov 4, 2019 at 3:10 PM Michael Shuler 
wrote:


I will also add that I did send the user@ list 4.0-alpha release notes,
along with dev@, and also added to the @cassandra tweet last week. I
thought those were acceptable to get a little wider audience, but didn't
want to link from downloads page, since this is explicit.

Michael

On 11/4/19 2:06 PM, Michael Shuler wrote:

-1 (I looked into this when we released 4.0-alpha1)

"During the process of developing software and preparing a release,
various packages are made available to the developer community for
testing purposes. Do not include any links on the project website that
might encourage non-developers to download and use nightly builds,
snapshots, release candidates, or any other similar package. The only
people who are supposed to know about such packages are the people
following the dev list (or searching its archives) and thus aware of the
conditions placed on the package. If you find that the general public
are downloading such test packages, then remove them."

http://www.apache.org/legal/release-policy.html#what

Michael

On 11/4/19 1:11 PM, Dinesh Joshi wrote:

I think this is a good idea. I am +1 on making this more discoverable
on our website. Please add instructions to report bugs and give us
feedback around it.

Dinesh


On Nov 4, 2019, at 10:53 AM, Jon Haddad  wrote:

I noticed we don't currently list the alpha in the downloads section.
Anyone object if I add the relevant information after the "Older
supported
releases" section in the downloads page?  I'd make it clear that this

is

alpha and non-production release, and we're soliciting feedback.

http://cassandra.apache.org/download/

Jon



-
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






-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: putting the alphas on the website downloads section

2019-11-04 Thread Michael Shuler
I will also add that I did send the user@ list 4.0-alpha release notes, 
along with dev@, and also added to the @cassandra tweet last week. I 
thought those were acceptable to get a little wider audience, but didn't 
want to link from downloads page, since this is explicit.


Michael

On 11/4/19 2:06 PM, Michael Shuler wrote:

-1 (I looked into this when we released 4.0-alpha1)

"During the process of developing software and preparing a release, 
various packages are made available to the developer community for 
testing purposes. Do not include any links on the project website that 
might encourage non-developers to download and use nightly builds, 
snapshots, release candidates, or any other similar package. The only 
people who are supposed to know about such packages are the people 
following the dev list (or searching its archives) and thus aware of the 
conditions placed on the package. If you find that the general public 
are downloading such test packages, then remove them."


http://www.apache.org/legal/release-policy.html#what

Michael

On 11/4/19 1:11 PM, Dinesh Joshi wrote:
I think this is a good idea. I am +1 on making this more discoverable 
on our website. Please add instructions to report bugs and give us 
feedback around it.


Dinesh


On Nov 4, 2019, at 10:53 AM, Jon Haddad  wrote:

I noticed we don't currently list the alpha in the downloads section.
Anyone object if I add the relevant information after the "Older 
supported

releases" section in the downloads page?  I'd make it clear that this is
alpha and non-production release, and we're soliciting feedback.

http://cassandra.apache.org/download/

Jon



-
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: putting the alphas on the website downloads section

2019-11-04 Thread Michael Shuler

-1 (I looked into this when we released 4.0-alpha1)

"During the process of developing software and preparing a release, 
various packages are made available to the developer community for 
testing purposes. Do not include any links on the project website that 
might encourage non-developers to download and use nightly builds, 
snapshots, release candidates, or any other similar package. The only 
people who are supposed to know about such packages are the people 
following the dev list (or searching its archives) and thus aware of the 
conditions placed on the package. If you find that the general public 
are downloading such test packages, then remove them."


http://www.apache.org/legal/release-policy.html#what

Michael

On 11/4/19 1:11 PM, Dinesh Joshi wrote:

I think this is a good idea. I am +1 on making this more discoverable on our 
website. Please add instructions to report bugs and give us feedback around it.

Dinesh


On Nov 4, 2019, at 10:53 AM, Jon Haddad  wrote:

I noticed we don't currently list the alpha in the downloads section.
Anyone object if I add the relevant information after the "Older supported
releases" section in the downloads page?  I'd make it clear that this is
alpha and non-production release, and we're soliciting feedback.

http://cassandra.apache.org/download/

Jon



-
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: [VOTE] Cassandra Enhancement Proposal (CEP) documentation

2019-11-01 Thread Michael Shuler

+1

Scott, was your NGCC talk videoed and uploaded anywhere? I would love to 
watch, since I missed the event.


Kind regards,
Michael

On 11/1/19 9:07 AM, Scott Andreas wrote:

+1 nb


On Nov 1, 2019, at 5:36 AM, Benedict Elliott Smith  wrote:

+1

On 01/11/2019, 12:33, "Mick Semb Wever"  wrote:

Please vote on accepting the Cassandra Enhancement Proposal (CEP) document 
as a starting point and guide towards improving collaboration on, and success 
of, new features and significant improvements. In combination with the recently 
accepted Cassandra Release Lifecycle documentation this should help us moving 
forward as a project and community.

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201

Past discussions on the document/process have been touched on in a number 
of threads in the dev ML.  The most recent thread was 
https://lists.apache.org/thread.html/b5d1b1ca99324f84e4a40b9cba879e8f858f5f6e18447775fcf32155@%3Cdev.cassandra.apache.org%3E

regards,
Mick

-
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



-
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: moving the site from SVN to git

2019-10-30 Thread Michael Shuler

Looks like the source markdown was added in the next commit.
http://svn.apache.org/viewvc?view=revision=1857226

(which I see in git as commit 157df5cdfb83cb2edd0051002736316f5f470ad9)

Michael

On 10/30/19 3:29 PM, Nate McCall wrote:

Unfortunately my svn foo is about as atrophied as yours. I followed the
usual steps when publishing as I've done with the other posts, so no idea
what happened? I dont have anything uncommitted locally either.

Whatever we can do to get it showing until we move off SVN (or just move)
is fine with me.

On Thu, Oct 31, 2019 at 9:17 AM Jon Haddad  wrote:


I figured out what was wrong with the site generation, I've pushed up a
fix.

I regenerated the site and noticed the blog post for streaming was marked
as deleted, which was odd.  I dug back through the history and found it an
HTML file committed at
http://svn.apache.org/viewvc?view=revision=1857225, but I'm not
sure where the original content is.  (My SVN foo is terrible now)

Looking at the Git history I see this:

commit f00523b1eefc90b5e4515db0d8c3ab207656684b
Author: zznate 
Date:   Wed Apr 10 01:16:07 2019 +

 CASSANDRA-14765 - Streaming performance post by Sumanth Pasupuleti

 git-svn-id: http://svn.apache.org/repos/asf/cassandra/site@1857225
13f79535-47bb-0310-9956-ffa450edef68
<http://svn.apache.org/repos/asf/cassandra/site@185722513f79535-47bb-0310-9956-ffa450edef68>

Was this just published directly as HTML?

Nate, do you remember how this was handled?  Am I missing something
obvious?

Jon

On Tue, Oct 29, 2019 at 1:28 PM Jon Haddad  wrote:


I'll take a look at the website generation.  Thanks for fixing manually
for now.

On Tue, Oct 29, 2019 at 1:16 PM Michael Shuler 
wrote:


I have updated the new releases in:
src/_data/releases.yaml

I ran through the docker build/run, yet the main index and download
pages of the site were not modified with the new release versions and
dates. I'm going to reset --hard and hand edit those pages. #justFYI

Michael

On 10/17/19 9:07 AM, Jon Haddad wrote:

The migration is finished.

I had to fix a few things along the way.  The docker containers didn't
build correctly (based on debian:latest rather than a fixed tag), and

the

site had to be served out of the content directory rather than the

publish

one we were using.

I'm going to address a couple things as follow ups.  We still point

people

to IRC, I'll update that to slack.  Longer term I'll migrate it to

Hugo,

which will make the entire process a lot easier.

Jon



On Wed, Oct 9, 2019 at 10:26 PM Jon Haddad  wrote:


OK, I checked with INFRA on some details and will finish the

migration

tomorrow.

On Thu, Oct 3, 2019 at 11:32 AM Jon Haddad 

wrote:



Awesome, thanks Michael.

We need to do a little bit of additional configuration to have it

switch

over.  Specifically, we need to set up the .asf.yaml config to tell

the

servers how the site should be published.  I can take care of it
tomorrow.

Reference:




https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Publishingabranchtoyourprojectwebsite


On Thu, Oct 3, 2019 at 10:57 AM Michael Shuler <

mich...@pbandjelly.org>

wrote:


committed! :)

https://gitbox.apache.org/repos/asf?p=cassandra-website.git

Michael

On 10/3/19 12:22 PM, Jon Haddad wrote:

I think we can safely ignore them.  Thanks for figuring this out.

On Thu, Oct 3, 2019 at 10:01 AM Michael Shuler <

mich...@pbandjelly.org


wrote:


I'm making progress through many periodic timeouts to svn.a.o and
restarts, but it appears that svn2git is smart enough to pick up

where

it left off. The first commit captured at the svn path I'm

specifying

is

when Cassandra was moved to a top level project at r922689

(2010-03-13).

I don't know the old incubator path, and it's probably OK to

ignore

the

few older incubator commits? I imagine it would mean starting

over

the

entire import to pull in those older incubator svn commits, then
changing the url and somehow importing the newer path on top?

I tried using a local path as the source to try to speed things

up,

after I got my first few timeouts, but that fails.

Curious if anyone really cares if we lose a few early commits -

if

so, I

can try to figure out the old path and start again.

Michael

On 10/3/19 11:14 AM, Jon Haddad wrote:

Thanks for taking a look, Michael.  Hopefully you have better

luck

than

me

:)

On Thu, Oct 3, 2019 at 6:42 AM Michael Shuler <

mich...@pbandjelly.org>

wrote:


I cloned the empty cassandra-website git repo, and I'm running:

svn2git http://svn.apache.org/repos/asf/cassandra/site

--rootistrunk

--no-minimize-url

..to see what I get. An svn checkout of the above url says it's

only

69M, so I suppose it's pulling all history of all time for all

projects?


I'll let this roll for a while I run an errand and report back!

Michael

On 10/2/19 9:30 PM, Jon Haddad wrote:

Daniel referred me to th

[RELEASE] Apache Cassandra 4.0-alpha2 released

2019-10-29 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache 
Cassandra version 4.0-alpha2.


Apache Cassandra is a fully distributed database. It is the right choice 
when you need scalability and high availability without compromising 
performance.


 http://cassandra.apache.org/

Downloads of source and binary distributions:

http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha2/apache-cassandra-4.0-alpha2-bin.tar.gz

http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha2/apache-cassandra-4.0-alpha2-src.tar.gz

Debian and Redhat configurations

 sources.list:
 deb http://www.apache.org/dist/cassandra/debian 40x main

 yum config:
 baseurl=https://www.apache.org/dist/cassandra/redhat/40x/

See http://cassandra.apache.org/download/ for full install instructions.

This is an ALPHA version! It is not intended for production use, however 
the project would appreciate your testing and feedback to make the final 
release better. As always, please pay attention to the release notes[2] 
and let us know[3] if you encounter any problems.


Enjoy!

[1]: CHANGES.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-alpha2
[2]: NEWS.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-alpha2

[3]: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RELEASE] Apache Cassandra 2.2.15 released

2019-10-29 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache 
Cassandra version 2.2.15.


Apache Cassandra is a fully distributed database. It is the right choice 
when you need scalability and high availability without compromising 
performance.


 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download 
section:


 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 2.2 series. As always, 
please pay attention to the release notes[2] and Let us know[3] if you 
were to encounter any problem.


Enjoy!

[1]: CHANGES.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-2.2.15
[2]: NEWS.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-2.2.15

[3]: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RELEASE] Apache Cassandra 3.11.5 released

2019-10-29 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache 
Cassandra version 3.11.5.


Apache Cassandra is a fully distributed database. It is the right choice 
when you need scalability and high availability without compromising 
performance.


 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download 
section:


 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.11 series. As always, 
please pay attention to the release notes[2] and Let us know[3] if you 
were to encounter any problem.


Enjoy!

[1]: CHANGES.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.11.5
[2]: NEWS.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.11.5

[3]: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RELEASE] Apache Cassandra 3.0.19 released

2019-10-29 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache 
Cassandra version 3.0.19.


Apache Cassandra is a fully distributed database. It is the right choice 
when you need scalability and high availability without compromising 
performance.


 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download 
section:


 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.0 series. As always, 
please pay attention to the release notes[2] and Let us know[3] if you 
were to encounter any problem.


Enjoy!

[1]: CHANGES.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.0.19
[2]: NEWS.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.0.19

[3]: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: moving the site from SVN to git

2019-10-29 Thread Michael Shuler

I have updated the new releases in:
  src/_data/releases.yaml

I ran through the docker build/run, yet the main index and download 
pages of the site were not modified with the new release versions and 
dates. I'm going to reset --hard and hand edit those pages. #justFYI


Michael

On 10/17/19 9:07 AM, Jon Haddad wrote:

The migration is finished.

I had to fix a few things along the way.  The docker containers didn't
build correctly (based on debian:latest rather than a fixed tag), and the
site had to be served out of the content directory rather than the publish
one we were using.

I'm going to address a couple things as follow ups.  We still point people
to IRC, I'll update that to slack.  Longer term I'll migrate it to Hugo,
which will make the entire process a lot easier.

Jon



On Wed, Oct 9, 2019 at 10:26 PM Jon Haddad  wrote:


OK, I checked with INFRA on some details and will finish the migration
tomorrow.

On Thu, Oct 3, 2019 at 11:32 AM Jon Haddad  wrote:


Awesome, thanks Michael.

We need to do a little bit of additional configuration to have it switch
over.  Specifically, we need to set up the .asf.yaml config to tell the
servers how the site should be published.  I can take care of it
tomorrow.

Reference:
https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Publishingabranchtoyourprojectwebsite

On Thu, Oct 3, 2019 at 10:57 AM Michael Shuler 
wrote:


committed! :)

https://gitbox.apache.org/repos/asf?p=cassandra-website.git

Michael

On 10/3/19 12:22 PM, Jon Haddad wrote:

I think we can safely ignore them.  Thanks for figuring this out.

On Thu, Oct 3, 2019 at 10:01 AM Michael Shuler 
I'm making progress through many periodic timeouts to svn.a.o and
restarts, but it appears that svn2git is smart enough to pick up where
it left off. The first commit captured at the svn path I'm specifying

is

when Cassandra was moved to a top level project at r922689

(2010-03-13).

I don't know the old incubator path, and it's probably OK to ignore

the

few older incubator commits? I imagine it would mean starting over the
entire import to pull in those older incubator svn commits, then
changing the url and somehow importing the newer path on top?

I tried using a local path as the source to try to speed things up,
after I got my first few timeouts, but that fails.

Curious if anyone really cares if we lose a few early commits - if

so, I

can try to figure out the old path and start again.

Michael

On 10/3/19 11:14 AM, Jon Haddad wrote:

Thanks for taking a look, Michael.  Hopefully you have better luck

than

me

:)

On Thu, Oct 3, 2019 at 6:42 AM Michael Shuler <

mich...@pbandjelly.org>

wrote:


I cloned the empty cassandra-website git repo, and I'm running:

svn2git http://svn.apache.org/repos/asf/cassandra/site

--rootistrunk

--no-minimize-url

..to see what I get. An svn checkout of the above url says it's only
69M, so I suppose it's pulling all history of all time for all

projects?


I'll let this roll for a while I run an errand and report back!

Michael

On 10/2/19 9:30 PM, Jon Haddad wrote:

Daniel referred me to the GitBox self service system.

I've attempted to port the site over using the tool Michael

suggested,

but

after a couple hours it died with this message:

command failed: r922600
git checkout -f master

If either of you (Mick or Michael) want to give svn2git a shot

maybe

you'll

get a different result.I think it may have been due to the

large

size

of the repo and the small drive on the VM I was using.  I can try

it

again

tomorrow with more storage to see if I get a better result.  Mick

if

you

want to give it a shot in the meantime that would be appreciated.

Jon

On Wed, Oct 2, 2019 at 3:18 PM Jon Haddad 

wrote:



I created an INFRA ticket here:
https://issues.apache.org/jira/browse/INFRA-19218.

On Wed, Sep 25, 2019 at 6:04 AM Michael Shuler <

mich...@pbandjelly.org>

wrote:


I see no good reason to trash history. There are tools to make

moving

from svn to git (hopefully) painless. We used git-svn for the

main c*

source to retain history of both, which this tool uses to do

migrations

- https://github.com/nirvdrum/svn2git

Michael

On 9/25/19 12:57 AM, Mick Semb Wever wrote:



Personally, no, I don't.  What I need to know is if someone who

actually

works on the site needs the history in *git*.



Yes. I need the history in *git*.


And I believe that INFRA can do the migration for you.
(For example, INFRA-12055 and spark-website)



-

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...@cassandr

Re: [VOTE PASSED] Release Apache Cassandra 4.0-alpha2

2019-10-29 Thread Michael Shuler

This vote passed with 6 binding +1, 3 non-binding +1, and no other votes.

Kind regards,
Michael Shuler

On 10/24/19 12:26 PM, Michael Shuler wrote:

I propose the following artifacts for release as 4.0-alpha2.

sha1: ca928a49c68186bdcd57dea8b10c30991c6a3c55
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha2-tentative 

Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1185/org/apache/cassandra/apache-cassandra/4.0-alpha2/ 

Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1185/


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/4.0-alpha2-tentative 

[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha2-tentative 



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE PASSED] Release Apache Cassandra 3.11.5

2019-10-29 Thread Michael Shuler

This vote passed with 7 binding +1, 2 non-binding +1, and no other votes.

Kind regards,
Michael Shuler

On 10/24/19 12:26 PM, Michael Shuler wrote:

I propose the following artifacts for release as 3.11.5.

sha1: b697af87f8e1b20d22948390d516dba1fbb9eee7
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.5-tentative 

Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1184/org/apache/cassandra/apache-cassandra/3.11.5/ 

Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1184/


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.5-tentative 

[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.5-tentative 



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE PASSED] Release Apache Cassandra 3.0.19

2019-10-29 Thread Michael Shuler

This vote passed with 8 binding +1, 3 non-binding +1, and no other votes.

Kind regards,
Michael Shuler

On 10/24/19 12:25 PM, Michael Shuler wrote:

I propose the following artifacts for release as 3.0.19.

sha1: a81bfd6b7db3a373430b3c4e8f4e930b199796f0
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.19-tentative 

Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1183/org/apache/cassandra/apache-cassandra/3.0.19/ 

Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1183/


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.19-tentative 

[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.19-tentative 



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE PASSED] Release Apache Cassandra 2.2.15

2019-10-29 Thread Michael Shuler

This vote passed with 8 binding +1, 2 non-binding +1, and no other votes.

Kind regards,
Michael Shuler

On 10/24/19 12:25 PM, Michael Shuler wrote:

I propose the following artifacts for release as 2.2.15.

sha1: 4ee4ceea28a1cb77b283c7ce0135340ddff02086
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.15-tentative 

Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1179/org/apache/cassandra/apache-cassandra/2.2.15/ 

Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1179/


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.15-tentative 

[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.15-tentative 



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[VOTE] Release Apache Cassandra 3.0.19

2019-10-24 Thread Michael Shuler

I propose the following artifacts for release as 3.0.19.

sha1: a81bfd6b7db3a373430b3c4e8f4e930b199796f0
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.19-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1183/org/apache/cassandra/apache-cassandra/3.0.19/
Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1183/


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.19-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.19-tentative


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[VOTE] Release Apache Cassandra 4.0-alpha2

2019-10-24 Thread Michael Shuler

I propose the following artifacts for release as 4.0-alpha2.

sha1: ca928a49c68186bdcd57dea8b10c30991c6a3c55
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha2-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1185/org/apache/cassandra/apache-cassandra/4.0-alpha2/
Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1185/


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/4.0-alpha2-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha2-tentative


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[VOTE] Release Apache Cassandra 3.11.5

2019-10-24 Thread Michael Shuler

I propose the following artifacts for release as 3.11.5.

sha1: b697af87f8e1b20d22948390d516dba1fbb9eee7
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.5-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1184/org/apache/cassandra/apache-cassandra/3.11.5/
Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1184/


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.5-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.5-tentative


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[VOTE] Release Apache Cassandra 2.2.15

2019-10-24 Thread Michael Shuler

I propose the following artifacts for release as 2.2.15.

sha1: 4ee4ceea28a1cb77b283c7ce0135340ddff02086
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.15-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1179/org/apache/cassandra/apache-cassandra/2.2.15/
Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1179/


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.15-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.15-tentative


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Improving our frequency of (patch) releases, and letting committers make releases

2019-10-17 Thread Michael Shuler
Oh! As an added bonus of migrating to proper bintray package repository 
types, we also cure the pain of users attempting to install older 
versions than the latest release, since all versions in the suite are 
installable.


--
Michael

On 10/17/19 9:47 AM, Michael Shuler wrote:

Noted:
https://issues.apache.org/jira/browse/CASSANDRA-14963

Fundamental current docker build flaws:
https://issues.apache.org/jira/browse/CASSANDRA-14962

Distribution changes suggested for deb/rpm:
https://issues.apache.org/jira/browse/CASSANDRA-14966
https://issues.apache.org/jira/browse/CASSANDRA-14967

..which are dependencies of repository sig changes to solve the whole 
KEYS file pain for package users, for ever and ever:

https://issues.apache.org/jira/browse/CASSANDRA-14968

There are other ASF projects using bintray metatdata signing (the repo 
metadata is *not* a release artifact). Artifact sigs uploaded to /dist/ 
and subsequent verification from KEYS seem orthogonal to repo metadata 
signatures to me. I don't see why we cannot do the same as quite a few 
other projects and use automated bintray repo signing, migrating to 
appropriate bintray repository types.


I believe some basic distribution changes would greatly help the entire 
question here, including making release builds easier for other people 
to perform, shortening the cycle times as desired. If there is some 
interest in building releases, I would like some help solving the 
problems that exist and have been in JIRA for quite some time.




-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Improving our frequency of (patch) releases, and letting committers make releases

2019-10-17 Thread Michael Shuler

Noted:
https://issues.apache.org/jira/browse/CASSANDRA-14963

Fundamental current docker build flaws:
https://issues.apache.org/jira/browse/CASSANDRA-14962

Distribution changes suggested for deb/rpm:
https://issues.apache.org/jira/browse/CASSANDRA-14966
https://issues.apache.org/jira/browse/CASSANDRA-14967

..which are dependencies of repository sig changes to solve the whole 
KEYS file pain for package users, for ever and ever:

https://issues.apache.org/jira/browse/CASSANDRA-14968

There are other ASF projects using bintray metatdata signing (the repo 
metadata is *not* a release artifact). Artifact sigs uploaded to /dist/ 
and subsequent verification from KEYS seem orthogonal to repo metadata 
signatures to me. I don't see why we cannot do the same as quite a few 
other projects and use automated bintray repo signing, migrating to 
appropriate bintray repository types.


I believe some basic distribution changes would greatly help the entire 
question here, including making release builds easier for other people 
to perform, shortening the cycle times as desired. If there is some 
interest in building releases, I would like some help solving the 
problems that exist and have been in JIRA for quite some time.


--
Kind regards,
Michael

On 10/17/19 8:41 AM, Joshua McKenzie wrote:

Might make sense to split the difference and have a loose reactive policy
of "consider / discuss a potential release when any of the following are
hit":

1. something critical is merged (data loss fix, cluster down fix, etc)
2. there are  changes to the branch
3. it's been  weeks since the last patch

Maybe having triggers at reasonably fat M/N above (30/8?) would be enough
to trigger those conversations and keep momentum on releases while
respecting both the highly variable delta each change can have as well as
our variable resources to commit to release validation across the project
as contributors.


On Thu, Oct 17, 2019 at 8:23 AM Jon Haddad  wrote:


Mick's absolutely right.  Even if we had been doing more frequent releases,
it's a big risk for us to only have one person able to it in the first
place.

I also agree with Benedict. I don't think we need to be crazy strict about
windows.  As long as we tell folks they may need to import keys, I think
we're much better off than we are now.

On Thu, Oct 17, 2019 at 5:08 AM Benedict Elliott Smith <
bened...@apache.org>
wrote:


+1

We need to do something about this, and I don't mind what.  It would be
better if we cut fix releases immediately after a critical fix lands,

much

as we used to.  We've got fairly lazy about producing releases, perhaps
because many of the full-time contributors now work for organisations

that

don't really need them.

We should definitely add any willing volunteers to the KEYS file now.  I
don't personally think we need any kind of a strict policy about

modifying

it in future, except that if our release cadence drops and we have

willing

volunteers we should do it again.


  On 17/10/2019, 07:50, "Mick Semb Wever"  wrote:


 > We're still in the position where only four people in the project:
 > Michael, Sylvain, Jake, and Eric; can cut, stage, and propose a
 > release.


 Our current patch release frequency is lacking. It's been 8 months
since 3.11.4.
 This is having an impact on users and their faith in the technology.

 There is currently only one person in the community that is actively
making releases. This really doesn't inspire confidence. We really should
be cutting a patch release every 2 to 6 weeks, if critical fixes apply,
imho. And I for one would certainly like to be helping out with this
situation.

 If we choose to address this issue, there are two facets to it that
come to mind:
   1) This misnomer that committers can't cut and publish releases.
   2) That we can't make changes to the KEYS file (or that it's too
painful to do so).

 Re (1). I'm not sure where this misunderstanding came from in our
community. But the ASF policy does not prevent committers from being the
release manager. By default the only thing in the process a committer

can't

do is publish the successfully voted upon release from stage to public.
This is a one-line svn command and the last and very small action in the
release process at large. A committer can coordinate, cut, stage,

announce,

and initiate the vote on a release, which is the bulk of the work. And

the

committer can also do the final publish command if the PMC has voted that
this is ok in this community. This is all in
http://www.apache.org/legal/release-policy.html


 > Is it time to add more people to our KEYS file?
 > This will have the consequence that debian users will have to

re-add

it.


 Re (2), the problem is that changes to the KEYS file mean that debian
users have to re-import it before pulling new packages. But is that

really

worse than an 8 month or more for an earlier patch version like ".5" ?


 > But 

Re: [VOTE-2] Apache Cassandra Release Lifecycle

2019-10-09 Thread Michael Shuler
+1

-- 
Kind regards,
Michael

On Wed, Oct 9, 2019 at 9:06 AM Aleksey Yeshchenko
 wrote:
>
> +1 as a rather reasonable starting point; we can make changes to the process 
> in the future if need be.
>
> > On 8 Oct 2019, at 19:00, sankalp kohli  wrote:
> >
> > Hi,
> >We have discussed in the email thread[1] about Apache Cassandra Release
> > Lifecycle. We came up with a doc[2] for it. We have finalized the doc
> > here[3] Please vote on it if you agree with the content of the doc [3].
> >
> > We did not proceed with the previous vote as we want to use confluence for
> > it. Here is the link for that[4]. It also mentions why we are doing this
> > vote.
> >
> > Vote will remain open for 72 hours.
> >
> > Thanks,
> > Sankalp
> >
> > [1]
> > https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> > [2]
> > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> > [3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> > Attachments area
> > [4]
> > https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E
> > 
>
>
> -
> 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: Can we kick off a release?

2019-10-08 Thread Michael Shuler
Thanks Sam, I'm following #15193 and should catch the status change there.

Michael

On Tue, Oct 8, 2019 at 6:17 AM Sam Tunnicliffe  wrote:
>
> CASSANDRA-15193 just got +1’d yesterday and would be good to include in the 
> 3.0 and 3.11 releases. If you don’t mind holding off while I add a cqlsh test 
> and merge it, that’d be good.
>
> Thanks,
> Sam
>
> > On 7 Oct 2019, at 22:54, Michael Shuler  wrote:
> >
> > Will do! I probably won't get this done this evening, so will send out
> > the emails tomorrow.
> >
> > Thanks,
> > Michael
> >
> > On Mon, Oct 7, 2019 at 2:37 PM Jon Haddad  wrote:
> >>
> >> Michael,
> >>
> >> Would you mind kicking off builds and starting a vote thread for the latest
> >> 2.2, 3.0 and 3.11 builds?
> >>
> >> Much appreciated,
> >> Jon
> >
> > -
> > 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
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Can we kick off a release?

2019-10-07 Thread Michael Shuler
Will do! I probably won't get this done this evening, so will send out
the emails tomorrow.

Thanks,
Michael

On Mon, Oct 7, 2019 at 2:37 PM Jon Haddad  wrote:
>
> Michael,
>
> Would you mind kicking off builds and starting a vote thread for the latest
> 2.2, 3.0 and 3.11 builds?
>
> Much appreciated,
> Jon

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: moving the site from SVN to git

2019-10-03 Thread Michael Shuler

committed! :)

https://gitbox.apache.org/repos/asf?p=cassandra-website.git

Michael

On 10/3/19 12:22 PM, Jon Haddad wrote:

I think we can safely ignore them.  Thanks for figuring this out.

On Thu, Oct 3, 2019 at 10:01 AM Michael Shuler 
wrote:


I'm making progress through many periodic timeouts to svn.a.o and
restarts, but it appears that svn2git is smart enough to pick up where
it left off. The first commit captured at the svn path I'm specifying is
when Cassandra was moved to a top level project at r922689 (2010-03-13).
I don't know the old incubator path, and it's probably OK to ignore the
few older incubator commits? I imagine it would mean starting over the
entire import to pull in those older incubator svn commits, then
changing the url and somehow importing the newer path on top?

I tried using a local path as the source to try to speed things up,
after I got my first few timeouts, but that fails.

Curious if anyone really cares if we lose a few early commits - if so, I
can try to figure out the old path and start again.

Michael

On 10/3/19 11:14 AM, Jon Haddad wrote:

Thanks for taking a look, Michael.  Hopefully you have better luck than

me

:)

On Thu, Oct 3, 2019 at 6:42 AM Michael Shuler 
wrote:


I cloned the empty cassandra-website git repo, and I'm running:

svn2git http://svn.apache.org/repos/asf/cassandra/site --rootistrunk
--no-minimize-url

..to see what I get. An svn checkout of the above url says it's only
69M, so I suppose it's pulling all history of all time for all projects?

I'll let this roll for a while I run an errand and report back!

Michael

On 10/2/19 9:30 PM, Jon Haddad wrote:

Daniel referred me to the GitBox self service system.

I've attempted to port the site over using the tool Michael suggested,

but

after a couple hours it died with this message:

command failed: r922600
git checkout -f master

If either of you (Mick or Michael) want to give svn2git a shot maybe

you'll

get a different result.I think it may have been due to the large

size

of the repo and the small drive on the VM I was using.  I can try it

again

tomorrow with more storage to see if I get a better result.  Mick if

you

want to give it a shot in the meantime that would be appreciated.

Jon

On Wed, Oct 2, 2019 at 3:18 PM Jon Haddad  wrote:


I created an INFRA ticket here:
https://issues.apache.org/jira/browse/INFRA-19218.

On Wed, Sep 25, 2019 at 6:04 AM Michael Shuler <

mich...@pbandjelly.org>

wrote:


I see no good reason to trash history. There are tools to make moving
from svn to git (hopefully) painless. We used git-svn for the main c*
source to retain history of both, which this tool uses to do

migrations

- https://github.com/nirvdrum/svn2git

Michael

On 9/25/19 12:57 AM, Mick Semb Wever wrote:



Personally, no, I don't.  What I need to know is if someone who

actually

works on the site needs the history in *git*.



Yes. I need the history in *git*.


And I believe that INFRA can do the migration for you.
(For example, INFRA-12055 and spark-website)



-

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






-
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






-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: moving the site from SVN to git

2019-10-03 Thread Michael Shuler
I'm making progress through many periodic timeouts to svn.a.o and 
restarts, but it appears that svn2git is smart enough to pick up where 
it left off. The first commit captured at the svn path I'm specifying is 
when Cassandra was moved to a top level project at r922689 (2010-03-13). 
I don't know the old incubator path, and it's probably OK to ignore the 
few older incubator commits? I imagine it would mean starting over the 
entire import to pull in those older incubator svn commits, then 
changing the url and somehow importing the newer path on top?


I tried using a local path as the source to try to speed things up, 
after I got my first few timeouts, but that fails.


Curious if anyone really cares if we lose a few early commits - if so, I 
can try to figure out the old path and start again.


Michael

On 10/3/19 11:14 AM, Jon Haddad wrote:

Thanks for taking a look, Michael.  Hopefully you have better luck than me
:)

On Thu, Oct 3, 2019 at 6:42 AM Michael Shuler 
wrote:


I cloned the empty cassandra-website git repo, and I'm running:

svn2git http://svn.apache.org/repos/asf/cassandra/site --rootistrunk
--no-minimize-url

..to see what I get. An svn checkout of the above url says it's only
69M, so I suppose it's pulling all history of all time for all projects?

I'll let this roll for a while I run an errand and report back!

Michael

On 10/2/19 9:30 PM, Jon Haddad wrote:

Daniel referred me to the GitBox self service system.

I've attempted to port the site over using the tool Michael suggested,

but

after a couple hours it died with this message:

command failed: r922600
git checkout -f master

If either of you (Mick or Michael) want to give svn2git a shot maybe

you'll

get a different result.I think it may have been due to the large size
of the repo and the small drive on the VM I was using.  I can try it

again

tomorrow with more storage to see if I get a better result.  Mick if you
want to give it a shot in the meantime that would be appreciated.

Jon

On Wed, Oct 2, 2019 at 3:18 PM Jon Haddad  wrote:


I created an INFRA ticket here:
https://issues.apache.org/jira/browse/INFRA-19218.

On Wed, Sep 25, 2019 at 6:04 AM Michael Shuler 
wrote:


I see no good reason to trash history. There are tools to make moving
from svn to git (hopefully) painless. We used git-svn for the main c*
source to retain history of both, which this tool uses to do migrations
- https://github.com/nirvdrum/svn2git

Michael

On 9/25/19 12:57 AM, Mick Semb Wever wrote:



Personally, no, I don't.  What I need to know is if someone who

actually

works on the site needs the history in *git*.



Yes. I need the history in *git*.


And I believe that INFRA can do the migration for you.
(For example, INFRA-12055 and spark-website)

-
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






-
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: moving the site from SVN to git

2019-10-03 Thread Michael Shuler

I cloned the empty cassandra-website git repo, and I'm running:

svn2git http://svn.apache.org/repos/asf/cassandra/site --rootistrunk 
--no-minimize-url


..to see what I get. An svn checkout of the above url says it's only 
69M, so I suppose it's pulling all history of all time for all projects?


I'll let this roll for a while I run an errand and report back!

Michael

On 10/2/19 9:30 PM, Jon Haddad wrote:

Daniel referred me to the GitBox self service system.

I've attempted to port the site over using the tool Michael suggested, but
after a couple hours it died with this message:

command failed: r922600
git checkout -f master

If either of you (Mick or Michael) want to give svn2git a shot maybe you'll
get a different result.I think it may have been due to the large size
of the repo and the small drive on the VM I was using.  I can try it again
tomorrow with more storage to see if I get a better result.  Mick if you
want to give it a shot in the meantime that would be appreciated.

Jon

On Wed, Oct 2, 2019 at 3:18 PM Jon Haddad  wrote:


I created an INFRA ticket here:
https://issues.apache.org/jira/browse/INFRA-19218.

On Wed, Sep 25, 2019 at 6:04 AM Michael Shuler 
wrote:


I see no good reason to trash history. There are tools to make moving
from svn to git (hopefully) painless. We used git-svn for the main c*
source to retain history of both, which this tool uses to do migrations
- https://github.com/nirvdrum/svn2git

Michael

On 9/25/19 12:57 AM, Mick Semb Wever wrote:



Personally, no, I don't.  What I need to know is if someone who

actually

works on the site needs the history in *git*.



Yes. I need the history in *git*.


And I believe that INFRA can do the migration for you.
(For example, INFRA-12055 and spark-website)

-
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






-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RELEASE] Apache Cassandra 4.0-alpha1 released

2019-09-08 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache 
Cassandra version 4.0-alpha1.


Apache Cassandra is a fully distributed database. It is the right choice 
when you need scalability and high availability without compromising 
performance.


 http://cassandra.apache.org/

Downloads of source and binary distributions for 4.0-alpha1:


http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha1/apache-cassandra-4.0-alpha1-bin.tar.gz

http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha1/apache-cassandra-4.0-alpha1-src.tar.gz

Debian and Redhat configurations

 sources.list:
 deb http://www.apache.org/dist/cassandra/debian 40x main

 yum config:
 baseurl=https://www.apache.org/dist/cassandra/redhat/40x/

See http://cassandra.apache.org/download/ for full install instructions. 
Since this is the first alpha release, it will not be present on the 
download page.


This is an ALPHA version! It is not intended for production use, however 
the project would appreciate your testing and feedback to make the final 
release better. As always, please pay attention to the release notes[2] 
and Let us know[3] if you were to encounter any problem.


Enjoy!

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-alpha1
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-alpha1

[3]: JIRA: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[VOTE PASSED] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

2019-09-07 Thread Michael Shuler
In the replies, I counted 2 binding +1 votes, 2 non-binding +1s, a 
non-binding -0, a couple non-binding "seems OK for alpha" affirmations 
with test results and JIRAs, and a binding desire for all the tests to pass.


Thanks for the test runs and feedback, I believe we can call this 
4.0-alpha1 vote successful. I will get the artifacts published as soon 
as I can.


--
Kind regards,
Michael

On 9/5/19 3:44 PM, Michael Shuler wrote:

I propose the following artifacts for release as 4.0-alpha1.

sha1: fc4381ca89ab39a82c9018e5171975285cc3bfe7
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha1-tentative 

Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1177/org/apache/cassandra/apache-cassandra/4.0-alpha1/ 

Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1177/


The Debian and RPM packages are available here: 
http://people.apache.org/~mshuler


The vote will be open for 24 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/4.0-alpha1-tentative 

[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-tentative 



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

2019-09-05 Thread Michael Shuler
Thanks a bunch for the test runs. Most of those upgrade tests show 
"RuntimeError: You need to set JAVA8_HOME," so it does look like a 
systemic, generic issue to resolve there somewhere in dtest. Thanks again!


Michael

On 9/5/19 8:08 PM, Joseph Lynch wrote:

Following passed 100%: utest_compression, utests_stress, utests_long,
utests_fqltool, j8_dtests-no-vnodes

j8_unit_tests: 1 failure
- testAcquireReleaseOutbound - org.apache.cassandra.net.ConnectionTest

j11_unit_tests: 1 failure
- testIdleDisconnect - org.apache.cassandra.transport.IdleDisconnectTest

j8_dtests-with-vnodes + j11_dtests-with-vnodes: 1 failure
- test_remote_query - cql_test.TestCQLSlowQuery

j11_dtests-no-vnodes: 1 failure
- test_13595 - consistency_test.TestConsistency

j8_upgradetests-no-vnodes: 3923 failures

Other than the upgradetests (which afaik nobody has looked at for
4.0), this looks somewhat reasonable to me. I'm launching a multi-dc
cluster to do some light load testing.

-Joey


On Thu, Sep 5, 2019 at 4:03 PM Joseph Lynch  wrote:


Running all tests at 
https://circleci.com/workflow-run/79918e2a-ea8e-48a6-a38d-96cf85de27ff

Will report back with results shortly,
-Joey

On Thu, Sep 5, 2019 at 3:55 PM Jon Haddad  wrote:


+1

On Thu, Sep 5, 2019 at 3:44 PM Michael Shuler 
wrote:


I propose the following artifacts for release as 4.0-alpha1.

sha1: fc4381ca89ab39a82c9018e5171975285cc3bfe7
Git:

https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha1-tentative
Artifacts:

https://repository.apache.org/content/repositories/orgapachecassandra-1177/org/apache/cassandra/apache-cassandra/4.0-alpha1/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1177/

The Debian and RPM packages are available here:
http://people.apache.org/~mshuler

The vote will be open for 24 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/4.0-alpha1-tentative
[2]: NEWS.txt:

https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-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



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

2019-09-05 Thread Michael Shuler

NEWS.txt link was incorrect (fixed in template for next time).
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha1-tentative

--
Michael

On 9/5/19 3:44 PM, Michael Shuler wrote:

I propose the following artifacts for release as 4.0-alpha1.

sha1: fc4381ca89ab39a82c9018e5171975285cc3bfe7
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha1-tentative 

Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1177/org/apache/cassandra/apache-cassandra/4.0-alpha1/ 

Staging repository: 
https://repository.apache.org/content/repositories/orgapachecassandra-1177/


The Debian and RPM packages are available here: 
http://people.apache.org/~mshuler


The vote will be open for 24 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/4.0-alpha1-tentative 

[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-tentative 



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: 4.0 alpha before apachecon?

2019-09-04 Thread Michael Shuler

Quick update on 4.0-alpha1 builds:

- tar artifacts are published to maven[0] and sha d4054e0c tagged as 
4.0-alpha1-tentative (thanks to Marcus Eriksson for asking this morning 
to look at a cassandra-diff PR for maven publish, which gave me a fresh 
idea on fixing .m2/settings.xml for new-laptop publish problems.. Fix 
worked!)


- debs built locally, but upload to people.a.o failed, which we've 
documented a change for this to go to a new svn pre-release location, 
but I need to work this out in the release prep.


- rpm upload to new svn location, too, once debs are done.

Once I have the packages uploaded, we can start a (quick?) vote! I'll 
have some time to keep banging on the uploads later this afternoon and 
see how far I can get. I'm on a mobile hotspot with a decent connection 
at the moment :)


[0] 
https://repository.apache.org/content/repositories/orgapachecassandra-1174/org/apache/cassandra/apache-cassandra/4.0-alpha1/


Michael

On 8/29/19 2:30 PM, Joseph Lynch wrote:

We hashed this out a bit in slack and I think the current rough
consensus (please speak up if you don't agree) is that we update our
release guidelines [1] to allow API changes between alpha and beta as
the common artifact is useful for testing and we will probably end up
finding API breakage while testing that must be fixed. Benedict helped
out by creating 4.0-alpha [2] and 4.0-beta [3] fix versions so we can
track what tickets are (roughly) blocking the next alpha/beta release.
If you feel that something you're working on should block the alpha or
the beta please help out and tag it with the proper fix version. The
idea is that we know which outstanding tickets exist and are impacting
the next alpha/beta, even if we ignore it and cut anyways at least we
can separate "this has to happen before beta" from "this has to happen
before release candidates".

I think the next decision is should we just cut 4.0-alpha1 now given
that Michael has some cycles regardless of the known issues and start
using the new fix versions for the 4.0-alpha2 release? I personally
feel we should cut 4.0-alpha1 with every imaginable "expect this
release to break" disclaimer and start working towards 4.0-alpha2.

[1] 
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit
[2] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%204.0-alpha
[3] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%204.0-beta

What do people think?
-Joey

On Wed, Aug 28, 2019 at 10:58 AM Michael Shuler  wrote:


Thanks for the reminder :) I have a few days of availability to prep a
4.0 alpha release. It's an alpha, so I don't have a problem with known
issues needing work.

I will have an internet-less period of time starting roughly Tuesday 9/3
through about Friday 9/13. I might get lucky and have a little network
access in the middle of that time, but I'm not counting on it.

--
Michael

On 8/28/19 10:51 AM, Jon Haddad wrote:

Hey folks,

I think it's time we cut a 4.0 alpha release.  Before I put up a vote
thread, is there a reason not to have a 4.0 alpha before ApacheCon /
Cassandra Summit?

There's a handful of small issues that I should be done for 4.0 (client
list in virtual tables, dynamic snitch improvements, fixing token counts),
I'm not trying to suggest we don't include them, but they're small enough I
think it's OK to merge them in following the first alpha.

Jon



-
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



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Builds email notifications

2019-09-04 Thread Michael Shuler




On 9/4/19 9:01 AM, Mick Semb Wever wrote:



This is going to be a job('Cassandra-template-artifacts') {publishers
...} step in the template, if I recall. Not sure what email plugins are
installed. I'd be happy to look at a PR.



Quick or the dead around here :-)

It has been done manually, and a separate PR opened here: 
https://github.com/apache/cassandra-builds/pull/10

But I need some help on testing and deploying it, so a review/input would be 
most appreciated!


I'm sure we were typing at the same time :) (PR comments went to dev@, 
so we all saw that, too..)


Testing DSL changes is a PITA and needs some sort of non-functional 
meta-DSL job to configure dummy jobs. Just committing, watching for 
errors in the seed job and fixing them isn't very problematic. The 
existing jobs are not touched, if the DSL does not parse correctly, and 
the errors are usually pretty clear where the issue might be. Just do it 
in prod, once it looks about what we want. ;)


--
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Builds email notifications

2019-09-04 Thread Michael Shuler




On 9/4/19 8:33 AM, Mick Semb Wever wrote:



Jenkins does have this functionality: with "E-mail Notification"
configuration under the "Post-build Actions" section. Emails are sent
when a build fails, becomes unstable or returns to stable, to a
specified ML and the authors of the breakage.

Is there any objection if I configure this for our
`cassandra-*-artifacts` builds?
And if I create a builds@ ML where these get cc'd?



Done.


Was this done by hand in Jenkins? I don't see any new commits to the job 
DSL, so the changes will get overwritten on the next cassandra-build 
push when the job configs are rebuilt.


https://gitbox.apache.org/repos/asf?p=cassandra-builds.git

Job DSL configs are in jenkins-dsl/cassandra_job_dsl_seed.groovy and DSL 
API reference can be viewed in Jenkins at 
https://builds.apache.org/plugin/job-dsl/api-viewer/index.html


This is going to be a job('Cassandra-template-artifacts') {publishers 
...} step in the template, if I recall. Not sure what email plugins are 
installed. I'd be happy to look at a PR.


--
Kind regards,
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: 4.0 alpha before apachecon?

2019-08-28 Thread Michael Shuler
Thanks for the reminder :) I have a few days of availability to prep a 
4.0 alpha release. It's an alpha, so I don't have a problem with known 
issues needing work.


I will have an internet-less period of time starting roughly Tuesday 9/3 
through about Friday 9/13. I might get lucky and have a little network 
access in the middle of that time, but I'm not counting on it.


--
Michael

On 8/28/19 10:51 AM, Jon Haddad wrote:

Hey folks,

I think it's time we cut a 4.0 alpha release.  Before I put up a vote
thread, is there a reason not to have a 4.0 alpha before ApacheCon /
Cassandra Summit?

There's a handful of small issues that I should be done for 4.0 (client
list in virtual tables, dynamic snitch improvements, fixing token counts),
I'm not trying to suggest we don't include them, but they're small enough I
think it's OK to merge them in following the first alpha.

Jon



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Stability of MaterializedView in 3.11.x | 4.0

2019-08-27 Thread Michael Shuler
It appears that you found the first message of the chain. I suggest 
reading the linked JIRA and the complete dev@ thread that arrived at 
this conclusion; there are loads of well formed opinions and 
information. Users of MVs *must* determine for themselves, through 
thorough testing and understanding, if they wish to use them.


Linkage:
https://issues.apache.org/jira/browse/CASSANDRA-13959
 (sub-linkage..)
 https://issues.apache.org/jira/browse/CASSANDRA-13595
 https://issues.apache.org/jira/browse/CASSANDRA-13911
 https://issues.apache.org/jira/browse/CASSANDRA-13880
 https://issues.apache.org/jira/browse/CASSANDRA-12872
 https://issues.apache.org/jira/browse/CASSANDRA-13747

Very much worth reading the complete thread:
part1: 
https://lists.apache.org/thread.html/d81a61da48e1b872d7599df4edfa8e244d34cbd591a18539f724796f@
part2: 
https://lists.apache.org/thread.html/19b7fcfd3b47f1526d6e993b3bb97f6c43e5ce204bc976ec0701cdd3@


Quick JQL for open tickets with "mv":
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20text%20~%20mv%20AND%20status%20!%3D%20Resolved

--
Michael

On 8/27/19 5:01 AM, pankaj gajjar wrote:

Hello,



concern about Materialized Views (MVs) in Cassandra. Unfortunately starting
with version 3.11, MVs are officially considered experimental and not ready
for production use, as you can read here:



http://mail-archives.apache.org/mod_mbox/cassandra-user/201710.mbox/%3cetpan.59f24f38.438f4e99.7...@apple.com%3E



Can you please someone give some productive feedback on this ? it would
help us to further implementation around the MVs in Cassandra.



Does anyone facing some critical issue or data lose or synchronization
issue ?



Regards

Pankaj.



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Contributing cassandra-diff

2019-08-22 Thread Michael Shuler
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

On 8/22/19 10:33 AM, Sankalp Kohli wrote:

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. Yes, that could 
be handled in a single repo, but with different repos we'd get natural 
boundaries.

-Original Message-
From: Sumanth Pasupuleti 
Sent: den 22 augusti 2019 14:40
To: dev@cassandra.apache.org
Subject: Re: Contributing cassandra-diff

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 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.


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/cassandra-diff.git 2. create a generic
repos/asf/cassandra-contrib.git where we can add

more

contributed tools in the future

Temporary location:
https://protect2.fireeye.com/url?k=e8982d07-b412e678-e8986d9c-86717
581b0b5-292bc820a13b7138=1=https%3A%2F%2Fgithub.com%2Fkrummas%2
Fcassandra-diff

Cassandra-diff is a spark job that compares the data in two
clusters -

it

pages through all partitions and reads all rows for those
partitions in both clusters to make sure they are identical. Based
on the

configuration

variable “reverse_read_probability” the rows are either read
forward or

in

reverse order.

Our main use case for cassandra-diff has been to set up two
identical clusters, transfer a snapshot from the cluster we want to
test to these clusters and upgrade one side. When that is done we
run this tool to

make

sure that 2.1 and 3.0 gives the same results. A few examples of the

bugs we

have found using this tool:

* CASSANDRA-14823: Legacy sstables with range tombstones spanning

multiple

index blocks create invalid bound sequences on 3.0+
* CASSANDRA-14803: Rows that cross index block boundaries can cause
incomplete reverse reads in some cases
* CASSANDRA-15178: Skipping illegal legacy cells can break reverse
iteration of indexed partitions

/Marcus

---
-- 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



B‹CB•È[œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PØ\ÜØ[™˜K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ]‹Z[Ø\ÜØ[™˜K˜\XÚK›Ü™ÃBƒB


-
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: Apache Cassandra Virtual meetings

2019-08-19 Thread Michael Shuler

On 8/19/19 3:40 PM, Dinesh Joshi wrote:

shared Google Calendar


This. I adore simple gcal additions and use quite a few. Thanks for the 
suggestion!


I would also, selfishly, love to get some folks actively posting things 
to #cassandra-dev during NGCC/ApacheCon, since I cannot attend. I'll be 
offshore with no internet access for several days, but just want a way 
to keep up with conversations and presentations.


--
Warm regards,
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Isn't there a workable cassandra java source for developing as other big data system?

2019-07-16 Thread Michael Shuler
You have a dirty build environment. Your path of "/cassandra-trunk/src" 
in the error and the suggestion on slack that you are trying to build 
cassandra-3.11.3 shows me you need to start over fresh. Here you go:


build docs:
http://cassandra.apache.org/doc/latest/development/ide.html

build steps pasted in slack:#cassandra:
  cd /tmp/
  git clone https://github.com/apache/cassandra.git
  cd cassandra/
  git checkout cassandra-3.11.3
  ant artifacts

BUILD SUCCESSFUL
Total time: 1 minute 32 seconds

--
Kind regards,
Michael

On 7/16/19 9:01 AM, Benedict Elliott Smith wrote:

3.11.3 compiles just fine, I have just corroborated.  Sir Jeff is in
fact a Cassandra developer, so please feel free to engage with his
question, which was designed to help diagnose your problem.



On 16 Jul 2019, at 14:54, Nimbus Lin  wrote:

To Sir Jeff: your method of "ant realclean" doesn't work, but
delete the needing library in build/jars/.

To other Cassandra's developers: Hi, is there any Cassandra's
developers here ?, would you like to tell me which version
cassandra's java source is really able to be build and run well?
or  how to solve the only  3 compile errors in  AbstractRow.java
for version 3.11.3?   If cassandra's source is not really free for
developing, then maybe it is better for me to change to other big
data system's source  to develop.

Isn't there a workable cassandra java source for developing  as
other big data system?



Thank you!

Sincerely Nimbuslin(Lin JiaXin) Mobile: 0086 180 5986 1565 Mail:
jiaxin...@live.com

-



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




-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Request for review - 2 jiras for 3.0/3.11

2019-07-08 Thread Michael Shuler
Resending as a new req-for-review thread for visibility, since they look 
important to my untrained eye:


https://issues.apache.org/jira/browse/CASSANDRA-15097
https://issues.apache.org/jira/browse/CASSANDRA-15098

Michael

 Forwarded Message 
Subject: Re: Time for a new 3.0/3.11 release?
Date: Wed, 3 Jul 2019 10:38:38 -0700
From: Jay Zhuang 
Reply-To: dev@cassandra.apache.org
To: dev@cassandra.apache.org

I'd like to raise some attention for the following 2 tickets, they're
patch-ready and deployed on all our production clusters:
* CASSANDRA-15098: "Endpoints no longer owning tokens are not removed for
vnode"
  For vNode cluster, the replaced node may not be removed from gossiper
(and system.peers, every time a node restart, they will be re-populated
into gossiper from system.peers). The patch is pretty small and
straightforward.
* CASSANDRA-15097: "Avoid updating unchanged gossip state"
  I think this is a bug because it's not only causing large pending gossip
tasks, it's also causing long token-metadata update lock for large vNode
cluster.

Here is another improvement we made for vNode to avoid gossip block during
removeNode: CASSANDRA-15141. But I think it can wait until 4.x. It mostly
causes problem for 1000+ vNode clusters.

Thanks,
Jay

On Tue, Jul 2, 2019 at 10:28 PM Mick Semb Wever  wrote:




> Is there any chance to get CASSANDRA-15005 (ready, with PR) into a
> 3.11.5 release?


I doubt it Soroka. It's not a bug and there's no patch for it, so I'd see
no reason why Michael would wait for this when he generously finds time to
cut a release.

Maybe the author and reviewer decides to push it to both 3.11.x and 4.0,
but that's irrelevant to this thread.

regards,
Mick

-
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: Time for a new 3.0/3.11 release?

2019-07-08 Thread Michael Shuler

On 7/3/19 1:44 PM, aj...@apache.org wrote:

In fact there is a branch for it noted in the ticket, from which a
patch could be cut instantly, but there doesn't seem to be any point
to doing that until the feature freeze is over. Is there any sense of
timing on that? I've seen a few discussions about release process for
4.x on this list, but I haven't been able to get a sense of how long
it might be.


I see a couple different links to a couple different branches and a 
github compare with conflicts in comments in CASSANDRA-15005. I see no 
PR link, and the project doesn't use PRs in practice. There is no patch 
attached to the jira. I also see a link to an open related jira and 
discussion around that. I don't know the details of the actual 
feature/improvement, but the discussion appears (to me) to still be a 
discussion. It does not look (to me) like a finalized patch with 
completed CI links, etc. ready for someone to review. Regardless, it 
does not appear (to me) to be appropriate for 3.11.x.


The cassandra-3.11 branch is in maintenance mode, which means no new 
features. Improvements require discussion and consensus for inclusion in 
maintenance branches, in order to keep breaking changes to a minimum. 
New features should target the trunk branch (4.0), unless there is a 
previously obtained consensus to include a particular 
improvement/feature in an earlier branch. Indeed, the trunk branch has 
been frozen for new feature inclusion for quite some time, and there 
have been some limited discussions on how long this might be. "When it's 
done" is basically the current answer, while the existing in-flight, 
approved feature jiras are still in progress or under review.


With trunk frozen, this feature may need to simply wait. This is an 
example of a possible problem with a long-frozen trunk branch - new 
things may need to sit in limbo for a while, until cassandra-4.0 is 
branched and there is an opportunity to commit new features to trunk again.


I hope that helps! Some of the above is definitely my understanding and 
some subjective observation of that specific jira.


(An update on the current state of in-progress/review statuses for 4.0 
jiras from the folks working on them would be awesome! hint hint.)


Kind regards,
Michael



On Wed, Jul 3, 2019, 1:28 AM Mick Semb Wever mailto:m...@apache.org>> wrote:


Is there any chance to get CASSANDRA-15005 (ready, with PR) into a 
3.11.5 release?



I doubt it Soroka. It's not a bug and there's no patch for it, so I'd
see no reason why Michael would wait for this when he generously
finds time to cut a release.

Maybe the author and reviewer decides to push it to both 3.11.x and
4.0, but that's irrelevant to this thread.

regards, Mick

-


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: Time for a new 3.0/3.11 release?

2019-07-01 Thread Michael Shuler

On 7/1/19 3:32 PM, Blake Eggleston wrote:

Any objections to doing a new 3.0 and 3.11 release? Both branches
have accumulated a decent number of changes since their last release,
the highlights being improved merkle tree footprint, a gossip race,
and a handful of 2.1 -> 3.x upgrade bugs.


I was looking at these changelogs, recently, and time since last 
releases, when trying to fix the downloads page. Yep, it's time :)


I am about to take some time off for the rest of this week, but can roll 
up some releases & start a vote on July 8th-ish, if there's no 
objections that pop up.


--
Kind regards,
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



"4.0: TBD" -> "4.0: Est. Q4 2019"?

2019-05-23 Thread Michael Shuler

We've had 4.0 listed as TBD release date for a very long time.

Yesterday, Alexander Dejanovski got a "when's 4.0 going to release?" 
question after his repair talk and he suggested possibly Q4 2019. This 
morning Nate McCall hinted at possibly being close by ApacheCon Las 
Vegas in September. These got me thinking..


Think we can we shoot for having a 4.0 alpha/beta/rc ready to 
announce/release at ApacheCon? At that time, we'll have been frozen for 
1 year, and I think we can. We'll GA release when it's ready, but I 
think Q4 could be an realistic target.


With that said, I'd like to change "TBD" on the downloads page to "Est. 
Q4 2019". We can always push or pull the estimate, but I think it's time 
to have a goal line. This lines up with ApacheCon nicely for a preview 
release.


Any concerns or objections to editing the download page? Have some other 
goal timeframe in mind?


--
Warm regards,
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Choosing a supported Python 3 major version for cqlsh

2019-03-18 Thread Michael Shuler
On 3/18/19 9:52 PM, Michael Shuler wrote:
> On 3/18/19 9:06 PM, Patrick Bannister wrote:
>> I recommend we pick the longest supported stable release available. That
>> would be Python 3.7, which is planned to get its last release in 2023, four
>> years from now.
>> - Python 3.5 was planned to get its last major release yesterday
>> - Python 3.6 is planned to get its last major release in December 2021,
>> about three years from now
>>
>> Any feedback on picking a tested Python version for cqlshlib? I'm inclined
>> to focus on Python 3.7 as we push toward finishing the ticket.
> 
> The correct method of choosing this would be to target runtime
> functionality on the version in the latest LTS release of the likely
> most-used OS. Ubuntu 18.04 LTS comes with python-3.6.5. I would think it
> highly likely that if it runs properly on 3.6, it should run on 3.7
> fine. Using some 3.7-only feature/syntax and making it difficult on
> people to install/use on Ubuntu LTS would be user-unfriendly.
> 
> https://packages.ubuntu.com/bionic/python3
> 
> There is not a similar CentOS package search, but I see a couple docs
> say that python-3.6 is available via the SCL repository for this OS. I
> do not see a 3.7 installation noted.

No python-3.7 install in the SCL repos:
https://www.softwarecollections.org/en/scls/?search=python==_by=-create_date_page=10

> Shoot for the lowest common denominator in real world usage, not the
> latest release from upstream. Super strong opinion, here.
> 

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Choosing a supported Python 3 major version for cqlsh

2019-03-18 Thread Michael Shuler
On 3/18/19 9:06 PM, Patrick Bannister wrote:
> I recommend we pick the longest supported stable release available. That
> would be Python 3.7, which is planned to get its last release in 2023, four
> years from now.
> - Python 3.5 was planned to get its last major release yesterday
> - Python 3.6 is planned to get its last major release in December 2021,
> about three years from now
> 
> Any feedback on picking a tested Python version for cqlshlib? I'm inclined
> to focus on Python 3.7 as we push toward finishing the ticket.

The correct method of choosing this would be to target runtime
functionality on the version in the latest LTS release of the likely
most-used OS. Ubuntu 18.04 LTS comes with python-3.6.5. I would think it
highly likely that if it runs properly on 3.6, it should run on 3.7
fine. Using some 3.7-only feature/syntax and making it difficult on
people to install/use on Ubuntu LTS would be user-unfriendly.

https://packages.ubuntu.com/bionic/python3

There is not a similar CentOS package search, but I see a couple docs
say that python-3.6 is available via the SCL repository for this OS. I
do not see a 3.7 installation noted.

Shoot for the lowest common denominator in real world usage, not the
latest release from upstream. Super strong opinion, here.

-- 
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Cassandra repo keys are revoked

2019-03-11 Thread Michael Shuler
On 3/11/19 2:41 PM, Michael Shuler wrote:
> On 3/11/19 8:36 AM, staticp...@gmail.com wrote:
>> Hello,
>>
>> It appears the keys listed here are outdated. 
>> https://www.apache.org/dist/cassandra/KEYS
>>
>> Trying to install Casandra 311x on Ubuntu 18.0.4. The recommendation is to 
>> use the keys from the link above however, the one of them is revoked. Others 
>> on this page are in the same state as well. Can someone from the dev group 
>> clean this up? It's a little unsettling when the official documentation - 
>> http://cassandra.apache.org/download/ gives instructions to download revoked 
>> keys. 
>>
>> apt-key list
>>
>> 
>> pub   rsa4096 2014-06-16 [SCEA] [revoked: 2016-08-16]
>>   7B0A 593A 9795 A964 AD57  D255 D46C 5ECB FE4B 2BDA
>> uid   [ revoked] Michael Shuler 
>>
>> pub   rsa4096 2009-07-15 [SC]
>>   A26E 528B 271F 19B9 E5D8  E19E A278 B781 FE4B 2BDA
>> uid   [ unknown] Michael Shuler 
>> uid   [ unknown] Michael Shuler 
>> sub   rsa4096 2009-07-15 [E]
> 
> 
> These are not the same keys. It looks like you possibly did a short-key
> import (FE4B2BDA), as well as the long-key import, as the download
> instructions indicate.  Here's my valid key:
> 
> mshuler@hana:~$ gpg --list-secret-key --fingerprint FE4B2BDA
> gpg: please do a --check-trustdb
> sec   rsa4096 2009-07-15 [SC]
>   A26E 528B 271F 19B9 E5D8  E19E A278 B781 FE4B 2BDA
> uid   [ unknown] Michael Shuler 
> uid   [ unknown] Michael Shuler 
> ssb   rsa4096 2009-07-15 [E]
> 
> In 2016, someone took a list of the strong key set and uploaded keys
> with faked short-key identifiers matching those of existing keys. It's a
> joe job to identify the weakness of using short key identifiers. There
> are thousands of these fake keys, and they've been revoked.
> 
> https://www.zdnet.com/article/pgp-security-weakness-exposed/
> 
> Drop that bogus key from apt-keys:
> 
> apt-key del D46C5ECBFE4B2BDA
> 
> This message is signed with the correct key.

I forgot to mention that the bogus key you imported from a public key
server is *not* contained in https://www.apache.org/dist/cassandra/KEYS
- feel free to verify that independently.

-- 
Kind regards,
Michael



signature.asc
Description: OpenPGP digital signature


Re: Cassandra repo keys are revoked

2019-03-11 Thread Michael Shuler
On 3/11/19 8:36 AM, staticp...@gmail.com wrote:
> Hello,
> 
> It appears the keys listed here are outdated. 
> https://www.apache.org/dist/cassandra/KEYS
> 
> Trying to install Casandra 311x on Ubuntu 18.0.4. The recommendation is to 
> use the keys from the link above however, the one of them is revoked. Others 
> on this page are in the same state as well. Can someone from the dev group 
> clean this up? It's a little unsettling when the official documentation - 
> http://cassandra.apache.org/download/ gives instructions to download revoked 
> keys. 
> 
> apt-key list
> 
> 
> pub   rsa4096 2014-06-16 [SCEA] [revoked: 2016-08-16]
>   7B0A 593A 9795 A964 AD57  D255 D46C 5ECB FE4B 2BDA
> uid   [ revoked] Michael Shuler 
> 
> pub   rsa4096 2009-07-15 [SC]
>   A26E 528B 271F 19B9 E5D8  E19E A278 B781 FE4B 2BDA
> uid   [ unknown] Michael Shuler 
> uid   [ unknown] Michael Shuler 
> sub   rsa4096 2009-07-15 [E]


These are not the same keys. It looks like you possibly did a short-key
import (FE4B2BDA), as well as the long-key import, as the download
instructions indicate.  Here's my valid key:

mshuler@hana:~$ gpg --list-secret-key --fingerprint FE4B2BDA
gpg: please do a --check-trustdb
sec   rsa4096 2009-07-15 [SC]
  A26E 528B 271F 19B9 E5D8  E19E A278 B781 FE4B 2BDA
uid   [ unknown] Michael Shuler 
uid   [ unknown] Michael Shuler 
ssb   rsa4096 2009-07-15 [E]

In 2016, someone took a list of the strong key set and uploaded keys
with faked short-key identifiers matching those of existing keys. It's a
joe job to identify the weakness of using short key identifiers. There
are thousands of these fake keys, and they've been revoked.

https://www.zdnet.com/article/pgp-security-weakness-exposed/

Drop that bogus key from apt-keys:

apt-key del D46C5ECBFE4B2BDA

This message is signed with the correct key.

-- 
Kind regards,
Michael



signature.asc
Description: OpenPGP digital signature


Re: Both Java 8 and Java 11 required for producing a tarball

2019-03-06 Thread Michael Shuler
On 3/6/19 7:10 PM, Stefan Miklosovic wrote:
> I am trying to build 4.0 from sources and prior to this I was doing
> 
> ant artifacts
> 
> in order to get distribution tarball to play with.
> 
> If I understand this right, if I do not run Ant with Java 11,
> java.version.8 will be true so it will skip building tarballs.

Correct. You'll get a JDK8-only jar, but no full tar artifact set.

> 1) Why would one couldnt create a tarball while running on Java 8 only?

The build system needs a dual-JDK install to build the artifacts with
support for each/both.

> 2) What is the current status of Java 11 / Java 8? Is it there just "to try
> it out if it runs with that" or are there different reasons behind it?

JDK8 runtime is the default, JDK11 runtime is optional, but supported.
Here's the JIRA with all the details:
https://issues.apache.org/jira/browse/CASSANDRA-9608

I just pushed a WIP branch to do a dual-JDK build via docker, since we
need to work on this, too. (lines may wrap:)

git clone -b tar-artifact-build
https://gitbox.apache.org/repos/asf/cassandra-builds.git

cd cassandra-builds/

docker build -t cass-build-tars -f docker/buster-image.docker docker/

docker run --rm -v `pwd`/dist:/dist `docker images -f
label=org.cassandra.buildenv=buster -q` /home/build/build-tars.sh trunk

After all that, here's my tar artifacts:

(tar-artifact-build)mshuler@hana:~/git/cassandra-builds$ ls -l dist/
total 94328
-rw-r--r-- 1 mshuler mshuler 50385890 Mar  6 21:16
apache-cassandra-4.0-SNAPSHOT-bin.tar.gz
-rw-r--r-- 1 mshuler mshuler 46198947 Mar  6 21:16
apache-cassandra-4.0-SNAPSHOT-src.tar.gz

Or you could drop a dual-JDK install on your machine, export the env
vars you found and `ant artifacts` should produce the tars :)

-- 
Kind regards,
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Looking for common cases in cassandra fit to autoheal

2019-03-01 Thread Michael Shuler
Your request is not related to the topic of this mailing list, the
development of Apache Cassandra. Your question would be better suited
for the user@ mailing list. Your question is also quite vague, and you
might include some detail or context about what exactly you are looking
for. You may also wish to drop the unenforceable email footer or use a
personal email address, if it's appended by your mail server.

-- 
Kind regards,
Michael
http://www.pbandjelly.org/2011/03/to-whom-it-may-concern/

On 3/1/19 2:33 PM, Sundaramoorthy, Natarajan wrote:
> Can someone please reply? Thanks
>  
>  
> 
> 
> -Original Message-
> From: Sundaramoorthy, Natarajan [mailto:natarajan_sundaramoor...@optum.com] 
> Sent: Wednesday, February 27, 2019 3:17 PM
> To: dev@cassandra.apache.org
> Subject: Looking for common cases in cassandra fit to autoheal
> 
> Can someone please provide some common cases in cassandra which can be 
> candidate for autoheal? Looking for log files and issue..Both from VM and/or 
> pod world welcome...Thanks in advance for help
> 
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
> 
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
> 
> 
> -
> 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: CASSANDRA-14482

2019-02-15 Thread Michael Shuler
+0.5

I skimmed the jira and github diff and a few things came to mind:
- There are multiple comments about using an older jar than the latest
version.
- I did not see any performance test results to form an opinion on any
gains/caveats as a user. This was the first thing I looked for.
- I did not see any conf/cassandra.yaml comment in the diff for the
valid class_name configuration option to use.

Seems interesting, and there are comments about 4.0 being in a freeze
and all, but OK on it being non-default.

-- 
Michael

On 2/15/19 11:43 AM, Ariel Weisberg wrote:
> Hi,
> 
> I am +1 since it's an additional compressor and not the default.
> 
> Ariel
> 
> On Fri, Feb 15, 2019, at 11:41 AM, Dinesh Joshi wrote:
>> Hey folks,
>>
>> Just wanted to get a pulse on whether we can proceed with ZStd support. 
>> The consensus on the ticket was that it’s a very valuable addition 
>> without any risk of destabilizing 4.0. It’s ready to go if there aren’t 
>> any objections.
>>
>> Dinesh
>>
>> -
>> 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
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RELEASE] Apache Cassandra 2.1.21 released

2019-02-11 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.1.21.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 2.1 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: (CHANGES.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-2.1.21
[2]: (NEWS.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-2.1.21
[3]: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RELEASE] Apache Cassandra 2.2.14 released

2019-02-11 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.2.14.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 2.2 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: (CHANGES.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-2.2.14
[2]: (NEWS.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-2.2.14
[3]: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RELEASE] Apache Cassandra 3.0.18 released

2019-02-11 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.0.18.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.0 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: (CHANGES.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.0.18
[2]: (NEWS.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.0.18
[3]: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RELEASE] Apache Cassandra 3.11.4 released

2019-02-11 Thread Michael Shuler
The Cassandra team is pleased to announce the release of Apache
Cassandra version 3.11.4.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 3.11 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: (CHANGES.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.11.4
[2]: (NEWS.txt)
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.11.4
[3]: https://issues.apache.org/jira/browse/CASSANDRA

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 2.1.21

2019-02-11 Thread Michael Shuler
I count 7 binding +1's, 1 non-binding +1 vote, and no others, so this
vote passes. I'll publish the artifacts as soon as I can.

Thanks for the discussion on support life of the 2.1 branch. I will not
be making any changes to the notes on the download page.

Kind regards,
Michael

On 2/2/19 6:32 PM, 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
> 




signature.asc
Description: OpenPGP digital signature


Re: [VOTE PASSED] Release Apache Cassandra 2.2.14

2019-02-11 Thread Michael Shuler
With 7 binding +1 votes, 2 non-binding +1, and no others, this vote
passed. I'll upload the artifacts as soon as possible.

Kind regards,
Michael

On 2/2/19 6: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
> 




signature.asc
Description: OpenPGP digital signature


  1   2   3   4   >