Re: Changing the output of tooling between majors
On Fri, Jul 7, 2023 at 10:20 AM Miklosovic, Stefan < stefan.mikloso...@netapp.com> wrote: > Hi list, > > I want to clarify the policy we have when we want to / going to change the > output of the tooling (nodetool or tools/bin etc.). > > I am not sure it is written somewhere explicitly, but how I get it from > the gossip over years is that we should not change the output (e.g. > changing the name of fields etc) in minors, but for majors (4.0 -> 5.0), > this is OK, correct? > > For example, when some tool prints this: > > thisIsAStatistic: 10 > > and we see that all other lines in that output print it like this: > > This Is Another Statistic: abc > > scratching the itch is almost irresistible so we want to change the output > to: > > This Is a Statistic: 10 > > This is the natural way how fixes are done. We are improving the output, > making it consistent etc. > > Someone may argue that we are changing "public api" and people are > actually parsing the output like this and we better not to change it > because we might break "the scripts" for somebody. > If that output is (or at some earlier point, was) the most obvious way to obtain something, then for all intents and purposes it is a public api. When it's changed, you should assume it *will* break scripts. > While I get this for minors and it is understandable that minors should be > same, is this relevant for majors? Because if we care about majors too in > this situation, how are we supposed to evolve the output over time? Is it > supposed to be just frozen for ever? I do not buy this argument. For > minors, fine. But for majors, I do not think so. > Majors are expected to be more disruptive, but I don't personally interpret that as a license to be disruptive. The pain this creates isn't any less because it is a major. > > I feel like "not break the output because API" is more or less an urban > legend we keep repeating ourselves. I yet need to meet somebody who is > stressing over the fact that her output changed *between majors*. > Hi Stefan, I'm Eric, nice to meet you; I stress a great deal at all of the changes —large and small— that occur between major versions. :) They create additional work, introduce risk, and often end up delaying (by months and years even) a major upgrade. You might be surprised by the kind of breakage (often subtle) that even the smallest changes can create, or how frustrating it can be when it was only done to satisfy a sense of aesthetics. > If that is the case, we should start to treat this problem completely > differently and we should not rely on the output of tooling at all and we > should either provide corresponding JMX method to retrieve it or we should > offer other formats tooling prints, like JSON or YAML. Absolutely. But I think the right thing in this situation is to acknowledge that the console output is a contract, and act accordingly. In this case: offer (and promote) those structured replacements (JSON, YAML), document the intended instability, and follow through after a sufficient window. -- Eric Evans john.eric.ev...@gmail.com
Re: Changing the output of tooling between majors
On Sun, Jul 9, 2023 at 9:10 PM Dinesh Joshi wrote: > On Jul 8, 2023, at 8:43 AM, Miklosovic, Stefan < > stefan.mikloso...@netapp.com> wrote: > > > > If we are providing CQL / JSON / YAML for couple years, I do not believe > that the argument "lets not break it for folks in nodetool" is still > relevant. CQL output is there from times of 4.0 at least (at least!) and > YAML / JSON is also not something completely new. It is not like we are > suddenly forcing people to change their habits, there was enough time to > update the stuff to CQL / json / yaml etc ... > > > What % of Cassandra users are using 4.0+? Operators who upgrade to 4.0 and > beyond may still use their existing scripts. Therefore keeping things > stable is important. Until nodetool can support JSON as output format for > all interaction and there is a significant adoption in the user community, > I would strongly advise against making breaking changes to the CLI output. > +1 -- Eric Evans john.eric.ev...@gmail.com
Re: Changing the output of tooling between majors
On Wed, Jul 12, 2023 at 1:54 AM Miklosovic, Stefan < stefan.mikloso...@netapp.com> wrote: > I agree with Jackson that having a different output format (JSON/YAML) in > order to be able to change the default output resolves nothing in practice. > > As Jackson said, "operators who maintain these scripts aren’t going to > re-write them just because a better way of doing them is newly available, > usually they’re too busy with other work and will keep using those old > scripts until they stop working". > > This is true. If this approach is adopted, what will happen in practice is > that we change the output and we provide a different format and then a user > detects this change because his scripts changed. As he has existing > solution in place which parses the text from human-readable output, he will > try to fix that, he will not suddenly convert all scripting he has to > parsing JSON just because we added it. Starting with JSON parsing might be > done if he has no scripting in place yet but then we would not cover > already existing deployments. > I think this is quite an extreme conclusion to draw. If tooling had stable, structured output formats, and if we documented an expectation that human-readable console output was unstable, then presumably it would be safe to assume that any new scripters would avail themselves of the stable formats, or expect breakage later. I think it's also fair to assume that at least some people would spend the time to convert their scripts, particularly if forced to revisit them (for example, after a breaking change to console output). As someone who manages several large-scale mission-critical Cassandra clusters under constrained resources, this is how I would approach it. TL;DR Don't let perfect by the enemy of good <https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good> [ ... ] > > For that reason, what we could agree on is that we would never change the > output for "tier 1" commands and if we ever changed something, it would be > STRICT ADDITIONS only. In other words, everything it printed, it would > continue to print that for ever. Only new lines could be introduced. We > need to do this because Cassandra is evolving over time and we need to keep > the output aligned as new functionality appears. But the output would be > backward compatible. Plus, we are talking about majors only. > > The only reason we would ever changed the output on "tier 1" commands, if > is not an addition, is the fix of the typo in the existing output. This > would again happened only in majors. > > All other output for all other commands might be changed but their output > will not need to be strictly additive. This would again happen only between > majors. > > What is you opinion about this? > To be clear about where I'm coming from: I'm not arguing against you or anyone else making changes like these (in major versions, or otherwise). If —for example— we had console output that was incorrect, incomplete, or obviously misleading, I'd absolutely want to see that fixed, script breakage be damned. All I want is for folks to recognize the problems this sort of thing can create, and show a bit of empathy before submitting a change. For operators on the receiving end, it can be really frustrating, especially when there is no normative change (i.e. it's in service of aesthetics). -- Eric Evans Staff SRE, Data Persistence Wikimedia Foundation
Re: Changing the output of tooling between majors
On Thu, Jul 13, 2023 at 9:44 AM Miklosovic, Stefan < stefan.mikloso...@netapp.com> wrote: > For example Dinesh said this: > > "Until nodetool can support JSON as output format for all interaction and > there is a significant adoption in the user community, I would strongly > advise against making breaking changes to the CLI output." > > That is where I get the need to have a JSON output in order to fix a typo > from. That is if we look at fixing a typo as a breaking change. Which I > would say it is as if somebody is "greping" it and it is not there, it will > break. > > Do you understand that the same way or am I interpreting that wrong? > I interpreted this to mean: If we want to get to a place where we can freely edit human-readable output formats, we should provide stable alternatives. > > > From: C. Scott Andreas > Sent: Thursday, July 13, 2023 16:35 > To: dev@cassandra.apache.org > Cc: dev > Subject: Re: Changing the output of tooling between majors > > NetApp Security WARNING: This is an external email. Do not click links or > open attachments unless you recognize the sender and know the content is > safe. > > > > > "From what I see you guys want to condition any change by offering > json/yaml as well." > > I don't think I've seen a proposal to block changes to nodetool output on > machine-parseable formats in this thread. > > Additions of new delimited fields to nodetool output are mostly > straightforward. Changes to fields that exist today are likely to cause > problems - as Josh mentions. These seem best to take on a case-by-case > basis rather than trying to hammer out an abstract policy. What changes > would you like to make? > > I do think we will have difficulty evolving output formats of text-based > Cassandra tooling until we offer machine-parseable output formats. > > – Scott > > On Jul 13, 2023, at 6:39 AM, Josh McKenzie wrote: > > > I just find it ridiculous we can not change "someProperty: 10" to "Some > Property: 10" and there is so much red tape about that. > Well, we're talking about programmatic parsing here. This feels like > complaining about a compiler that won't let you build if you're missing a ; > > We can change it, but that doesn't mean the aggregate cost/benefit across > our entire ecosystem is worth it. The value of correcting a typo is pretty > small, and the cost for everyone downstream is not. This is why we should > spellcheck things in API's before we release them. :) > > On Wed, Jul 12, 2023, at 2:45 PM, Miklosovic, Stefan wrote: > Eric, > > I appreciate your feedback on this, especially more background about where > you are comming from in the second paragraph. > > I think we are on the same page afterall. I definitely understand that > people are depending on this output and we need to be careful. That is why > I propose to change it only each major. What I feel is that everybody's > usage / expectations is little bit different and outputs of the commands > are very diverse and it is hard to balance this so everybody is happy. > > I am trying to come up with a solution which would not change the most > important commands unnecessarily while also having some free room to tweak > the existing commands where we see it appropriate. I just find it > ridiculous we can not change "someProperty: 10" to "Some Property: 10" and > there is so much red tape about that. > > If I had to summarize this whole discussion, the best conclustion I can > think of is to not change what is used the most (this would probably need > to be defined more explicitly) and if we have to change something else we > better document that extensively and provide json/yaml for people to be > able to divorce from the parsing of human-readable format (which probably > all agree should not happen in the first place). > > What I am afraid of is that in order to satisfy these conditions, if, for > example, we just want to fix a typo or the format of a key of some value, > the we would need to deliver JSON/YAML format as well if there is not any > yet and that would mean that the change of such triviality would require > way more work in terms of the implementation of JSON/YAML format output. > Some commands are quite sophisticated and I do not want to be blocked to > change a field in human-readable out because providing corresponding > JSON/YAML format would be gigantic portion of the work itself. > > From what I see you guys want to condition any change by offering > json/yaml as well and I dont know if that is just not too much. > > > _
Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)
On Mon, Oct 23, 2023 at 1:36 PM Jeff Jirsa wrote: > Why ship a ghost release we dont really expect people to use. Why not just > move the date so all the PR content highlighting TCM+Accord isnt a mess? > We won't move to 5.x until some time after the dust settles, and I can't see us starting that timer until after 5.1 (assuming that's when TCM+Accord lands). > > I get it, nobody wants to move dates. Isn't that the least-bad option? > I think so. > > On Mon, Oct 23, 2023 at 11:28 AM Aleksey Yeshchenko > wrote: > >> I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path >> instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in >> one hop. >> >> Nobody likes going through these upgrades. So I personally expect 5.0 to >> be a largely ghost release if we go this route, adopted by few, just a >> permanent burden on the merge path to trunk. >> >> Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord >> - there most certainly is - but with the expectation that 5.1 will follow >> up reasonably shortly after with all that *and* two highly anticipated >> features on top, I just don’t see the point. It will be another 2.2 release. >> >> >> On 23 Oct 2023, at 17:43, Josh McKenzie wrote: >> >> We discussed that at length in various other mailing threads Jeff - kind >> of settled on "we're committing to cutting a major (semver MAJOR or MINOR) >> every 12 months but want to remain flexible for exceptions when >> appropriate". >> >> And then we discussed our timeline for 5.0 this year and settled on the >> "let's try and get it out this calendar year so it's 12 months after 4.1, >> but we'll grandfather in TCM and Accord past freeze date if they can make >> it by October". >> >> So that's the history for how we landed here. >> >> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after >> 5.1.0 is? >> >> This is my understanding, yes. Deprecation and support drop is predicated >> on the 5.0 release, not any specific features or anything. >> >> On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote: >> >> >> >> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever wrote: >> >> >> The TCM work (CEP-21) is in its review stage but being well past our >> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would >> like to propose the following. >> >> >> >> I think this presumes that 5.0 GA is date driven instead of feature >> driven. >> >> I'm sure there's a conversation elsewhere, but why isn't this date >> movable? >> >> >> -- Eric Evans Staff SRE, Data Persistence Wikimedia Foundation
Re: Side Car New Repo vs not
> into the sidecar with a single atomic commit, we don't have to > > do two > > > > > > > phase > > > > > > > commits where we add some IPC mechanism to allow us to support > > it in > > > > > > > both, > > > > > > > then turn it on in the sidecar, then turn it off in the server, > > etc... > > > > > > > * I think that the verification is much easier (sounds like > > Jonathan > > > > > > > disagreed on the other thread, I could certainly be wrong), and > > we > > > > > don't > > > > > > > have to worry about testing matrices to assure that the sidecar > > works > > > > > > > with > > > > > > > various versions as the version of the sidecar that is released > > with > > > > > that > > > > > > > version of Cassandra is the only one we have to certify works. If > > > > > people > > > > > > > want to pull in new versions or maintain backports they can do > > that at > > > > > > > their discretion/testing. > > > > > > > * We can iterate and prove value before committing to a choice. > > Since > > > > > it > > > > > > > will be a separate artifact from the start we can always move the > > > > > > > artifact > > > > > > > to a separate repo later (but moving the other way is harder). > > > > > > > * Users will get the sidecar "for free" when they install the > > daemon, > > > > > > > they > > > > > > > don't need to take affirmative action to e.g. be able to restart > > their > > > > > > > cluster, run repair, or back their data up; it just comes out of > > the > > > > > box > > > > > > > for free. > > > > > > > > > > > > > > Unique pros of a separate repository sidecar: > > > > > > > * We can use a more modern build system like gradle instead of > > ant > > > > > > > * Merging changes is less "scary" I guess (I feel like if you're > > not > > > > > > > touching the daemon this is already true but I could see this > > being > > > > > less > > > > > > > worrisome for some). > > > > > > > * Releasing a separate artifact is somewhat easier from a > > separate > > > > > repo > > > > > > > (especially if we have gradle which makes e.g. building debs and > > rpms > > > > > > > trivial). > > > > > > > * We could backport to previous versions without getting into > > > > > arguments > > > > > > > about bug fixes vs features. > > > > > > > * Committers could be different from the main repo, which ... > > may be a > > > > > > > useful thing > > > > > > > > > > > > > > Non unique pros of a sidecar (could be achieved in the main repo > > or in > > > > > a > > > > > > > separate repo): > > > > > > > * A separate build artifact .jar/.deb/.rpm that can be installed > > > > > > > separately. It's slightly easier with a separate repo but > > certainly > > > > > not > > > > > > > out > > > > > > > of reach within a single repo (indeed the current patch already > > creates > > > > > a > > > > > > > separate jar, and we could create a separate .deb reasonably > > easily). > > > > > > > Personally I think having a separate .deb/.rpm is premature at > > this > > > > > point > > > > > > > (for companies that really want it they can build their own > > packages > > > > > > > using > > > > > > > the .jars), but I think it really is a distracting issue from > > where > > > > > the > > > > > > > patch should go as we can always choose to remove experimental > > .jar > > > > > files > > > > > > > that the main daemon doesn't touch. > > > > > > > * A separate process lifecycle. No matter where the sidecar > > goes, we > > > > > get > > > > > > > the benefit of restarting it being less dangerous for > > availability > > > > > than > > > > > > > restarting the main daemon. > > > > > > > > > > > > > > That all being said, these are strong opinions weakly held and I > > would > > > > > > > rather get something actually committed so that we can prove > > value one > > > > > > > way > > > > > > > or the other and am therefore, of course, happy to put sidecar > > patches > > > > > > > wherever someone can review and commit it. > > > > > > > > > > > > > > -Joey > > > > > > > > > > > > > > On Mon, Aug 20, 2018 at 1:52 PM sankalp kohli < > > kohlisank...@gmail.com> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > I am starting a new thread to get consensus on where the side > > car > > > > > > > > should be contributed. > > > > > > > > > > > > > > > > Please send your responses with pro/cons of each approach or > > any > > > > > other > > > > > > > > approach. Please be clear which approach you will pick while > > still > > > > > > > giving > > > > > > > > pros/cons of both approaches. > > > > > > > > > > > > > > > > Thanks. > > > > > > > > Sankalp > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Jon Haddad > > > > > > http://www.rustyrazorblade.com > > > > > > twitter: rustyrazorblade > > > > > > > > > > > > > > > - > > > > > 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 > > > > > -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Development Approach for Apache Cassandra Management process
On Wed, Sep 12, 2018 at 10:19 AM sankalp kohli wrote: > > Hi, > Community has been discussing about Apache Cassandra Management process > since April and we had lot of discussion about which approach to take to > get started. Several contributors have been interested in doing this and we > need to make a decision of which approach to take. > > The current approaches being evaluated are > a. Donate an existing project to Apache Cassandra like Reaper. If this > option is selected, we will evaluate various projects and see which one > fits best. > b. Take a piecemeal approach and use the features from different OSS > projects and build a new project. > > Available options to vote > a. +1 to use existing project. > b. +1 to take piecemeal approach > c -1 to both > d +0 I dont mind either option As others have pointed out, I think we're placing too much of an emphasis on voting; What we need is consensus, not a majority ruling. Obtaining consensus can be difficult, frustrating, and time-consuming, but IMO always worth it. My interpretation of the discussion is that there was at least consensus on the value of a project-supported management stack, as well as (I think) the notion that it should be kept loosely coupled to the database, beyond that things seem contentious. Assuming I'm not wrong, and there is consensus on a loosely-coupled project, why do we need to rush a decision on inclusion? What prevents those who are vested in one approach (or existing project) or another from working on what they think best? I suspect developing consensus here would be a lot easier if we were talking about something a bit more concrete. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: How to unsubscribe from this group
How did you subscribe? On Tue, Mar 26, 2019 at 9:24 AM Sundaramoorthy, Natarajan wrote: > > > > 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. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: How to unsubscribe from this group
On Tue, Mar 26, 2019 at 10:47 AM Russell Bradberry wrote: > > Responses like this aren't helpful. I can't even remember how I subscribed > to this list as it was nearly 8 years ago. The answer might be. We seem have a lot of people who struggle to unsubscribe and I am curious as to why that is. Is it just as difficult for people to subscribe (and we're not aware because we aren't seeing the questions)? Did they try and fail? > To answer the question, you can send a message to > dev-unsubscr...@cassandra.apache.org. Full instructions can be found here: > http://cassandra.apache.org/community/ > > -Russ > > On Tue, Mar 26, 2019 at 8:20 AM Eric Evans > wrote: > > > How did you subscribe? > > > > On Tue, Mar 26, 2019 at 9:24 AM Sundaramoorthy, Natarajan > > wrote: > > > > > > > > > > > > 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. > > > > > > > > -- > > Eric Evans > > john.eric.ev...@gmail.com > > > > ----- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: How to unsubscribe from this group
On Tue, Mar 26, 2019 at 11:22 AM Russell Bradberry wrote: > > This conversation comes up quite a bit as it pertains to a lot of Apache > groups, especially the Cassandra groups. I've advocated in the past for a > more standard way of unsubscribing, such as responding with "UNSUBSCRIBE" > in the subject line or body, or more of a link-based approach rather than a > special email account you need to send a message to. FWIW, it seems the List-Unsubscribe header is being set. For supported clients (most of the big ones apparently), this is supposed to result in a clickable unsubscribe link. Gmail is supposed to be one of the providers that supports this, and AFAICT the link is supposed to appear to the right of the address in each message, but this isn't working for me. > Thing is unless you subscribe to a lot of Apache mailing lists, this is not > a normal way of subscribing and unsubscribing from distributions. So, from > a user perspective, it's easy to see how people can get confused as to how > to actually unsubscribe. YMMV, I guess. I'm subscribed to a lot of mailing lists that work identically (and have been for years). I've never had an issue, and cannot think of another list where so many struggle with how to unsubscribe. It's why I always circle back to wondering what is different here. Is the list software buggy or less forgiving (i.e. do people try and fail)? Are we not presenting this information prominently enough on the site and/or are search engines not indexing it properly? > Which is why I linked to the Apache Cassandra > community page as an effort to point folks in the right direction that may > be wondering the same thing. I applaud the intent, but a lot of people have been tilting at this particular windmill for a while, and it doesn't seem to help. > On Tue, Mar 26, 2019 at 9:10 AM Eric Evans > wrote: > > > On Tue, Mar 26, 2019 at 10:47 AM Russell Bradberry > > wrote: > > > > > > Responses like this aren't helpful. I can't even remember how I > > subscribed > > > to this list as it was nearly 8 years ago. > > > > The answer might be. We seem have a lot of people who struggle to > > unsubscribe and I am curious as to why that is. Is it just as > > difficult for people to subscribe (and we're not aware because we > > aren't seeing the questions)? Did they try and fail? > > > > > To answer the question, you can send a message to > > > dev-unsubscr...@cassandra.apache.org. Full instructions can be found > > here: > > > http://cassandra.apache.org/community/ > > > > > > -Russ > > > > > > On Tue, Mar 26, 2019 at 8:20 AM Eric Evans > > > wrote: > > > > > > > How did you subscribe? > > > > > > > > On Tue, Mar 26, 2019 at 9:24 AM Sundaramoorthy, Natarajan > > > > wrote: > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > -- > > > > Eric Evans > > > > john.eric.ev...@gmail.com > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > -- > > Eric Evans > > john.eric.ev...@gmail.com > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > -- Eric Evans john.eric.ev...@gmail.com - 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
On Fri, Oct 18, 2019 at 12:30 AM Mick Semb Wever wrote: > > > > 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. > > > Or we can just say that committers can make releases, and the KEYS file can > change. > These tickets can be improvements later, rather than blockers now. It sounds like there is work to do on the mechanics of it all, and the more immediate issue of being overdue for a release. I realize you're lacking the karma to do the actual publishing, but you could create and sign the release artifacts and call a vote. When it passes, someone with the rights is going to have to step forward to ensure they are published, but surely we can manage that much. Do you want to do the honors? -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Cloudbees Operations Center and Client Masters upgrade this weekend.
Thanks Gavin! On Sun, Apr 5, 2020 at 11:32 AM Gavin McDonald wrote: > > Hi All, > > This is now completed. > > Overall time spent was around 3 hours on the Operations Center and 5 > masters. > > When the OC was being upgraded, there was no downtime for the masters. > > Each master had downtime of around 20 minutes to 30 minutes, including > multiple restarts > , backups and plugin upgrades. > > CouchDB folks - most of your nodes are connected via 'node connects to the > master' meaning that you'll > have to update each slave.jar manually. The preferred method is ssh i/o > non-blocking, all nodes connected > in this fashion all came back on their own without intervention. > > Thanks all > > Gavin McDonald (ASF Infra) > > > On Sat, Apr 4, 2020 at 3:20 PM Gavin McDonald wrote: > > > Hi All, > > > > I'll be upgrading the Cloudbees Core Operations Center and all attached > > Masters on Sunday 5th April at around 10am UTC until completed. > > > > I'll turn off new builds around 7am UTC. > > > > I'm 'expecting' a couple of hours downtime assuming all goes well, > > including upgrading all > > associated plugins, performing backups etc. But, this is the first time > > I'm upgrading this setup so there may be the odd gotcha that surprises me > > who knows! - I'm as prepared as possible and I am not expecting any > > problems. > > > > Thanks > > > > Gavin McDonald (ASF Infra) > > > > -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: 4-26-2020 update on Kubernetes Operator
On Mon, Apr 27, 2020 at 2:30 AM Dinesh Joshi wrote: > Hi Patrick, > > Thanks for driving the meetings. It would be good to have the on going > discussions on the dev list for people in time zones that cannot attend the > meetings in real time. > +1 I would never (try to) tell anyone that they cannot teleconference with like-minded peers, but it feels worth mentioning that this format will never be totally inclusive. > > On Apr 26, 2020, at 10:49 PM, Patrick McFadin > wrote: > > > > *Hi everyone,Over the past two weeks, we have had 4 public meetings > with a > > lot of great discussions. You can find the recordings and notes here: > > > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG > > < > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG > >There > > were some important next steps after this week. First is some > housekeeping. > > Having two meetings allowed for better time zone spread, but the > > discussions were disconnected and tended to be somewhat redundant. It was > > suggested to move to a single meeting that can span the most timezones. I > > took that feedback and have rebuilt the SIG meeting schedules in the same > > type of rotation being used for the Contributor Meetings. We’ll see how > > that goes for everyone effected. I’ve also switched away from Zoom to > Jitsi > > (jitsi.org <http://jitsi.org>). Switching to a more open video > conferencing > > software seemed like a natural move and the feature list is comparable to > > Zoom.All the meeting details and schedule are posted here: > > > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG > > < > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG > >This > > includes a calendar file and shared calendar link. Next important thing > is > > the beginning of the CEP for the Kubernetes Operator. Ben Bromhead and I > > took a first pass at a skeleton for CEP-2 > > < > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-2+Kubernetes+Operator > > > > with all the basics. At this point, we need everyone participating in the > > project to take some time and help build out some of the critical > details. > > Because everyone loves Confluence so much, I have created a Google doc we > > can use as a working area before moving over to a more formal Cassandra > > Wiki. > > > https://docs.google.com/document/d/18Ow4R3tB9GIvdcFO7WmUvjb0a-sT6h0zSCEnfHsPz58/edit?usp=sharing > > < > https://docs.google.com/document/d/18Ow4R3tB9GIvdcFO7WmUvjb0a-sT6h0zSCEnfHsPz58/edit?usp=sharing > >Everyone > > has edit rights. Please use the comment functionality if you have > questions > > about a particular section.The main portion that really needs the most > > thoughtful work is Operator Capability Level > > < > https://github.com/operator-framework/operator-sdk/blob/master/doc/operator-capabilities.md > >. > > What does each level mean in Cassandra terms. There was already some good > > debate about configuration and common tasks like repair. Let’s get that > > captured in the doc if we can. If you are one of the groups that already > > have an operator, your experience here is invaluable. Please take some > time > > of you can. Thanks and looking forward to the collaboration. Patrick* > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- Eric Evans (he/him) Senior Software Engineer, Core Platform Wikimedia Foundation eev...@wikimedia.org
Re: Calling for release managers (Committers and PMC)
I can take a turn. On Fri, May 8, 2020 at 11:10 AM Vinay Chella wrote: > > I would like to help as well. > > > On Fri, May 8, 2020 at 8:54 AM Chris Lohfink wrote: > > > I'd like to get involved in this as well. > > > > On Thu, May 7, 2020 at 2:06 PM Jon Meredith wrote: > > > > > Sign me up. > > > > > > On Thu, May 7, 2020 at 12:36 PM Robert Stupp wrote: > > > > > > > > I can help > > > > > > > > -- > > > > Robert Stupp > > > > @snazy > > > > > > > > > Am 07.05.2020 um 20:29 schrieb Mick Semb Wever : > > > > > > > > > > The Cassandra release process has had some improvements to better in > > > > > line with the ASF guidelines: sha256 & sha512 checksums, staged > > > > > artefacts in svnpubsub, dep and rpm repositories complete and signed > > > > > in staging, and separate scripts and manual steps merged together. > > > > > > > > > > The updated documentation for cutting, voting, and publishing a > > > > > release is found here: > > > > > > > > https://cassandra.apache.org/doc/latest/development/release_process.html > > > > > > > > > > I am hoping to get as many Committers* and PMC members interested as > > > > > possible for cutting a future release. > > > > > > > > > > Who is interested? How many names can I get :-) > > > > > > > > > > The more that are interested then the easier it is to take turns and > > > > > be flexible depending on our own availability each time. I will help > > > > > out everyone on their first run. Indeed most of my motivation in > > > > > getting involved with the release process was to make it all as > > simple > > > > > and as forgettable as possible, so the role of the role manager can > > > > > change easily from release to release. > > > > > > > > > > *When a Committer cuts a release, a PMC member has to perform the > > very > > > > > last post-vote publish step. > > > > > > > > > > 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 > > > > > > > > > -- > > Thanks, > Vinay Chella -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Project governance wiki doc (take 2)
+0 On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie wrote: > > Link to doc: > https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance > > Change since previous cancelled vote: > "A simple majority of this electorate becomes the low-watermark for votes > in favour necessary to pass a motion, with new PMC members added to the > calculation." > > This previously read "super majority". We have lowered the low water mark > to "simple majority" to balance strong consensus against risk of stall due > to low participation. > > >- Vote will run through 6/24/20 >- pmc votes considered binding >- simple majority of binding participants passes the vote >- committer and community votes considered advisory > > Lastly, I propose we take the count of pmc votes in this thread as our > initial roll call count for electorate numbers and low watermark > calculation on subsequent votes. > > Thanks again everyone (and specifically Benedict and Jon) for the time and > collaboration on this. > > ~Josh -- Eric Evans john.eric.ev...@gmail.com - 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.7
+1 On Tue, Jul 14, 2020 at 5:47 PM Mick Semb Wever wrote: > > Proposing the test build of Cassandra 3.11.7 for release. > > sha1: 9fe62b3e40147fda2cc081744bd375b04574aef7 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.7-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1209/org/apache/cassandra/cassandra-all/3.11.7/ > > 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.7/ > > 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. > > [1]: CHANGES.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.7-tentative > [2]: NEWS.txt: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.7-tentative -- Eric Evans eev...@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 2.1.7
[ Jake Luciani ] > I propose the following artifacts for release as 2.1.7. > > sha1: 718c144324d170535d4f1a1e79dd9869cce19ed1 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.7-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1061/org/apache/cassandra/apache-cassandra/2.1.7/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-1061/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~jake > > The vote will be open for 72 hours (longer if needed). +1 -- Eric Evans eev...@sym-link.com
Re: [Proposal] Mandatory comments
On Mon, May 2, 2016 at 11:26 AM, Sylvain Lebresne wrote: > Looking forward to other's opinions and feedbacks on this proposal. We might want to leave just a little wiggle room for judgment on the part of the reviewer, for the very simple cases. Documenting something like setFoo(int) with "Sets foo" can get pretty tiresome for everyone, and doesn't add any value. Otherwise I think this is perfectly reasonable; +1 -- Eric Evans john.eric.ev...@gmail.com
Re: [Proposal] Mandatory comments
On Wed, May 4, 2016 at 12:14 PM, Jonathan Ellis wrote: > On Wed, May 4, 2016 at 2:27 AM, Sylvain Lebresne > wrote: > >> On Tue, May 3, 2016 at 6:57 PM, Eric Evans >> wrote: >> >> > On Mon, May 2, 2016 at 11:26 AM, Sylvain Lebresne >> > wrote: >> > > Looking forward to other's opinions and feedbacks on this proposal. >> > >> > We might want to leave just a little wiggle room for judgment on the >> > part of the reviewer, for the very simple cases. Documenting >> > something like setFoo(int) with "Sets foo" can get pretty tiresome for >> > everyone, and doesn't add any value. >> > >> >> I knew someone was going to bring this :). In principle, I don't really >> disagree. In practice though, >> I suspect it's sometimes just easier to adhere to such simple rule somewhat >> strictly. In particular, >> I can guarantee that we don't all agree where the border lies between what >> warrants a javadoc >> and what doesn't. Sure, there is a few cases where you're just paraphrasing >> the method name >> (and while it might often be the case for getters and setters, it's worth >> noting that we don't really >> do much of those in C*), but how hard is it to write a one line comment? >> Surely that's a negligeable >> part of writing a patch and we're not that lazy. >> > > I'm more concerned that this kind of boilerplate commenting obscures rather > than clarifies. When I'm reading code i look for comments to help me > understand key points, points that aren't self-evident. If we institute a > boilerplate "comment everything" rule then I lose that signpost. This. Additionally you could also probably argue that it obscures the true purpose to leaving a comment; It becomes a check box to tick, having some javadoc attached to every method, rather than genuinely looking for the value that could be added with quality comments (or even altering the approach so that the code is more obvious in the absence of them). The reason I suggested "wiggle room", is that I think everyone basically agrees that the default should be to leave good comments (and that that hasn't been the case), that we should start making this a requirement to successful review, and that we can afford to leave some room for judgment on the part of the reviewer. Worse-case is that we find in doing so that there isn't much common ground on what constitutes a quality comment versus useless boilerplate, and that we have to remove any wiggle room and make it 100% mandatory (I don't think that will (has to) be the case, though). -- Eric Evans john.eric.ev...@gmail.com
Re: Documentation
On Tue, Jun 7, 2016 at 10:34 PM, Jonathan Ellis wrote: > In light of the confusion around documentation (people asking on dev list > about driver docs or DataStax docs), I think we should accelerate the plans > to finish migrating our official documentation from the MoinMoin wiki to > our source tree. > > Briefly, the technical problems with Moin aren't going away and having the > docs in tree means we can version them by release for free. > > (We still want to use a wiki for contributor-oriented pages like > HowToContribute, but user-level docs like GettingStarted and Operations > will be moved into tree. And even the contributor wiki needs to move to > Confluence <https://issues.apache.org/jira/browse/INFRA-10942> because > MoinMoin sucks.) > > I've attached an outline of what I think we need to migrate to the ticket > <https://issues.apache.org/jira/browse/CASSANDRA-8700>. I think this is fantastic; I was completely unaware of https://issues.apache.org/jira/browse/CASSANDRA-8700, and had been planning to suggest exactly this. -- Eric Evans john.eric.ev...@gmail.com
Re: Cassandra Java Driver and DataStax
On Sat, Jun 4, 2016 at 2:38 PM, Jonathan Ellis wrote: > FWIW, in very very ancient history we actually had the drivers in tree. It > sucked, because the people who wanted to contribute to the drivers were for > the most part not Committers, and the committers for the most part weren't > interested in reviewing drivers patches, and you have different, > non-overlapping sets of contributors for each driver. (A C++ driver author > generally isn't very interested in clojure and vice versa.) > > Two things really convinced us they didn't belong in tree, even if we > wanted to live with the above drawbacks: > > - If it's in tree, then the Apache committers are viewed as responsible for > maintaining it. Never mind if the Perl driver was (hypothetically) > contributed by some guy who disappeared after a month and none of the > committers know Perl, we have by committing it implicitly promised to fix > bugs and keep it up to date with new features. > - The obvious solution to this problem is to just not commit any driver > that we don't have enough expertise to maintain ourselves or are not > sufficiently confident in the author's commitment. But then you have a > very clear distinction between "first class," in tree drivers (probably > just Java, maybe Python too) and everyone else, which didn't sit right with > us either. FWIW, at the time, I was probably one of the more vocal proponents of this model (out-of-tree driver code), but I'm less certain these days. First off, I think it's probably a false dichotomy to say that if we were to admit one language that we'd be obligated to admit them all, or that we'd be compelled to offer some arbitrary level of support for any or all drivers simply because they are there. We could, for example, release a Java driver and only a Java driver because a) there is room to share some common code with Cassandra, b) because Cassandra is Java and the expertise is there, and c) because having one driver is enough to serve as a reference implementation. Or we could have some subset that met whatever objective criteria we came up with to address concerns about supportability. Or we could be liberal about the drivers we accept, but conservative about the support we provide (i.e. set realistic expectations). One thing is as certain now as it was then, to make such a thing work, we'd need to be far more willing to pull the trigger on new committers than we are now. Personally, I think we could benefit from that, regardless of how you feel about in-tree drivers. -- Eric Evans john.eric.ev...@gmail.com
Re: NewBie Question ~ Book for Cassandra
On Mon, Jun 13, 2016 at 8:05 AM, Mattmann, Chris A (3980) wrote: > However also see that besides the current documentation, there needs to be > a roadmap for making Apache Cassandra and *its* documentation (not > *DataStax’s*) > up to par for a basic user to build, deploy and run Cassandra. I don’t think > that’s > the current case, is it? There is CASSANDRA-8700 (https://issues.apache.org/jira/browse/CASSANDRA-8700), which is a step in this direction I hope. One concern I do have though is that changing the tech used to author/publish documentation won't in itself be enough to get good docs. In fact, moving the docs in-tree raises the barrier to contribution in the sense that instead of mashing 'Edit', you have to put together a patch and have it reviewed. That said, I also think that we've historically set the bar way too high to committer/PMC, and that this may be an opportunity to change that; There ought to be a path to the PMC for documentation authors and translators (and this is typical in other projects). So, I will personally do my best to set aside some time each week to review and merge documentation changes, and to champion regular doc contributors for committership. Hopefully there are others willing to do the same! -- Eric Evans john.eric.ev...@gmail.com
Re: A proposal to move away from Jira-centric development
On Tue, Aug 16, 2016 at 1:34 PM, Benedict Elliott Smith wrote: > This topic is complex, and fully exploring all of the detail would be onerous > over email. Out of curiosity, why; What makes this topic so difficult to discuss over email? > DataStax, in my opinion, consciously tries to be a good citizen. However > there > are emergent properties of a system with this imbalance that are not > conscious, > and are suboptimal, and it is not unreasonable for the Apache apparatus to > try to "rectify" the imbalance. I personally support that *in principle*, > but I think > they're not going about it brilliantly right now. I also doubt the success > of any > such endeavour, given how difficult the problem is. This. A good first step in my opinion would be for us all to simply recognize this. An imbalance of this nature is not good for the project, full stop. No malice needs to be attributed, no effigies burned, and it shouldn't be viewed as squaring up against those we know and respect who are employed by Datastax. -- Eric Evans john.eric.ev...@gmail.com
Re: A proposal to move away from Jira-centric development
On Tue, Aug 16, 2016 at 2:38 PM, Benedict Elliott Smith wrote: > I think all complex, nuanced and especially emotive topics are challenging > to discuss over textual media, due to things like the attention span of > your readers, the difficulties in structuring your text, and especially the > hoops that have to be jumped through to minimise the potential for > misinterpretation, as well as correcting the inevitable misinterpretations > that happen anyway. Fair enough, I suppose, but some of these things are also difficult face to face. Most people who collaborate over the Internet with people from different backgrounds in different timezones, etc, learn to adjust accordingly. And, the asynchronicity of email is often a feature in this regard, giving people the opportunity to more carefully consider what they've read, and to be more deliberate in their response. I guess what I should have asked is, if not email, then how? -- Eric Evans john.eric.ev...@gmail.com
Re: A proposal to move away from Jira-centric development
On Tue, Aug 16, 2016 at 3:09 PM, Benedict Elliott Smith wrote: > This is a great example of email's inadequacies, as this innocuous (to me) > little textual > act resulted instead in *different* quagmire, while the first potential > quagmire is still in > play! > > Email is a minefield, and textual interactions can be exhausting. So > people tap out without fully expressing themselves, to retain their life > and sanity. My apologies, it wasn't my intention to drag you into a quagmire. You had indicated a reluctance to discuss a particular topic, and attributed it to email. Personally, I think that this is a) a conversation worth having, and b) one that others have been reluctant to engage in. My intention was to understand the reluctance, and if possible, encourage you (and others) to try. Cheers, -- Eric Evans john.eric.ev...@gmail.com
Re: A proposal to move away from Jira-centric development
On Mon, Aug 15, 2016 at 9:22 AM, Jonathan Ellis wrote: [ ... ] > I propose that we take advantage of the dev list to perform that > separation. Major new features and architectural improvements should be > discussed first here, then when consensus on design is achieved, moved to > Jira for implementation and review. > > I think this will also help with the problem when the initial idea proves > to be unworkable and gets revised substantially later after much > discussion. It can be difficult to figure out what the conclusion was, as > review comments start to pile up afterwards. Having that discussion on the > list, and summarizing on Jira, would mitigate this. TL;DR +1 I think there are actually a couple of related, but disjoint issues here. IMO, a JIRA should be the source of truth for an issue, a way to track any on-going efforts, and a historical account after-the-fact. Regardless of where you think discussions should take place, I would argue there is room for improvement here; Many of our JIRAs (I would argue the most interesting ones!), are very difficult to make use of for either of these cases (current status, or after-the-fact). Some curation (as someone else pointed out in this thread), could go a long way. Retitling and/or revising the description as the scope of a ticket evolves, or posting a summary or current status in the description body would be ways for people who are up to speed on an issue, to spend a few minutes making it valuable to others. So would summarizing discussions that take place elsewhere. The other issue is discoverability and/or inclusivity. If the only way to keep abreast of what is happening is to follow the fire-hose of all JIRA updates, then contribution is going to be limited to those with the bandwidth. If you work on Cassandra full-time, this probably doesn't seem like a big deal, but if your time is limited, then it can create quite a barrier (and I've been on both sides of this with Cassandra). So moving serious discussions to the mailing list is also a sort of curation, since it creates a venue free of all the minutiae/noise. My personal opinion is also that it's far easier to manage a given volume with email, and that the discussions are easier to follow (the interface is better at representing the ontology, for example), but from what I can gather, not everyone agrees so YMMV. Cheers, -- Eric Evans john.eric.ev...@gmail.com
Re: CASSANDRA-10993 Approaches
On Wed, Aug 17, 2016 at 2:08 PM, Tyler Hobbs wrote: > In the spirit of the recent thread about discussing large changes on the > Dev ML, I'd like to talk about CASSANDRA-10993, the first step in the > "thread per core" work. I'm just lurking ATM; I don't have anything to add WRT CASSANDRA-10993, but wanted to say that this is awesome. Thanks for this Tyler! -- Eric Evans john.eric.ev...@gmail.com
[ANN]: Cert management with self-signed CA for Cassandra (and presumably other Java stuff)
Hi, The topic of configuring encryption comes up fairly often, so I thought I'd make available to others what we use at the Wikimedia Foundation. https://github.com/eevans/cassandra-ca-manager It allows you to define a self-signed root CA, along with keys and certs for each of your machines in a YAML manifest file. The script reads the manifest and generates everything you need (including Java keystore and truststore files), and drops them in a directory of your choosing. It's nothing fancy, but it works pretty well, and beats looking up all of the baroque commands once a year to do it manually. Cheers, -- Eric Evans john.eric.ev...@gmail.com
Re: [ANN]: Cert management with self-signed CA for Cassandra (and presumably other Java stuff)
On Mon, Aug 22, 2016 at 5:28 PM, Jake Farrell wrote: > Any reason to not include this in the docs/operating or as a utility in repo > to make it easier for end users to find all information in one place? Know > this has come up on other projects and we always fall into the same > search/reply trap as well No, if there were consensus that was worthwhile, I would have no objections. -- Eric Evans eev...@wikimedia.org
Re: Gossip 2.0
On Thu, Sep 1, 2016 at 7:02 AM, Jason Brown wrote: > have opened up CASSANDRA-12345... Nice; What did you do, camp on the "create" button until after 12344 was submitted? :) -- Eric Evans john.eric.ev...@gmail.com
Re: Proposal - 3.5.1
On Thu, Sep 15, 2016 at 9:33 PM, Mick Semb Wever wrote: > - keep bimonthly feature releases, > - revert from tick-tock to SemVer numbering scheme, > - during the release vote also vote on the quality label (feature branches > start with a 'Alpha' and the first patch release as 'Beta'), > - accept that every feature release isn't by default initially supported, > and its branch might never be, > - maintain 3 'GA' branches at any one time, > - accept that it's not going to be the oldest GA branches that necessarily > reach EOL first. I like it. -- Eric Evans john.eric.ev...@gmail.com
Re: Proposal - 3.5.1
On Fri, Sep 16, 2016 at 5:05 AM, Sylvain Lebresne wrote: > In light of all this, my suggesting for a release cycle woud be: > - To have 3 branches: 'features', 'testing' and 'stable', with an X month > rotation: 'features' becomes 'testing' after X months and then 'stable' > after > X more, before getting EOL X months later. > - The feature branch gets everything. The testing branch only gets bug > fixes. > The stable branch only gets critical bug fixes. And imo, we should be very > strict on this (I acknowledge that there is sometimes a bit of > subjectivity on > whether something is a bug or an improvement, and if it's critical or > not, but > I think it's not that hard to get consensus if we're all reasonable > (though it > might worth agreeing on some rough but written guideline upfront)). > - We release on a short and fixed cadence of Y month(s) for both the > feature and > testing branch. For the stable branch, given that it already had X months > of > only bug fixes during the testing phase, one can hope critical fixes will > be > fairly rare, less than 1 per Y period on average). Further, it's supposed > to > be stable and fixes are supposed to be critical, so doing hot-fix releases > probably makes the most sense (though it probably only work if we're > indeed > strict on what is considered critical). This seems pretty close to what Mck suggested; I think this could work. -- Eric Evans john.eric.ev...@gmail.com
Re: [VOTE] Accept dtests Donation Into Project
On Fri, Sep 30, 2016 at 1:51 PM, Nate McCall wrote: > I propose we begin the process of accepting the contribution of the > dtest codebase (https://github.com/riptano/cassandra-dtest) into the > project. > > Background discussion thread here: > https://lists.apache.org/thread.html/840fd900fb7f6568bfa008d122d4375b708c1f7f1b5929018118d5d5@%3Cdev.cassandra.apache.org%3E > > Note: It won't be immediate as there are some steps to follow [0] for > accepting outside code contributions. > > The vote will be open for 72 hours. +1 -- Eric Evans john.eric.ev...@gmail.com
Re: Moderation
On Fri, Nov 4, 2016 at 11:44 AM, Chris Mattmann wrote: > So seriously, we're going to send now 4 emails talking about what a user of > Apache Cassandra and possible community member could have done right or > better or sooner, or that there is no time limit to moderating shit when it > could have been as simple as literally sending a confirmation email to > moderate it through? This is the definition of process over community. And > it's the definition (wrongly so) of why people think it's "Apache" that > induces the processes that make shit hard, and not the community itself. > Seriously this is a joke. So what if she didn't do it right the first time. > You think potentially moderating her mail through and then sending a kind > email suggesting she look at the instructions for how to subscribe, which oh > someone may not have found easy to do or simply not understood that simply > sending an email to the list wouldn't have made it go through the first time? > Is it that hard to figure out? Really? > > This is the definition of making things hard and not making them easy or > friendly. And this is also exactly what enables people to sound off on > Twitter about a project, and loses the conversation that could have been had > on Apache mailing lists. Kelly has been tweeting for days. I saw her tweets > retweeted by someone in my feed, and yesterday asked her kindly to bring her > conversation to the list. 12 hours later it's still in moderation, and we are > arguing whether to f'ing moderate it through. Wow. Great job. Wait, what? As a moderator of this list (unpaid, volunteer), did I miss the SLA I was being held to? Are you volunteering to moderate this list? -- Eric Evans john.eric.ev...@gmail.com
Re: Moderation
On Fri, Nov 4, 2016 at 11:51 AM, Gary Dusbabek wrote: > I'm beginning to wonder if I'm the only one with moderator privs. Any other > committer/PMCs interested? You are not. > Sorry, it's a chore to begin with and I've been traveling this week. No need to be sorry. -- Eric Evans john.eric.ev...@gmail.com
Re: Moderation
On Fri, Nov 4, 2016 at 11:57 AM, Chris Mattmann wrote: > Yet you act like it's volunteer time that's preventing moderating a message > through in 12 hours. Here it is again, 12 hours. If we have a 12 hour SLA on moderation, then you can remove me as a moderator; I can't do that. -- Eric Evans john.eric.ev...@gmail.com
Re: Review of Cassandra actions
On Sun, Nov 6, 2016 at 3:42 PM, Mark Thomas wrote: > A number of posts from a variety of authors on this topic in recent days > have fallen short of the standard expected on an Apache list. Trying to > correct that without causing the situation to escalate is hard. The last > thing I want to do is add fuel to the fire. I've started to draft a > couple of emails at various points over the weekend only to find by the > time I'm happy(ish) with the draft, the thread has moved on and I need > to start again. > > Alongside this I had hoped that things would have slowed down enough > over the weekend to give everyone time to reflect, recognise where they > might need to apologise and aim to start this coming week on a more > positive footing. There have been signs of this which I take to be > encouraging. Moving forward I'd encourage everyone to pause and review > what they have just written with the Code of Conduct in mind before > pressing send. Thank you for this Mark. And while we're at it, thank you for all of your input these past weeks. It's been incredibly helpful and constructive. -- Eric Evans john.eric.ev...@gmail.com
Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)
On Sun, Nov 13, 2016 at 1:13 AM, Ben Slater wrote: > For anyone that’s interested, I’ve submitted my doc changes for point 2 > below (emphasising contributions other than new features) here: > https://issues.apache.org/jira/browse/CASSANDRA-12906 > > I haven’t added anything about the sponsor/shepherd idea as doesn’t seem to > be agreed at this point. > > Cheers > Ben > > On Mon, 7 Nov 2016 at 09:34 Nate McCall wrote: > >> Ben, >> Thank you for providing two thoughtful, concrete recommendations. >> There is some good feedback in general on this thread, but I'm calling >> Ben's response out because point #1 is important to discuss and point >> #2 is immediately actionable. >> >> > 1) I think some process of assigning a committer of a “sponsor” of a >> change >> > (which would probably mean committers volunteering) before it commences >> > would be useful. You can kind of do this at the moment by creating a JIRA >> > and asking for comment but I think the process is a bit unclear and a bit >> > intimidating for people starting off and it would be nice to know who was >> > your primary reviewer for a piece of work. (Or maybe this process does >> > exist and I don’t know about.) >> >> This is a good idea, but it assumes a single point triage and resource >> management that we don't really have right now. >> >> For the history of the project, we had triage in the form of sponsored >> resources flighting most of the new issues. This has made the rest of >> us complacent. It's probably the most immediate thing to fix and I >> don't know how to do that. >> >> Does anybody have any recommendations about ASF projects doing this >> effectively? Note that the folks from DS engineering are still heavily >> involved and I very much thank them for that, but diversifying is the >> only way to get us over our complacency. >> >> > 2) I think the “how to contribute” docs could emphasise activities other >> > than creating new features as a great place to start.It seems that >> review, >> > testing and doco could all do with more hands (as on just about any >> > project). So, encouraging this as a way to start on the project might >> help >> > to get some more bandwidth in this area rather than people creating >> patches >> > that the committers don’t have bandwidth to review. I would be happy to >> > draft an update to the docs including some of this if people think it’s a >> > good idea. >> >> Also a good idea and much more accessible/easily fixable. >> >> We will gladly look at any doc updates for this, looping in the >> broader community once published (this last part being key - I'm >> afraid if we ask for help too early, we'll get tons of interest to >> which we cannot reply and then be in even worse shape). >> >> -Nate >> -- Eric Evans john.eric.ev...@gmail.com
Re: Board report and feedback from such.
On Wed, Nov 16, 2016 at 10:30 PM, Ben Bromhead wrote: > Thanks Nate, this is great to see this get some visibility on a wider > distribution list like dev! Full ACK; Thanks for sending this to the list Nate! -- Eric Evans john.eric.ev...@gmail.com
Re: STCS in L0 behaviour
On Sat, Nov 26, 2016 at 6:30 PM, Dikang Gu wrote: > Hi Marcus, > > Do you have some stack trace to show that which function in the ` > getNextBackgroundTask` is most expensive? > > Yeah, I think having 15-20K sstables in L0 is very bad, in our heavy-write > cluster, I try my best to reduce the impact of repair, and keep number of > sstables in L0 < 100. > > Thanks > Dikang. > > On Thu, Nov 24, 2016 at 12:53 PM, Nate McCall wrote: > >> > The reason is described here: >> https://issues.apache.org/jira/browse/CASSANDRA-5371? >> focusedCommentId=13621679&page=com.atlassian.jira. >> plugin.system.issuetabpanels:comment-tabpanel#comment-13621679 >> > >> > /Marcus >> >> "...a lot of the work you've done you will redo when you compact your now >> bigger L0 sstable against L1." >> >> ^ Sylvain's hypothesis (next comment down) is actually something we see >> occasionally in practice: having to re-write the contents of L1 too often >> when large L0 SSTables are pulled in. Here is an example we took on a >> system with pending compaction spikes that was seeing this specific issue >> with four LCS-based tables: >> >> https://gist.github.com/zznate/d22812551fa7a527d4c0d931f107c950 >> >> The significant part of this particular workload is a burst of heavy writes >> from long-duration scheduled jobs. >> > > > > -- > Dikang -- Eric Evans john.eric.ev...@gmail.com
Re: splitting CQL parser & spec into separate repo
On Wed, Mar 22, 2017 at 10:01 AM, Edward Capriolo wrote: > I believe you could accomplish a similar goal by making a multi-module > project https://maven.apache.org/guides/mini/guide-multiple-modules.html. > Probably not as easy thanks to ant, but I think that is a better route. One > there actually are N dependent projects in the wild you can make the case > for overhead which is both technical and in ASF based. This was my first thought: If we were using Maven, we'd probably already have created this as a module[*]. [*]: Maybe a surprise to some given how strongly I pushed back against it in the Early Days, but we would be so much better off at this point with Maven. -- Eric Evans john.eric.ev...@gmail.com
Re: Spam Moderation
On Thu, Mar 23, 2017 at 11:10 AM, Michael Shuler wrote: > I won't reply to the obvious spam to hilight it any further, so new > message.. > > Could the mailing list moderator that approved the "client list" message > identify themselves and possibly explain how that was seen as a valid > message about the development of Apache Cassandra? TL;DR That would be me. My policy in moderating this list has always been to ignore the obvious spam, and default to letting everything else through. IMO, to apply judgment beyond that is a very slippery slope. Transparency and openness are more important to me than protecting everyone from the occasional false-positive spam and/or possibly off-topic message. I also bang through the messages in the queue pretty quickly and make the Obvious Spam -or- not judgement almost reflexively. In this case, I guess the lack of HTML, images, or attachments, along with the presence of words like "Datastax", and "client" triggered a snap Not Spam reaction and I sent it through. But at least some of the reaction here seems to extend beyond a simple matter of a spam message on the list (that has happened before); Some here seem to be reacting out of concern to the very existence of the email, which makes me think it's precisely the sort of thing that shouldn't be kept hidden. -- Eric Evans john.eric.ev...@gmail.com
Re: Weekly Cassandra Wrapup
On Fri, Apr 7, 2017 at 10:35 PM, Jeff Jirsa wrote: > First, check out this graph: > > http://i.imgur.com/cEx3jOo.png Oh snap; That's awesome! -- Eric Evans john.eric.ev...@gmail.com
Re: Cassandra on RocksDB experiment result
On Thu, Apr 20, 2017 at 6:25 PM, Jeff Jirsa wrote: > Setting aside details of the implementation, does anyone feel that > pluggable storage in itself is inherently a bad idea (so much so that you'd > -1 it if someone else did the work)? I don't think it's inherently a bad idea, no. I'm a little skeptical about the tractability, while being genuinely hopeful that someone will prove me wrong. :) > If we can establish loose consensus on it being something generally > acceptable (assuming someone can come up with an interface/abstraction upon > which everyone can agree), then it seems like the next step is working on > defining the proper interface. +1 -- Eric Evans john.eric.ev...@gmail.com
Re: Cassandra on RocksDB experiment result
On Fri, Apr 21, 2017 at 4:32 AM, benjamin roth wrote:
> I am not a PMC member or sth but just my 2 cents:
Somewhat off-topic here, but I'd like to start discouraging people
from prefacing remarks like this ("not a PMC member", "non-binding
+1"). The exchange rate here is 1:1 IMO, your 2 cents are worth the
same as any others! ;)
--
Eric Evans
john.eric.ev...@gmail.com
Re: Way to unsubscribe from mailing lists
On Tue, Apr 25, 2017 at 2:56 AM, Alain RODRIGUEZ wrote:
> Should / could we have INFRA automatically unsubscribing people sending
> those messages? I believe this would be the best solution, as more people
> mentioned a year ago. I would like at least those messages to be filtered,
> even that is a bit more selfish as it would not end the subscription for
> the person sending the message, it would at least reduce the noise.
I'd be in favor of filtering them from the list, with an
auto-responder that explained *why* it wasn't delivered, and what they
need to do to unsubscribe (and maybe setting the reply-to to
{list}-unsubscribe@cassandra.a.o).
I'm fairly certain the list software doesn't come ready to do this
though; I imagine the response from INFRA will be something like
"patches welcome", so we should be ready to rollup our sleeves.
--
Eric Evans
john.eric.ev...@gmail.com
Re: Way to unsubscribe from mailing lists
On Wed, Apr 26, 2017 at 9:36 AM, Jake Farrell wrote: > moderators can also subscribe/unsubscribe people by sending an email using > the following pattern > > example to unsubscribe u...@example.com: > dev-unsubscribe-user=example@cassandra.apache.org Doing so seem prone to abuse though. -- Eric Evans john.eric.ev...@gmail.com
Re: Way to unsubscribe from mailing lists
On Wed, Apr 26, 2017 at 11:16 AM, Jake Luciani wrote: > Another option would be to add a unsubscribe header, not sure if we already > do but I think that causes gmail/outlook to add a unsubscribe button > > http://www.list-unsubscribe.com/ Brilliant. Sad that it would come to this, but brilliant. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
NGCC?
Hi, Is anyone working on an NGCC event for this year? Given all of the recent changes, it seems like it could be really useful. If not, is there interest? When would be good, September? October? What about location? I think we could get the space to host such an even in either San Antonio (centrally located), or San Francisco (San Franciscoly located). Thoughts? -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: NGCC?
On Wed, May 31, 2017 at 2:19 PM, Eric Evans wrote: > Hi, > > Is anyone working on an NGCC event for this year? Given all of the > recent changes, it seems like it could be really useful. If not, is > there interest? When would be good, September? October? What about > location? I think we could get the space to host such an even in > either San Antonio (centrally located), or San Francisco (San > Franciscoly located). > > Thoughts? And to be clear: NGCC == Next Generation Cassandra Conference And conference may or may not be a misnomer here. I think what we're talking about is more of a meeting of Cassandra developers (read: developers *of* Cassandra), to discuss their respective needs / plans, and to talk about how that might fit into a project road map. IMO, a successful event would result in ideas and help inform consensus about where the project is going, what is important, and who is willing to collaborate on what. I do not see this as a place where actual decisions would be made, that wouldn't be inclusive of all the people unable to attend. HTH, -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: NGCC?
On Thu, Jun 1, 2017 at 11:02 AM, Russell Bradberry wrote: >> read: developers *of* Cassandra > > Historically it has not only been developers of Cassandra but also specific > power users, influencers, and experts. If you want to be successful in > deciding the direction of a product, you need more than its developers > present. For instance, I am not a Cassandra developer, but I have been > invited every year. Same with folks like Peter Bailis, Rick Branson, and > others who come in with a wealth of knowledge around varying use cases. > Unfortunately, I missed that last two years, but was hoping to make it this > year. You are right, of course. I was (clumsily) trying to create a distinction between this and a regular user conference. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: NGCC?
On Fri, Jun 2, 2017 at 2:34 PM, Ben Bromhead wrote: > We are more than happy to donate some resources (both people and materials) > to putting on NGCC. > > I would suggest some sort of committee of folks who are willing to do the > groundwork and who act as the executive so it gets done :) Gary Dusbabek and myself are both willing to shoulder the grunt work of organizing this. Since we're both in San Antonio, that's the location that would be most practical for us. It's also easy to get to, centrally located, and the weather should be fantastic that time of year. We were thinking we'd put together some options for venue, and propose some dates, and circle back to the list in search of consensus. If this seems reasonable for now, then we'll get back to everyone with more info in a weeks time. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: NGCC Proposal (Was Re: NGCC?)
On Mon, Jun 12, 2017 at 3:30 PM, Gary Dusbabek wrote: > Date: One of 18, 19, or 22 September 2017. Strawpoll: Which of these dates looks most attractive to folks (Monday, Tuesday, or Friday)? -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Three scripts needed to run the server, Why?
On Wed, Jul 12, 2017 at 5:49 AM, Tomas Repik wrote: > Thanks guys for joining the discussion, I hope you don't mind if I continue > to argue a bit more. > > The core intelligence and functionality of Cassandra server lays in the Java > classes, which reside in jar archives. This is the place where the main > functionality updates take place. To ease the use of the classes there is, > let's call it "wrapper" script (bin/cassandra), which sets up the environment > for the classes to provide the functionality. This wrapper uses two other > scripts: one of which sits in bin (the include) and the other in etc (the env > file). I agree that the files in bin should not be edited by the users, but > the following quotes from the wrapper script state the opposite: > "Any serious use-case though will likely require customization of the > include." > "Developers and enthusiasts can put a customized include file at > ~/.cassandra.in.sh." > According to these the include file is no different from the environment > file. But why would you have two separate files meant for the same purpose? cassandra-env.sh is meant to be user configuration, whereas cassandra.in.sh is system configuration. cassandra.in.sh can be used to customize the behavior of the startup script for the system you are deploying to; It is used to integrate. Packages can make customizations here, or you could template it for use with Puppet, Chef, etc. Once deployed, you would not edit this file again. cassandra-env.sh is configuration for Cassandra that lives above what is reasonable to configure in the application. Heap size is a good example of the sort handled here, something to be passed as an argument to the JVM, not something you could use cassandra.yaml for. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: CHANGES.txt
On Tue, Jul 18, 2017 at 8:10 AM, Stefan Podkowinski wrote: > Has there been any consensus in the past about what goes into > CHANGES.txt and what not? My naive assumption was that the intended > audience for the file are users who want to know about changes between > new releases. Having that in mind, I skipped changes.txt once in a while > for updates that have no relevance except for developers. For releases, > such as 4.0, the list is already substantial and hard to digest. I'm > also wondering how informative entries such as e.g. "Remove unused > method" are for the general user. So my question is, should we add all > resolved tickets to changes.txt, or should we try to keep the list less > verbose in the future? One problem with trying to be selective, is that it invites judgment as to what is or is not worthy for inclusion, and that's bound to be a slippery slope. I also think it's not uncommon for what appears to be a trivial change for one person, to be very important to someone else. I wonder if the length of the list for 4.0 doesn't have as much to do with the delays in getting it released. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Occasional Cassandra Status Wrapup
On Sat, Sep 30, 2017 at 12:29 AM, Jeff Jirsa wrote: > It's been a long time since I've remembered to write what used to be the > weekly cassandra wrapup, but I wanted to try to summarize some of the > recent events (especially NGCC) for those that couldn't attend / didn't > know it was happening / don't have time to follow every conversation in the > community. [ ... ] I've missed these; Thanks Jeff! -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: High IOWaits after upgrade to 3.11.1
On Tue, Nov 7, 2017 at 4:38 AM, Jaroslav Kameník wrote: > Hi all, > > we are running one small testing cluster on virtualized HW, > it had little higher IOWaits in past, but after upgrade to > C* 3.11.1 IOWaits grew up +- three times. Are there any > changes causing more agressive disc usage? What version are you upgrading from? How many page faults are you seeing? If the number is high, you might try adding "disk_access_mode: mmap_index_only" to cassandra.yaml (there is no default entry in the file). -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Cassandra 2017 Wrapup
> > > some time talking about testing and CI. > > > > > > Some other big'ish development efforts worth mentioning (from personal > > > memory, perhaps the worst possible way to create such a list): > > > - We spent a fair amount of time talking about testing. Francois @ > > > Instagram lead the way in codifying a new set of principles around > > testing > > > and quality ( > > > https://lists.apache.org/thread.html/0854341ae3ab41ceed2ae8a03f2486 > > > cf2325e4fca6fd800bf4297dd4@%3Cdev.cassandra.apache.org%3E > > > / https://issues.apache.org/jira/browse/CASSANDRA-13497 ). > > > - We've also spent some time making tests work in CircleCI, which > should > > > make life much easier for occasional contributors - no need to figure > out > > > how to run tests in ASF Jenkins. > > > - The internode messaging rewrite to use async/netty is probably the > > single > > > largest that comes to mind. It went in earlier this year, and should > make > > > it easier to have HUGE clusters. All of you running thousand instance > > > clusters will probably benefit from this patch (I know you're out > there, > > > I've talked to you in IRC) - will be in 4.0 ( > > > https://issues.apache.org/jira/browse/CASSANDRA-8457 ) > > > - We have a company working on making Cassandra happy with proprietary > > > flash storage and PPC64LE (IBM's recent patches, > > > https://developer.ibm.com/linuxonpower/2017/03/31/using- > > > capi-improve-performance-apache-cassandra-work-progress-update/ > > > ) > > > - We have a new commitlog mode added for the first time in quite some > > time > > > - the GroupCommitLog will be in 4.0 ( > > > https://issues.apache.org/jira/browse/CASSANDRA-13530 ) > > > - Michael Kjellman spent some time porting dtests from nose to pytest, > > and > > > from python 2.7 to python 3, removing dependencies on dead projects > like > > > pycassa and the old thrift-cql library. Still needs to be reviewed ( > > > https://issues.apache.org/jira/browse/CASSANDRA-14134 ) > > > - Robert Stupp spent some time porting to java9 - again, still need to > be > > > reviewed ( https://issues.apache.org/jira/browse/CASSANDRA-9608 ) > > > > > > Overall, the state of the project appears to be strong. We're seeing > > active > > > contributions driven primarily by users (like you), the 8099/3.0 engine > > is > > > looking pretty good here in December, and the code base is stabilizing > > > towards a product all of us should be happy to run in production. > Despite > > > some irrationally skeptical sky-is-falling threads near the end of > 2016, > > I > > > feel confident in saying it was a pretty good year for Cassandra, and > as > > > the project continues to move forward, I'm looking forward to seeing > 4.0 > > > launch in 2018 (hopefully with a real user conference!) > > > > > > - Jeff > > > > > > -- Eric Evans john.eric.ev...@gmail.com
Re: A JIRA proposing a seperate repository for the online documentation
On Thu, Mar 15, 2018 at 4:58 AM, Rahul Singh wrote: > > I don’t understand why it’s so complicated. In tree docs are as good as any. > All the old docs are there in the version control system. > > All we need to is a) generate docs for old versions b) improve user > experience on the site by having it clearly laid out what is latest vs. old > docs. and c) have some semblance of a search maybe using something like > Algolia or whatever. This. Keeping the docs in-tree is a huge win, because they can move in lock-step with changes occurring in that branch/version. I don't think we've been enforcing this, but code-changes that alter documented behavior should be accompanied by corresponding changes to the documentation, or be rejected. Code-changes that correspond with undocumented behavior are an opportunity to include some docs (not grounds to reject a code-review IMO, but certainly an opportunity to politely ask/suggest). Publishing more than one version (as generated from the respective branches/tags), is a solvable problem. > > On Thu, Mar 15, 2018 at 1:22 Kenneth Brotman > wrote: > > > > > https://issues.apache.org/jira/browse/CASSANDRA-14313 > > > > > > > > > > > > For some reason I'm told by many committers that we should not have sets > > > of > > > documentation for other versions than the current version in a tree for > > > that > > > version. This has made it difficult, maybe impossible to have > > > documentation > > > for all the supported versions on the website at one time. > > > > > > > > > > > > As a solution I propose that we maintain the online documentation in a > > > separate repository that is managed as the current repository under the > > > guidance of the Apache Cassandra PMC (Project Management Committee); and > > > that in the new repository . . . > > > > > > > > > > > > Please see the jira. I hope it's a good answer to everyone. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: A JIRA proposing a seperate repository for the online documentation
On Thu, Mar 15, 2018 at 11:40 AM, Kenneth Brotman wrote: > Well pickle my cucumbers Jon! It's good to know that you have experience > with Hugo, see it as a good fit and that all has been well. I look forward > to the jira epic! > > How exactly does the group make such a decision: Call for final discussion? > Call for vote? Wait for the PMC to vote? Good question! Decisions like this are made by consensus; As the person who is attempting to do something, you discuss your ideas with the group, listen to the feedback of others, and develop consensus around a direction. This is more difficult than demanding your way, or having someone(s) in a position of absolute power tell you what you can and cannot do, but the result is better. > -Original Message- > From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad > Sent: Thursday, March 15, 2018 9:24 AM > To: dev@cassandra.apache.org > Subject: Re: A JIRA proposing a seperate repository for the online > documentation > > Murukesh is correct on a very useable, pretty standard process of > multi-versioned docs. > > I’ll put my thoughts in a JIRA epic tonight. I’ll be a multi-phase process. > Also correct in that I’d like us to move to Hugo for the site, I’d like us to > have a unified system between the site & the docs, and hugo has been > excellent. We run the reaper site & docs off hugo, it works well. We just > don’t do multi-versions (because we don’t support multiple): > https://github.com/thelastpickle/cassandra-reaper/tree/master/src/docs > <https://github.com/thelastpickle/cassandra-reaper/tree/master/src/docs>. > > Jon > >> On Mar 15, 2018, at 8:57 AM, Murukesh Mohanan >> wrote: >> >> On Fri, Mar 16, 2018 at 0:19 Kenneth Brotman >> mailto:kenbrot...@yahoo.com.invalid>> >> wrote: >> >>> Help me out here. I could have had a website with support for more >>> than one version done several different ways by now. >>> >>> A website with several versions of documentation is going to have >>> sub-directories for each version of documentation obviously. I've >>> offered to create those sub-directories under the "doc" folder of the >>> current repository; and I've offered to move the online documentation >>> to a separate repository and have the sub-directories there. Both >>> were shot down. Is there a third way? If so please just spill the beans. >>> >> >> There is. Note that the website is an independent repository. So to >> host docs for multiple versions, only the website's repository (or >> rather, the final built contents) needs multiple directories. You can >> just checkout each branch or tag, generate the docs, make a directory >> for that branch or tag in the website repo, and copy the generated >> docs there with appropriate modifications. >> >> I do this on a smaller scale using GitHub Pages (repo: >> https://github.com/murukeshm/cassandra >> <https://github.com/murukeshm/cassandra> site: >> https://murukeshm.github.io/cassandra/ >> <https://murukeshm.github.io/cassandra/> >> <https://murukeshm.github.io/cassandra/3.11.1/ >> <https://murukeshm.github.io/cassandra/3.11.1/>> ). The method is a >> bit hacky as I noted in CASSANDRA-13907. A daily cronjobs updated the repo >> if docs are updated. 3.9+ versions are available. >> >> >> >> >>> Also, no offense to anyone at Sphinx but for a project our size it's >>> not suitable. We need to move off it now. It's a problem. >>> >>> Can we go past this and on to the documenting! Please help resolve this. >>> >>> How are we going to: >>> Make the submission of code changes include required changes to >>> documentation including the online documentation? >>> Allow, encourage the online documentation to publish multiple >>> versions of documentation concurrently including all officially supported >>> versions? >> >> >> Only on this point: we'll need to start by improving the website build >> process. Michael's comment on 13907 ( >> https://issues.apache.org/jira/browse/CASSANDRA-13907?focusedCommentId >> =16211365&page=com.atlassian.jira.plugin.system.issuetabpanels:comment >> -tabpanel#comment-16211365 >> <https://issues.apache.org/jira/browse/CASSANDRA-13907?focusedCommentI >> d=16211365&page=com.atlassian.jira.plugin.system.issuetabpanels:commen >> t-tabpanel#comment-16211365> >> ) >> shows it's a painful, fiddly process. That seems to
Re: Paying off tech debt and correctly naming things
On Wed, Mar 21, 2018 at 3:48 AM, Sylvain Lebresne wrote: [ ... ] > - pure code renaming is one reasonably simple aspect, but quite a few > renaming may have user visible impact. Particularly around JMX where many > things are name based on their class, and to a lesser extend some of our > tools still use "old" naming. We can't and shouldn't ignore those impact: > such user visible changes should imo be documented, and we should make sure > we have a reasonably painless (and thus incremental) upgrade path. My hunch > is the latter isn't as simple as it seems. Speaking as someone who has personally been burned by this (repeatedly, and it's on-going), please think very carefully before making such changes. I hate to think about of all the hours I wasted shaving this breed of yak. > On Wed, Mar 21, 2018 at 9:06 AM kurt greaves wrote: [ ... ] -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
; >>>>>>>>> > >>>>>>>>> We have a jira [5] where Robert Stupp did most of the work to get > >>>> us > >>>>> onto > >>>>>>>>> Java 9 (thanks, Robert), but then the announcement of the JDK > >>>> version > >>>>>>>>> changes happened last fall after Robert had done much of the work > >>>> on > >>>>> the > >>>>>>>>> ticket. > >>>>>>>>> > >>>>>>>>> Here's an initial proposal of how to move forward. I don't > suspect > >>>>> it's > >>>>>>>>> complete, but a decent place to start a conversation. > >>>>>>>>> > >>>>>>>>> 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK > >>>> will > >>>>>>>>> release every six months, and the OracleJDK will release every > >>>> three > >>>>>>>> years. > >>>>>>>>> Thus, the OracleJDK is the LTS version, and it just comes from a > >>>>> snapshot > >>>>>>>>> of one of those OpenJDK builds. > >>>>>>>>> > >>>>>>>>> 2) always release cassandra on a LTS version. I don't think we > can > >>>>>>>>> reasonably expect operators to update the JDK every six months, > on > >>>>> time. > >>>>>>>>> Further, if there are breaking changes to the JDK, we don't want > >>>> to > >>>>> have > >>>>>>>> to > >>>>>>>>> update established c* versions due to those changes, every six > >>>>> months. > >>>>>>>>> > >>>>>>>>> 3) keep trunk on the lasest jdk version, assumming we release a > >>>> major > >>>>>>>>> cassandra version close enough to a LTS release. Currently that > >>>> seems > >>>>>>>>> reasonable for cassandra 4.0 to be released with java 11 (18.9 > >>>> LTS) > >>>>>>>>> support. Perhaps we can evaluate this over time. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Once we agree on a path forward, *it is impreative that we > publish > >>>>> the > >>>>>>>>> decision to the docs* so we can point contributors and operators > >>>>> there, > >>>>>>>>> instead of rehashing the same conversation. > >>>>>>>>> > >>>>>>>>> I look forward to a lively discussion. Thanks! > >>>>>>>>> > >>>>>>>>> -Jason > >>>>>>>>> > >>>>>>>>> [1] http://www.oracle.com/technetwork/java/eol-135779.html > >>>>>>>>> [2] > >>>>>>>>> https://blogs.oracle.com/java-platform-group/faster-and- > >>>>>>>> easier-use-and-redistribution-of-java-se > >>>>>>>>> [3] > >>>>>>>>> https://www.oracle.com/java/java9-screencasts.html?bcid= > >>>>>>>> 5582439790001&playerType=single-social&size=events > >>>>>>>>> [4] > >>>>>>>>> http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live. > >>>>>>>> html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ > >>>>>>>> StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29 > >>>>>>>>> [5] https://issues.apache.org/jira/browse/CASSANDRA-9608 > >>>>>>>> > >>>>>>>> > >>>> - > >>>>>>>> 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 > > -- Eric Evans eev...@wikimedia.org
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
On Wed, Mar 21, 2018 at 9:00 AM, Josh McKenzie wrote: >> Wasn't portability supposed to be one of the >> big selling points of Java? > Historically, yes, but their change in release cadence and support > structure is something they're pushing, not us. We have to figure out > how to make the best of a change that is, at best, orthogonal to our > interests as a project. > > Maintaining portability within a few releases of the JDK for each > supported version of C* is a non-trivial amount of work with a 6 month > refresh timer on it. Do we know this though? More frequent releases should also mean that each new release has accumulated less change (the typical trade-off). Also, these JDKs are supposed to be backward compatible, if this isn't the case because (for example) we are (ab)using private interfaces, that's probably worth looking at anyway. > On Wed, Mar 21, 2018 at 9:49 AM, Eric Evans wrote: >> On Wed, Mar 21, 2018 at 8:04 AM, Stefan Podkowinski wrote: >> >>> There's also another option, which I just want to mention here for the >>> sake of discussion. >>> >>> Quoting the Oracle Support Roadmap: >>> "Instead of relying on a pre-installed standalone JRE, we encourage >>> application developers to deliver JREs with their applications." >>> >>> I've played around with Java 9 a while ago and also tested creating a >>> self contained JRE using jlink, which you can bundle and ship with your >>> application. So there's a technical solution for that with Java 9. Of >>> course you'd have to clarify licensing issues (OpenJDK is GPLv2 + >>> Classpath exception) first. >>> >>> Bundling a custom JRE along with Cassandra, would be convenient in a way >>> that we can do all the testing against the bundled Java version. We >>> could also switch to a new Java version whenever it fits us. Like e.g. >>> apache-cassandra-4.0.14_openjdk11u321 and two months later release >>> apache-cassandra-4.0.15_openjdk12u123. History has shown that planing >>> and timing new releases isn't always working out for us as expected. I'd >>> rather prefer not having to tightly coordinate our own releases together >>> with OpenJDK releases, if it can be avoided. At the same time I'd like >>> to avoid having users updating to incompatible JREs (think about >>> 8u161/#14173), or have them constantly ask which JRE version to use for >>> which Cassandra version, always with the risk of automatic updates >>> causing unexpected issues. Bundling the JRE may help us with that, as it >>> would become more a matter of testing and getting CI turn green, before >>> we're ready to bundle the next major JRE update, without getting the >>> user involved at all. >>> >>> If you would prefer using a global system JRE, that should still be >>> possible by installing an unbundled Cassandra version, but you'd have to >>> pay attention which Java version to use for which Cassandra release, >>> possibly having to provide patches and do some testing for more recent >>> Cassandra versions, in case of compatibility issues. If we update 3.11 >>> to Java 13 in mid 2019, we'd have to provide release candidates that can >>> be used for testing for such incompatibilities by LTS users and have >>> them provide patches, which then have to fully work with Java 13 of >>> course. Otherwise I can't see how to make Oracle/Redhat/IBM/Azul LTS >>> releases work, except on this best effort basis without official support >>> guarantees by us. >>> >>> I'm not too enthusiastic about this perspective. But I wouldn't >>> completely dismiss it either, without talking about all the other >>> options first. >>> >> >> Personally, I don't like the idea of vendoring like this at all. Wasn't >> portability supposed to be one of the big selling points of Java? Wouldn't >> our efforts be better directed at being portable to within a few releases >> of the JDK, than to tightly couple it to once specific version? >> >> >>> On 20.03.2018 22:32, Ariel Weisberg wrote: >>> > Hi, >>> > >>> > Synchronizing with Oracle LTS releases is kind of low value if it's a >>> paid offering. But if someone in the community doesn't want to upgrade and >>> pays Oracle we don't want to get in the way of that. >>> > >>> > Which is how you end up with what Jordan and ElasticSearch suggest. I'm >>> stil
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
On Wed, Mar 21, 2018 at 9:21 AM, Gerald Henriksen wrote: > On Wed, 21 Mar 2018 14:04:39 +0100, you wrote: > >>There's also another option, which I just want to mention here for the >>sake of discussion. >> >>Quoting the Oracle Support Roadmap: >>"Instead of relying on a pre-installed standalone JRE, we encourage >>application developers to deliver JREs with their applications." >> >>I've played around with Java 9 a while ago and also tested creating a >>self contained JRE using jlink, which you can bundle and ship with your >>application. So there's a technical solution for that with Java 9. Of >>course you'd have to clarify licensing issues (OpenJDK is GPLv2 + >>Classpath exception) first. >> >>Bundling a custom JRE along with Cassandra, would be convenient in a way >>that we can do all the testing against the bundled Java version. We >>could also switch to a new Java version whenever it fits us. > > To a certain extent though the issue isn't whether Cassandra works > well with the given JRE but rather the issue of having a supported JRE > in a production environment. > > If Cassandra ships with a bundled JRE does that then mean the > people/organizations downloading and using that product are going to > expect the Cassandra project to provide bug and security updates to > the JRE as well as Cassandra? > > What happens if an organization gets hacked due to an issue in an out > of date JRE that Cassandra bundled? Yes, that can currently happen if > the organization chooses to run Cassandra on an unsupported JRE. But > in that case the organization has made that decision, not Cassandra. Exactly. It is common for organizations to evaluate JVM errata against their environment/requirements and the use-cases they have, then act accordingly. If applications start embedding their own JVM this becomes a combinatorial nightmare. > Essentially any security concious entity, whether a person or > organization, running any software stack on top of Java (or I guess > any of the other languages based on the JVM) is going to have to make > a choice between constantly updating their JRE or going with a LTS > version (either from Oracle or Red Hat or any other company that is > willing to provide it). Or maybe even move to .Net now that it is > supported on Linux. > > I don't think there are any great choices here for Cassandra or any of > the other Java based projects but an easy solution (in terms of basing > the project on a supported JRE that can be downloaded for free) would > be to choose whatever version of OpenJDK is supported by Red Hat or > any other Linux distribution that offers a LTS release. > > So for example basing on OpenJDK 8 gets you support until October 2020 > with paying for Red Hat, or for free (with mainly security updates) by > using Centos. Agreed. Someone said this elsewhere as well, that the community will work this out. Even if you are not running say Debian, or RedHat, those distributions will be backporting critical fixes to their JVMs; This work is going to be done, and will be available to anyone. If this becomes an issue, it'll be an issue facing a lot of people, and I expect unofficial LTS releases will quickly become available. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Roadmap for 4.0
On Mon, Apr 9, 2018 at 3:56 PM, Jonathan Haddad wrote: [ ... ] > If they're not close to finished now why even consider them for > the 4.0 release? They're so core they should be merged into trunk at the > beginning of the cycle for the follow up release in order to get as much > exposure as possible. This sounds right to me. Bigger, destabilizing changes should land at the beginning of the cycle; Setting up a mad rush at the end of a release cycle does not yield favorable results (we've done this, we know). > On Mon, Apr 9, 2018 at 1:46 PM Nate McCall wrote: > >> > I'd like to see pluggable storage and transient replica tickets land, for >> > starters. >> >> I think both those features are, frankly, necessary for our future. On >> the other hand, they both have the following risks: >> 1. core behavioral changes >> 2. require changing a (relatively) large surface area of code >> >> We can aim to de-risk 4.0 by focusing on what we have now which is >> solid repair and NIO internode (maybe we move the 4.0 branch timeline >> up?), aiming for a 4.1 following soon-ish. >> >> Or we can go in eyes open and agree on a larger footprint 4.0. >> >> I'm on the fence, tbh (can't emphasize enough how big both those >> features will be). I just want everyone to know what we are getting >> into and that we are potentially impacting our goals of "stable" == >> "exciting." Unfortunately, when stability suffers things get "exciting" for all sorts of unintended reasons. I'm personally not umm, excited, by that prospect. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Roadmap for 4.0
On Thu, Apr 12, 2018 at 4:07 AM, Sylvain Lebresne wrote: > I feel this discussion is starting to go in every directions and getting > farther away from any decision/progress so I'll attempt to summarize what I > hear, where I stand and *more importantly*, why. > > So as far as "what do we do for 4.0", I hear it boil down to 3 options: > 1) we freeze June 1. It says nothing on when we do release but starting > testing early, which also by extension limit the scope of what needs to be > tested, give believability in an earlier and more stable release. Everyone > seems to agree stability is good, and having no major release for too long > run the risk of everyone outside our own bubble thinking the project is > dead. > 2) we decide on a freeze date now, but later than June 1 (the question is > then "when?"). I'm listing this because there has been some explicit "+1 to > freezing but not June 1" but I'll admit I'm not entirely sure of the > reasoning behind this, and if there has been explicit argument for this, > I've missed them. > 3) we don't decide on a freeze date, 4.0 freeze is feature related. So we > build a list of features that needs to be in to freeze (which can have some > color for sure, some may be harder requirements than others). The best > argument I've heard for this is Blake's one, which is that people won't > truly test the release unless it is sexy (implying trunk isn't at all right > now) and that it would therefore yield more stability. Personally, a sexy Cassandra release is one that doesn't cost me an inordinate amount of work and imperil my production clusters. A sexy Cassandra release is one with as few surprises as possible. I can't remember the last major release I thought was sexy. Additionally, I'm more likely to be able to spend time testing a new release, the more that work can be shown to move us closer to implementing it (which becomes more difficult as the delta increases). > As should be clear, I'm a proponent of 1 for the reasoning I expressed on > that point. I don't deny there is some logic behind the "it needs to be > sexy to be tested" argument for 3, but it's simply imo more risky, and too > much so. And this because: > 1) I'm convinced it will delay the release *a lot* in practice compared to > option 1 and I think we're underestimating the damage not releasing a major > for years will do to the project. > 2) it's all predicated on people doing unprecedented level of testing that > they wouldn't do if we go with option 1, but there is no historical > evidence to support the notion that it is a safe bet. If this doesn't > happen, which we *have* to consider, then the project will be in a *much* > worst state than with option 1. We'll have taken forever to release a less > stable release. +1 I think the way we address all those "sexy features" people want to get out, is by working to increase the release cadence (without increasing the burden on operators). Release early, release often. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Proposing an Apache Cassandra Management process
On Thu, Apr 12, 2018 at 4:41 PM, Dinesh Joshi wrote: > Hey all - > With the uptick in discussion around Cassandra operability and after > discussing potential solutions with various members of the community, we > would like to propose the addition of a management process/sub-project into > Apache Cassandra. The process would be responsible for common operational > tasks like bulk execution of nodetool commands, backup/restore, and health > checks, among others. We feel we have a proposal that will garner some > discussion and debate but is likely to reach consensus. > While the community, in large part, agrees that these features should exist > “in the database”, there is debate on how they should be implemented. > Primarily, whether or not to use an external process or build on > CassandraDaemon. This is an important architectural decision but we feel the > most critical aspect is not where the code runs but that the operator still > interacts with the notion of a single database. Multi-process databases are > as old as Postgres and continue to be common in newer systems like Druid. As > such, we propose a separate management process for the following reasons: > >- Resource isolation & Safety: Features in the management process will not > affect C*'s read/write path which is critical for stability. An isolated > process has several technical advantages including preventing use of > unnecessary dependencies in CassandraDaemon, separation of JVM resources like > thread pools and heap, and preventing bugs from adversely affecting the main > process. In particular, GC tuning can be done separately for the two > processes, hopefully helping to improve, or at least not adversely affect, > tail latencies of the main process. > >- Health Checks & Recovery: Currently users implement health checks in > their own sidecar process. Implementing them in the serving process does not > make sense because if the JVM running the CassandraDaemon goes south, the > healthchecks and potentially any recovery code may not be able to run. Having > a management process running in isolation opens up the possibility to not > only report the health of the C* process such as long GC pauses or stuck JVM > but also to recover from it. Having a list of basic health checks that are > tested with every C* release and officially supported will help boost > confidence in C* quality and make it easier to operate. > >- Reduced Risk: By having a separate Daemon we open the possibility to > contribute features that otherwise would not have been considered before eg. > a UI. A library that started many background threads and is operated > completely differently would likely be considered too risky for > CassandraDaemon but is a good candidate for the management process. Makes sense IMO. > What can go into the management process? >- Features that are non-essential for serving reads & writes for eg. > Backup/Restore or Running Health Checks against the CassandraDaemon, etc. > >- Features that do not make the management process critical for > functioning of the serving process. In other words, if someone does not wish > to use this management process, they are free to disable it. > > We would like to initially build minimal set of features such as health > checks and bulk commands into the first iteration of the management process. > We would use the same software stack that is used to build the current > CassandraDaemon binary. This would be critical for sharing code between > CassandraDaemon & management processes. The code should live in-tree to make > this easy. > With regards to more in-depth features like repair scheduling and discussions > around compaction in or out of CassandraDaemon, while the management process > may be a suitable host, it is not our goal to decide that at this time. The > management process could be used in these cases, as they meet the criteria > above, but other technical/architectural reasons may exists for why it should > not be. > We are looking forward to your comments on our proposal, Sounds good to me. Personally, I'm a little less interested in things like health/availability checks and metrics collection, because there are already tools to solve this problem (and most places will already be using them). I'm more interested in things like cluster status, streaming, repair, etc. Something to automate/centralize database-specific command and control, and improve visibility. In-tree also makes sense (tools/ maybe?), but I would suggest working out of a branch initially, and seeking inclusion when there is something more concrete to discuss. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Update: Cassandra Virtual Nodes
to contribute or work with a clone from github then it >> would be advisable to familiarise yourself with TopGit, the tool we >> have been using for branch-based patch queue management. We've written >> up a tutorial here: >> https://github.com/acunu/cassandra/wiki/TopGit-Tutorial >> >> == What's left? == >> >> We haven't included any patches for tickets CASSANDRA-4123 and >> CASSANDRA-4124 which relate to the replication strategy and repair. >> Currently replication and repair "just work" with the current patches >> without any additional changes required. >> >> CASSANDRA-4126 relates to testing. We're running virtual nodes builds >> through our own test suites but we will also be writing new tests in >> addition. >> >> >> I look forward to your questions and comments! >> >> >> -- >> Sam Overton >> Acunu | http://www.acunu.com | @acunu > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com -- Eric Evans Acunu | http://www.acunu.com | @acunu
[VOTE] Release Apache Cassandra 1.1.4
There are bug-fixes worthy of a minor release sitting in 1.1, and Sylvain is taking a holiday, so here's hoping that I remember how all of this goes. I propose the following for release as 1.1.4. Check it over carefully though, it's entirely possible I missed dotting an I, or crossing a T somewhere. :) SHA1: 9dc5608 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.4-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-134/org/apache/cassandra/apache-cassandra/1.1.4 Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-134 The artifacts as well as the debian package are also available here: http://people.apache.org/~eevans The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/kmyHH (CHANGES.txt) [2]: http://goo.gl/Dw4mM (NEWS.txt) -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: [VOTE] Release Apache Cassandra 1.1.4
Oh hell. I'll reroll shortly. On Mon, Aug 13, 2012 at 10:56 PM, Cathy Daw wrote: > I received an error starting the server and Jonathan suggested it may be due > to having the binary compiled with Java 1.7. > > The binary is from > https://repository.apache.org/content/repositories/orgapachecassandra-134/org/apache/cassandra/apache-cassandra/1.1.4/apache-cassandra-1.1.4-bin.tar.gz > > $ ./cassandra > xss = -ea -javaagent:./../lib/jamm-0.2.5.jar -XX:+UseThreadPriorities > -XX:ThreadPriorityPolicy=42 -Xms1024M -Xmx1024M -Xmn200M > -XX:+HeapDumpOnOutOfMemoryError > Cathy-Daws-MacBook-Pro:bin cathy$ Exception in thread "main" > java.lang.UnsupportedClassVersionError: > org/apache/cassandra/thrift/CassandraDaemon : Unsupported major.minor version > 51.0 > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) > at java.lang.ClassLoader.defineClass(ClassLoader.java:615) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) > at java.net.URLClassLoader.access$000(URLClassLoader.java:58) > at java.net.URLClassLoader$1.run(URLClassLoader.java:197) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > > > On Aug 13, 2012, at 4:09 PM, Jonathan Ellis wrote: > >> I just now added #4494 to CHANGES, but probably not worth re-rolling >> for. +1 from me >> >> On Mon, Aug 13, 2012 at 4:44 PM, Eric Evans wrote: >>> There are bug-fixes worthy of a minor release sitting in 1.1, and >>> Sylvain is taking a holiday, so here's hoping that I remember how all >>> of this goes. >>> >>> I propose the following for release as 1.1.4. Check it over carefully >>> though, it's entirely possible I missed dotting an I, or crossing a T >>> somewhere. :) >>> >>> SHA1: 9dc5608 >>> Git: >>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.4-tentative >>> Artifacts: >>> https://repository.apache.org/content/repositories/orgapachecassandra-134/org/apache/cassandra/apache-cassandra/1.1.4 >>> Staging repository: >>> https://repository.apache.org/content/repositories/orgapachecassandra-134 >>> >>> The artifacts as well as the debian package are also available here: >>> http://people.apache.org/~eevans >>> >>> The vote will be open for 72 hours (longer if needed). >>> >>> [1]: http://goo.gl/kmyHH (CHANGES.txt) >>> [2]: http://goo.gl/Dw4mM (NEWS.txt) >>> >>> -- >>> Eric Evans >>> Acunu | http://www.acunu.com | @acunu >> >> >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder of DataStax, the source for professional Cassandra support >> http://www.datastax.com > -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: [VOTE] Release Apache Cassandra 1.1.4
On Tue, Aug 14, 2012 at 9:15 AM, Eric Evans wrote: > Oh hell. I'll reroll shortly. And by shortly I mean, shortly after repository.apache.org is working again. -- Eric Evans Acunu | http://www.acunu.com | @acunu
[VOTE] Release Apache Cassandra 1.1.4 (take #2)
I knew I'd mess up something; So here we go again, this time built with the right version of JDK. SHA1: 8b1336f Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.4-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-003/org/apache/cassandra/apache-cassandra/1.1.4 Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-003 The artifacts as well as the debian package are also available here: http://people.apache.org/~eevans The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/Iu7W3 (CHANGES.txt) [2]: http://goo.gl/yi8Iu (NEWS.txt) -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: [VOTE] Release Apache Cassandra 1.1.4 (take #2)
On Tue, Aug 14, 2012 at 4:34 PM, Eric Evans wrote: > SHA1: 8b1336f > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.4-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-003/org/apache/cassandra/apache-cassandra/1.1.4 > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-003 > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~eevans > > The vote will be open for 72 hours (longer if needed). Counting my own we appear to have 5 binding votes; The vote is now closed I'll get the artifacts published shortly. Thanks, -- Eric Evans Acunu | http://www.acunu.com | @acunu
Upgrade path for virtual nodes
Hi all, First off, the ground rules. :) This is a development/design discussion. If you have general questions about virtual nodes that don't pertain to this discussion, please ask them in another thread, or on user@ and we'll get them answered there. BACKGROUND Currently, an upgrade from 1.1.x to 1.2 will result no change as far as virtual nodes are concerned. Upgraded clusters will continue to operate with the single token per node they were originally configured with. If however you wish to upgrade your cluster to virtual nodes, you do so by setting the num_tokens parameter in cassandra.yaml to something greater than one (recommended: 256), and restarting your nodes. This results in the existing range on each node being split into num_tokens parts. This works fine except that the new ranges are still contiguous, and ideally need to be randomly (re)distributed for optimal effect. Enter CASSANDRA-4443[1] for the creation of a so-called shuffle utility to do exactly that, redistribute the tokens to random locations. I'm ready to start on this, whatever shape it takes, but since it seems the requirements could use some shoring up, I thought I'd raise it for discussion here. Shuffling the ranges to create a random distribution from contiguous ranges has the potential to move a *lot* of data around (all of it, basically). Doing this in an optimal way would mean never moving a range more than once. Since it is a lot of data, and since presumably we're expecting normal operations to continue in the meantime, it would seem an optimal shuffle would need to maintain state. For example, one machine could serve as the "shuffle coordinator", precalculating and persisting all of the moves, starting new transfers as existing ones finish, and tracking the progress, etc. Talking with Brandon Williams earlier, he suggested a simpler approach of treating shuffle as a per node operation (possibly limited to some subset of the ranges). There would be no tracking of state. If a shuffle failed, you would either rerun it in its entirety, or not (if for example you decided it made enough progress to satisfy your requirements for distribution). Of the two, the former benefits from being optimal all around, but it's a fairly involved bit of code for something that I assume will be used on a cluster at most once (is this a safe assumption?). The latter is much simpler to implement, but places more onus on the user to get right, and will result in either or both of, a lot of needless retransfer of data, and poor redistribution (i.e. if a shuffle didn't complete, or if a subset of ranges was used). So the question I pose for discussion is: What are the requirements for a shuffle operation? How optimal does it need to be? How fool-proof? [1]: https://issues.apache.org/jira/browse/CASSANDRA-4443 [2]: http://wiki.apache.org/cassandra/VirtualNodes/Balance -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: Upgrade path for virtual nodes
On Tue, Aug 21, 2012 at 2:54 PM, Jonathan Ellis wrote: > On Mon, Aug 20, 2012 at 4:55 PM, Eric Evans wrote: >> Shuffling the ranges to create a random distribution from contiguous >> ranges has the potential to move a *lot* of data around (all of it, >> basically). Doing this in an optimal way would mean never moving a >> range more than once. Since it is a lot of data, and since presumably >> we're expecting normal operations to continue in the meantime, it >> would seem an optimal shuffle would need to maintain state. For >> example, one machine could serve as the "shuffle coordinator", >> precalculating and persisting all of the moves, starting new transfers >> as existing ones finish, and tracking the progress, etc. > > Fortunately, we have a distributed storage system :) > > Seriously though, creating a CF mapping vnode from->to tuples, > throwing in the list of changes to make once, and deleting them out as > they complete, would be a pretty simple way to get what we want. Yeah, that's exactly what I had in mind to do. Actually, now that I think about it, I'd probably drop the entire notion of a "coordinator", and write the respective entiries into a column family in the system keyspaces. Each system could then work through their respective queue of relocations at their own pace. What would you think of this approach? -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: Upgrade path for virtual nodes
On Fri, Aug 24, 2012 at 11:27 AM, Jonathan Ellis wrote: > On Fri, Aug 24, 2012 at 11:23 AM, Eric Evans wrote: >> Actually, now that I think about it, I'd probably drop the entire >> notion of a "coordinator", and write the respective entiries into a >> column family in the system keyspaces. Each system could then work >> through their respective queue of relocations at their own pace. > > Sounds reasonable. OK, then unless someone steps forward with a better idea, I'll proceed with this approach. Thanks! -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: Upgrade path for virtual nodes
On Fri, Aug 24, 2012 at 3:39 PM, Eric Evans wrote: > On Fri, Aug 24, 2012 at 11:27 AM, Jonathan Ellis wrote: >> On Fri, Aug 24, 2012 at 11:23 AM, Eric Evans wrote: >>> Actually, now that I think about it, I'd probably drop the entire >>> notion of a "coordinator", and write the respective entiries into a >>> column family in the system keyspaces. Each system could then work >>> through their respective queue of relocations at their own pace. >> >> Sounds reasonable. > > OK, then unless someone steps forward with a better idea, I'll proceed > with this approach. I've updated the ticket[1] with a link to a patch[2] that implements what I was thinking here. Each node implements a scheduler that periodically looks in a system table for token ranges that should be relocated to it. As a safety measure, it will skip new transfers if the actual number of tokens exceeds num_tokens by 10% or more (giving slower nodes a chance to catch up, if needed). The periodic scheduler can be enabled and disabled using JMX. What remains is to create the administrative tool, something to calculate the token moves and populate the tables with the respective entries. Any thoughts on this? Should this be something baked into nodetool, or a separate utility? Can we add the entries directly, or should this be done via JMX? Also, do we have an exact date for the freeze yet? I assume I have at least until Sylvain returns from holiday. :) Thoughts, comments, ideas? [1]: https://issues.apache.org/jira/browse/CASSANDRA-4443 [2]: https://github.com/acunu/cassandra/compare/top-bases/p/4443/050_process_queued_xfers...p/4443/050_process_queued_xfers.diff -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: 1.2 freeze
On Mon, Aug 27, 2012 at 5:16 PM, Jonathan Ellis wrote: > Here are the ten issues I think we should resolve before freezing > 1.2.0 and releasing beta 1: > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CASSANDRA+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%221.2.0+beta+1%22+ORDER+BY+priority+DESC&mode=hide > > The remaining issues for 1.2.0 are either bugs that can be addressed > during the freeze or updates to tools (e.g., stress, shuffle) that IMO > are okay to address after beta 1: > > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CASSANDRA+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%221.2.0%22+ORDER+BY+priority+DESC&mode=hide > > I've pushed other issues to 1.2.1 and 1.3. > > Thoughts? https://issues.apache.org/jira/browse/CASSANDRA-4559 (pending review), is a dependency for shuffle (https://issues.apache.org/jira/browse/CASSANDRA-4443). Also, CASSANDRA-4443 has a node-side component in addition to the tooling. -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: Build failed in Jenkins: Cassandra-quick #1361
On Tue, Sep 18, 2012 at 10:18 AM, Sean Coleman wrote: > How can I unsubscribe? Send an email to user-unsubscr...@cassandra.apache.org -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: Build failed in Jenkins: Cassandra-quick #1375
> per node).
>> [junit] WARN 14:10:38,974 Generated random token
>> [Token(bytes[ea187baf05f7a1eab26faa3a31db43a7])]. Random tokens will result
>> in an unbalanced ring; see http://wiki.apache.org/cassandra/Operations
>> [junit] - ---
>> [junit] Testsuite: org.apache.cassandra.thrift.ThriftValidationTest
>> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 4.207 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.tools.SSTableExportTest
>> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 4.486 sec
>> [junit]
>> [junit] - Standard Output ---
>> [junit] Importing 1 keys...
>> [junit] 1 keys imported successfully.
>> [junit]
>> [{"columns":[["636f6c4e616d65","76616c",1348150250588],["636f6c4e616d6531","76616c31",1348150250588]],"key":"726f7741","metadata":{"deletionInfo":{"markedForDeleteAt":0,"localDeletionTime":0}}}]
>> [junit] - ---
>> [junit] Testsuite: org.apache.cassandra.tools.SSTableImportTest
>> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 4.476 sec
>> [junit]
>> [junit] - Standard Output ---
>> [junit] Counting keys to import, please wait... (NOTE: to skip this use -n
>> )
>> [junit] Importing 2 keys...
>> [junit] 2 keys imported successfully.
>> [junit] Counting keys to import, please wait... (NOTE: to skip this use -n
>> )
>> [junit] Importing 2 keys...
>> [junit] 2 keys imported successfully.
>> [junit] Counting keys to import, please wait... (NOTE: to skip this use -n
>> )
>> [junit] Importing 2 keys...
>> [junit] 2 keys imported successfully.
>> [junit] Importing 3 keys...
>> [junit] Importing 2 keys...
>> [junit] 2 keys imported successfully.
>> [junit] Counting keys to import, please wait... (NOTE: to skip this use -n
>> )
>> [junit] Importing 2 keys...
>> [junit] 2 keys imported successfully.
>> [junit] Counting keys to import, please wait... (NOTE: to skip this use -n
>> )
>> [junit] Importing 1 keys...
>> [junit] 1 keys imported successfully.
>> [junit] - ---
>> [junit] - Standard Error -
>> [junit] Line 2: Key null is greater than previous, collection is not sorted
>> properly. Aborting import. You might need to delete SSTables manually.
>> [junit] - ---
>> [junit] Testsuite: org.apache.cassandra.utils.BloomFilterTest
>> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.537 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.BoundedStatsDequeTest
>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.055 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.ByteBufferUtilTest
>> [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.072 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.BytesReadTrackerTest
>> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.057 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.EncodedStreamsTest
>> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 4.281 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.EstimatedHistogramTest
>> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.059 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.FBUtilitiesTest
>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.06 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.HexTest
>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.061 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.IntervalTreeTest
>> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.17 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.LegacyBloomFilterTest
>> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.448 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.MergeIteratorTest
>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.075 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.MerkleTreeTest
>> [junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 1.028 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.SemanticVersionTest
>> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.059 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.SerializationsTest
>> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 5.991 sec
>> [junit]
>> [junit] Testsuite: org.apache.cassandra.utils.StreamingHistogramTest
>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.06 sec
>> [junit]
>>
>> BUILD SUCCESSFUL
>> Total time: 9 minutes 32 seconds
>> [TASKS] Scanning folder
>> '<https://builds.apache.org/job/Cassandra-quick/ws/'> for files matching the
>> pattern '**/*.java' - excludes:
>> [TASKS] Found 900 files to scan for tasks
>> [TASKS] Found 126 open tasks.
>> [TASKS] Computing warning deltas based on reference build #82
>> Recording test results
>> No test report files were found. Configuration error?
>> Build step 'Publish JUnit test result report' changed build result to FAILURE
>>
>>
>
>
--
Eric Evans
Acunu | http://www.acunu.com | @acunu
Re: Build failed in Jenkins: Cassandra-quick #1375
http://goo.gl/tl8xI On Thu, Sep 20, 2012 at 11:11 AM, Jonathan Ellis wrote: > The list you are mailing is the dev list, not the user list. Which is > what the confirmation message you pasted says... > > On Thu, Sep 20, 2012 at 11:05 AM, Sean Coleman > wrote: >> Thanks for thinking of saving me time by googling that for me….. but I did >> already unsubscribed by emailing the unsubscribe address. >> >> >> >> Here is the unsubscribe response: >> >> Hi! This is the ezmlm program. I'm managing the >> u...@cassandra.apache.org (mailto:u...@cassandra.apache.org) mailing list. >> >> Acknowledgment: The address >> >> sean.cole...@jobing.com (mailto:sean.cole...@jobing.com) >> >> was not on the user mailing list when I received >> your request and is not a subscriber of this list. >> >> >> >> >> Here's the confirmation email when I subscribed: >> >> Hi! This is the ezmlm program. I'm managing the >> dev@cassandra.apache.org (mailto:dev@cassandra.apache.org) mailing list. >> >> I'm working for my owner, who can be reached >> at dev-ow...@cassandra.apache.org (mailto:dev-ow...@cassandra.apache.org). >> >> Acknowledgment: I have added the address >> >> sean.cole...@jobing.com (mailto:sean.cole...@jobing.com) >> >> to the dev mailing list. >> >> Welcome to dev@cassandra.apache.org (mailto:dev@cassandra.apache.org)! >> >> >> >> >> -- >> Regards & Go Jobing! >> >> Sean Coleman >> Jobing | Jobing.com (http:/www.jobing.com) | Recruiting.com >> (http://www.recruiting.com) >> >> Email/Gtalk: sean.cole...@jobing.com (mailto:sean.cole...@jobing.com) >> SMS/Voice: 602.570.7633 >> >> Learn More About Our Products & Services >> - Job Board Solutions:jobing.com/recruiting >> (http://jobing.com/recruiting) >> - Technology Services: recruiting.com (http://recruiting.com) >> >> >> On Thursday, September 20, 2012 at 8:53 AM, Eric Evans wrote: >> >>> On Thu, Sep 20, 2012 at 10:00 AM, Sean Coleman >> (mailto:sean.cole...@jobing.com)> wrote: >>> > How do I unsubscribe? >>> >>> >>> http://lmgtfy.com/?q=unsubscribe+cassandra+mailing+list >>> >>> > On Thursday, September 20, 2012 at 7:11 AM, Apache Jenkins Server wrote: >>> > >>> > > See <https://builds.apache.org/job/Cassandra-quick/1375/changes> >>> > > >>> > > Changes: >>> > > >>> > > [xedin] fix error when using ORDER BY with extended selections >>> > > >>> > > -- >>> > > [...truncated 450 lines...] >>> > > [junit] >>> > > [junit] - Standard Error - >>> > > [junit] WARN 14:08:43,252 No host ID found, created >>> > > c3beb601-2d9f-4296-84fd-bea8f9222a66 (Note: This should happen exactly >>> > > once per node). >>> > > [junit] WARN 14:08:43,355 Generated random token >>> > > [Token(bytes[e2ebec4c0f812390c8c61c755d239273])]. Random tokens will >>> > > result in an unbalanced ring; see >>> > > http://wiki.apache.org/cassandra/Operations >>> > > [junit] - --- >>> > > [junit] Testsuite: >>> > > org.apache.cassandra.service.AntiEntropyServiceStandardTest >>> > > [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 5.956 sec >>> > > [junit] >>> > > [junit] - Standard Error - >>> > > [junit] WARN 14:08:49,960 No host ID found, created >>> > > 3e585025-5c9b-4746-b5db-8f50a6ab56d6 (Note: This should happen exactly >>> > > once per node). >>> > > [junit] WARN 14:08:50,070 Generated random token >>> > > [Token(bytes[228f88bbaa54ac4c7a305c013a761644])]. Random tokens will >>> > > result in an unbalanced ring; see >>> > > http://wiki.apache.org/cassandra/Operations >>> > > [junit] - --- >>> > > [junit] Testsuite: org.apache.cassandra.service.CassandraServerTest >>> > > [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.254 sec >>> > > [junit] >>> > > [junit] Testsuite: >>> > > org.apache.cassandra.service.EmbeddedCassandraServiceTest >>> &
Re: [VOTE] Release Apache Cassandra 1.2.0-beta1
On Tue, Sep 18, 2012 at 11:55 AM, Sylvain Lebresne wrote: > sha1: 60bf68caa98566ce09e76d501b14d45b46c26209 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.0-beta1-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-016/org/apache/cassandra/apache-cassandra/1.2.0-beta1/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-016/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~slebresne/ > > The vote will be open for 72 hours (longer if needed). +1 -- Eric Evans Acunu | http://www.acunu.com | @acunu
ApacheCon EU -- Hackathon anyone?
Hi all, ApacheCon EU[1] is in 3 weeks, and Monday the 5th[2] is reserved for hackathons[3]. Who else is planning to be in Sinsheim on the 5th, and, is there any interest in a Cassandra hackathon? One idea for a hackathon would be to focus on testing (writing, running, manual), and bug squashing. This is broad enough that people of all skill levels should be able to contribute. So, is anyone interested? [1]: 5–8 November, Sinsheim, Germany [2]: Guy Fawkes Day! [3]: http://wiki.apache.org/apachecon/HackathonEU12 -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: Write Timestamps
On Wed, Oct 24, 2012 at 9:13 PM, Jeremiah Jordan
wrote:
> How are you doing the write? CQL or Thrift? In thrift, the client specifies
> the timestamp, and you should always be seeing that as the timestamp. In
> CQL, the CQL layer on the server adds the timestamp.
For the record, you can supply a timestamp with CQL, same as you can
with Thrift. For example:
INSERT INTO somedb.sometable (id, given, surname) VALUES ('pgriffith',
'Peter', 'Griffith') USING TIMESTAMP 42;
--
Eric Evans
Acunu | http://www.acunu.com | @acunu
Re: [VOTE] Release Apache Cassandra 1.1.8
+1 On Mon, Dec 17, 2012 at 10:56 AM, Brandon Williams wrote: > +1 > > On Mon, Dec 17, 2012 at 3:28 AM, Sylvain Lebresne > wrote: >> We've fixed a few annoying issue since 1.1.7 so I propose the following >> artifacts for release as 1.1.8. >> >> sha1: 4885bfccf1841def0c86b46302133cf2924d7acd >> Git: >> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.8-tentative >> Artifacts: >> https://repository.apache.org/content/repositories/orgapachecassandra-037/org/apache/cassandra/apache-cassandra/1.1.8/ >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachecassandra-037/ >> >> The artifacts as well as the debian package are also available here: >> http://people.apache.org/~slebresne/ >> >> The vote will be open for 72 hours (longer if needed). >> >> [1]: http://goo.gl/vkaZt (CHANGES.txt) >> [2]: http://goo.gl/H3E61 (NEWS.txt) -- Eric Evans Acunu | http://www.acunu.com | @acunu
ApacheCon NA Hackathon?
Hi, ApacheCon NA is February 26-28 in Portland, with project hackathons hosted on Monday the 25th. How many are planning to attend ApacheCon this year? Is there any interest in organizing a Cassandra hackathon? http://wiki.apache.org/apachecon/HackathonNA13 Cheers, -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: ApacheCon NA Hackathon?
On Sun, Dec 30, 2012 at 8:30 PM, Tomaz Muraus wrote: > I will be at ApacheCon NA and I would be interested in participating (at > least part of the time) and working on improving Node.js Cassandra client > and adding support for CQL 3.0. Great. Drivers might be a good focus for a hackathon; I was planning to spend some time working on a C native driver. If you haven't already, add 1 to the number of interested persons on http://wiki.apache.org/apachecon/HackathonNA13. See you there! > On Wed, Dec 26, 2012 at 1:54 PM, Eric Evans wrote: > >> Hi, >> >> ApacheCon NA is February 26-28 in Portland, with project hackathons >> hosted on Monday the 25th. >> >> How many are planning to attend ApacheCon this year? Is there any >> interest in organizing a Cassandra hackathon? >> >> http://wiki.apache.org/apachecon/HackathonNA13 >> >> Cheers, >> >> -- >> Eric Evans >> Acunu | http://www.acunu.com | @acunu >> -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: Proposal: require Java7 for Cassandra 2.0
http://i.imgur.com/kQWV2.gif On Thu, Feb 7, 2013 at 9:38 PM, Anton Prakash wrote: > unsubscribe > > > On Thu, Feb 7, 2013 at 12:58 PM, Ajith Kannan > wrote: > >> +1 >> >> On 2/6/2013 9:13 PM, Jake Luciani wrote: >> >>> +1 >>> >>> On Wed, Feb 6, 2013 at 5:32 PM, Gary Dusbabek >>> wrote: >>> >>> +1 >>>> >>>> >>>> On Wed, Feb 6, 2013 at 4:21 PM, Jonathan Ellis >>>> wrote: >>>> >>>> Java 6 EOL is this month. Java 7 will be two years old when C* 2.0 >>>>> comes out (July). Anecdotally, a bunch of people are running C* on >>>>> Java7 with no issues, except for the Snappy-on-OS-X problem (which >>>>> will be moot if LZ4 becomes our default, as looks likely). >>>>> >>>>> Upgrading to Java7 lets us take advantage of new (two year old) >>>>> features as well as simplifying interoperability with other >>>>> dependencies, e.g., Jetty's BlockingArrayQueue requires java7. >>>>> >>>>> Thoughts? >>>>> >>>>> -- >>>>> Jonathan Ellis >>>>> Project Chair, Apache Cassandra >>>>> co-founder, http://www.datastax.com >>>>> @spyced >>>>> >>>>> >>> >>> -- Eric Evans Acunu | http://www.acunu.com | @acunu
ApacheCon North America
Hi All It's now about 2 weeks until ApacheCon North America, which is taking place Sunday 24th Feb - Thursday 28th in Portland. Quite a few people from our project will be there, and we'd love to see you all! If you haven't already registered for the conference, then we've some good news - we've managed to snag a 20% discount for you! To register with the 20% off, use code PMC or the link http://acna13.eventbrite.com/?discount=PMC To see what the talks are, including the ones relating to Cassandra, please see the schedule -http://na.apachecon.com/schedule/ Would you like to get more involved in the project? A number of people will be at the (Free!) Hackathon on the Monday. Ours will focus on CQL drivers, but if you would like to learn more about contributing, get some mentoring on a patch, or help collaborate on some fixes, then by all means come join us. If you'd like to come, whether you can make it to the main conference or not, the details are on the ApacheCon wiki: http://wiki.apache.org/apachecon/HackathonNA13 Also talking of free, there will be a BarCamp on the Sunday. This is open to everyone, Portland natives and conference-goers alike, and should be a great chance to share new ideas and learn about existing + upcoming projects. To sign up to come to that, or learn more, it's http://wiki.apache.org/apachecon/BarCampApachePortland Hopefully see some of you in Portland in a few weeks! --- Thanks -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: [VOTE] Release Apache Cassandra 1.1.10
+1 On Tue, Feb 12, 2013 at 9:59 AM, Sylvain Lebresne wrote: > We've fixed our share of bugs since 1.1.9 so I propose the following > artifacts > for release as 1.1.10. > > sha1: 684994215120b2bac4e04f520420e105e21d07c9 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.10-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-226/org/apache/cassandra/apache-cassandra/1.1.10/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-226/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~slebresne/ > > The vote will be open for 72 hours (longer if needed). > > [1]: http://goo.gl/dwPLz (CHANGES.txt) > [2]: http://goo.gl/reKh5 (NEWS.txt) -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: Notes from committer's meeting: overview
On Mon, Feb 25, 2013 at 5:24 PM, Anton Prakash wrote: > unsubscribe apples > On Mon, Feb 25, 2013 at 3:23 PM, Brandon Williams wrote: > >> On Mon, Feb 25, 2013 at 5:19 PM, Edward Capriolo >> wrote: >> > I am curious what you mean when you say "does the fat client work right >> > now?" >> >> It's not often tested. >> >> > What does not work about it? I have a fat client app running same jvm as >> c* >> > it seems to work well. >> >> Good to know. :) >> >> -Brandon >> -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: [VOTE] Release Apache Cassandra 1.2.3
[ Sylvain Lebresne ] > Some important bug fixed since 1.2.2, I propose the following artifacts for > release as 1.2.3. > > sha1: f07804e0d0cf57bc6e1e2924a7b926d55408f640 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.3-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-002/org/apache/cassandra/apache-cassandra/1.2.3/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-002/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~slebresne/ > > The vote will be open for 72 hours (longer if needed). +1 -- Eric Evans eev...@sym-link.com
[VOTE] Release Apache Cassandra 1.1.11
Greets, I propose the following for release as 1.1.11 SHA1: d939a0c958d36a3debfc63364a3fa569aa632c6e Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.11-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-108/org/apache/cassandra/apache-cassandra/1.1.11/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-108/ A Debian package is available here: http://people.apache.org/~eevans The vote will be open for 72 hours (longer if needed). Cheers, [1]: http://goo.gl/QfZlg (CHANGES.txt) [2]: http://goo.gl/O55QF (NEWS.txt) [3]: http://goo.gl/KbiRm (Can't Hug Every Cat) -- Eric Evans eev...@sym-link.com
Re: [VOTE] Release Apache Cassandra 1.1.11
[ Eric Evans ] > I propose the following for release as 1.1.11 > > SHA1: d939a0c958d36a3debfc63364a3fa569aa632c6e > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.1.11-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-108/org/apache/cassandra/apache-cassandra/1.1.11/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-108/ > > A Debian package is available here: http://people.apache.org/~eevans > > The vote will be open for 72 hours (longer if needed). That's 6 +1s (including my own), and no vetoes; The vote passes I will get the artifacts posted, the site updated, and announcement out. Thanks, > [1]: http://goo.gl/QfZlg (CHANGES.txt) > [2]: http://goo.gl/O55QF (NEWS.txt) > [3]: http://goo.gl/KbiRm (Can't Hug Every Cat) -- Eric Evans eev...@sym-link.com
Re: [VOTE] Release Apache Cassandra 2.0.0-beta1
[ Sylvain Lebresne ] > Cassandra 2.0 is coming along but we now need wider testing. So I propose > the > following artifacts for release as 2.0.0-beta1. Let it be clear that it is > only > a beta (and the first one at that), so we know it's not perfect, but the > current goal is first and foremost to get better testing. > > sha1: fcdb39384e8570cf38c027f38b799181da06d56d > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.0-beta1-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-117/org/apache/cassandra/apache-cassandra/2.0.0-beta1/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-117/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~slebresne/ > > The vote will be open for 72 hours (longer if needed). +1 > [1]: http://goo.gl/LorY5 (CHANGES.txt) > [2]: http://goo.gl/zEt5i (NEWS.txt) -- Eric Evans eev...@sym-link.com
Re: Regression in 1.2.7
[ Brandon Williams ] > On Sat, Jul 27, 2013 at 2:39 PM, Jonathan Ellis wrote: > > > The fix for range tombstone performance [1] introduced a regression > > [2] that breaks slice queries against 1.1-format sstables. Running > > upgradesstables is a workaround, but this means that you can't do > > zero-downtime upgrades from 1.1 at CL.ONE. > > > > I think we should withdraw 1.2.7 from the download mirrors and roll > > 1.2.7.1 with the fix. > > > > +1, but I'll bikeshed the version. I'd rather keep the scheme and call it > 1.2.8. If memory serves, we've done this before, this way. Yeah, that's how we've been doing it. Since Sylvain is out, I'll put together some release artifacts and start a new vote presently. Cheers, -- Eric Evans eev...@sym-link.com
[VOTE] Release Apache Cassandra 1.2.8
A regression made its way into 1.2.7 and has since been fixed [2]; I propose the following artifacts for release as 1.2.8. Git SHA1: 0291d696018214000709025c0b806089c2f51e97 Git HTTP: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.8-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-029/org/apache/cassandra/apache-cassandra/1.2.8/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-029 The artifacts as well as the debian package are also available here: http://people.apache.org/~eevans/ Unless anyone objects, I suggest a 24-hour vote. [1]: http://thread.gmane.org/gmane.comp.db.cassandra.devel/7904 [2]: https://issues.apache.org/jira/browse/CASSANDRA-5814 [3]: http://goo.gl/bQ3a4i (CHANGES.txt) [4]: http://goo.gl/Zj1JFa (NEWS.txt) -- Eric Evans eev...@sym-link.com
Re: [VOTE] Release Apache Cassandra 1.2.8
[ Eric Evans ] > Git SHA1: 0291d696018214000709025c0b806089c2f51e97 > Git HTTP: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.8-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-029/org/apache/cassandra/apache-cassandra/1.2.8/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-029 > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~eevans/ > > Unless anyone objects, I suggest a 24-hour vote. I count 5 binding +1s (including mine), and no dissension; The vote passes I'll get the artifacts published presently. > [1]: http://thread.gmane.org/gmane.comp.db.cassandra.devel/7904 > [2]: https://issues.apache.org/jira/browse/CASSANDRA-5814 > [3]: http://goo.gl/bQ3a4i (CHANGES.txt) > [4]: http://goo.gl/Zj1JFa (NEWS.txt) -- Eric Evans eev...@sym-link.com
[VOTE] Release Apache Cassandra 2.0.0 rc1
Sounds like it's that time; I propose the following artifacts for release as 2.0.0 rc1. Git: 2.0.0-rc1-tentative / e8ae672 Gitweb: https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=e8ae672 Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-062/org/apache/cassandra/apache-cassandra/2.0.0-rc1/ Maven repository (staging): https://repository.apache.org/content/repositories/orgapachecassandra-062/ Debian package: http://people.apache.org/~eevans The vote will remain open for 72 hours, (longer if need be). [1]: http://goo.gl/ZRB5aW (CHANGES.txt) [2]: http://goo.gl/h55Zsq (NEWS.txt) -- Eric Evans eev...@sym-link.com
Re: CQL or Thrift ?
[ Nulik Nol ] > I need a client in C (not C++) to work with Cassandra, so since there > is no one yet I would do my own. So far I have checked, I can do it > through Thrift RPC port, or through CQL port. As I understand, CQL > doesn't support direct "mutate" or "get_range_slices" calls like > Thrift does , so being Thrift API more low level, it should be faster > for specific queries my application would execute. The question is, > what do you recommend me to use, Thrift or CQL3 native protocol? Performance is likely to be the least important consideration when comparing the two, but luckily we don't have to have that argument; CQL is actually faster. -- Eric Evans eev...@sym-link.com
