Re: Supporting multiple JDKs
I really don't see any benefit at all in having any additional Java 1.7 specific build and testing changes for the 2.2 branch. The 2.2 version is reaching EOL and will only get critical patches until then anyways. I also can't remember any reports on regressions in 2.2 bug fix releases specific to 1.7. So what's the actual problem we want to solve here? As for 4.0, we're going to ship multi-release jars, which are targeted against Java 8, but also contain Java 11 classes that will only be used when executed under Java 11 (also currently just a single class). I can see two issues that need our attention with that: * We should make sure to use the "_build_multi_java" target for our CI jobs, so we're really testing the same build that we would ship. It's probably not going to make a real difference, but who knows.. * It would also be nice to have the option to run tests on CI under Java 11, although we only provide "experimental" support for that Java version. Nice to have at this point, as there will be plenty of bugs in 4.0 to fix, until we should spend time looking more closely for more subtle Java 11 issues. But if someone wants to contribute any work to make this happen, I'd be glad to have that option running tests on Java 11, so don't get me wrong. On 07.09.18 04:10, Sumanth Pasupuleti wrote: >> And I would suggest to go further and crash the build with JDK1.7 so we > can take away the possibility for users to shoot their foot off this way. > > I like this suggestion. Either we should be on the side of NO support to > JDK 1.7, or if we say we support JDK1.7, I believe we should be building > against JDK1.7 to make sure we are compliant. > I have a quick clarifying question here - I believe origin of > CASSANDRA-14563 is from the introduction of an API in 2.2 that is > incompatible with 1.7, that has then been manually detected and fixed. Are > you suggesting, going further, we would not support 1.7? > >> Currently I'm unclear on how we would make a stable release using only > JDK8, maybe their are plans on the table i don't know about? > > From the current state of build.xml and from the past discussions, I do > believe as well, that we need both JDKs to make a 4.0 release using > ‘_build_multi_java’. Bonus would be that, the release would also be able to > run against Java11, but that would be an experimental release. > >> I'm not familiar with optional jobs or workflows in CircleCi, do you have > an example of what you mean at hand? > > By optional, I was referring to having workflow definitions in place, but > calls to those workflows commented out. Basically similar to what we have > today. > workflows: > version: 2 > build_and_run_tests: *default_jobs > #build_and_run_tests: *with_dtest_jobs_only > #build_and_run_tests_java11: *with_dtest_jobs_java11 > Jason created CASSANDRA-14609 for this purpose I believe. > >> Off-topic, but what are your thoughts on this? Can we add `ant > artifacts`, and the building of the docs, as a separate jobs into the > existing default CircleCI workflow? I think we should also be looking into > getting https://cassandra.apache.org/doc/latest/ automatically updated > after each successful trunk build, and have > https://cassandra.apache.org/doc/X.Y versions on the docs in place (which > are only updated after each patch release). > > I like all these ideas! I believe we should be able to add a workflow to > test out artifact generation. Will create a JIRA for this. Your suggestions > around auto-update of docs provides a way to keep our website docs > up-to-date. Not sure what it takes to do it though. Will be happy to > explore (as part of separate JIRAs). > > Thanks, > Sumanth > - 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 Fri, Sep 7, 2018 at 10:00 PM Blake Eggleston wrote: > > Right, I understand the arguments for starting a new project. I’m not saying > reaper is, technically speaking, the best place to start. The point I’m > trying to make is that the non-technical advantages of using an existing > project as a starting point may outweigh the technical benefits of a clean > slate. Whether that’s the case or not, it’s not a strictly technical > decision, and the non-technical advantages of starting with reaper need to be > weighed. > Technical debt doesn't just refer to the technical solutions, having an existing user base means that a project has made promises in the past (in the case of Priam 5+ years ago) that the new project would have to keep if we make keeping users of those sidecars a goal (which for the record I don't think should be a goal, I think the goal is to make Cassandra the database work out of the box in the 4.x series). For example, Priam has to continue supporting the following as users actively use them (including Netflix): * Parallel token assignment and creation allowing parallel bootstrap and parallel doubling of hundred node clusters at once (as long as you use single tokens and run in AWS with asgs). * 3+ backup solutions, as well as assumptions about where in e.g. S3 backups are present and what format they're present in. * Numerous configuration options and UI elements (mostly 5 year old JSON APIs) * Support for Cassandra 2.0, 2.1, 2.2, 3.0, 3.11 and soon 4.0 Reaper has to continue supporting the following as users actively use them: * Postgres and h2 storage backends. These were the original storage engines and users may not have (probably haven't?) migrated to the relatively recently added Cassandra backend (which is probably the only one an official sidecar should support imo). * The three historical modes of running Reaper [1] all of which involve remote JMX (disallowed by many companies security policies including Netflix's) and none of which are a sidecar design (although Mick says we can add that back in, at which point it has to support four). * Numerous configuration options and UI elements (e.g. a UI around a single Reaper instance controlling many Cassandra clusters instead of each cluster having a separate UI more consistent with how Cassandra architecture works) * Support for Cassandra 2.2, 3.0, 3.11, and soon 4.0 [1] http://cassandra-reaper.io/docs/usage/multi_dc/ [2] https://github.com/hashbrowncipher/cassandra-mirror We can't "get the community" of these sidecars and drop support for 90+% of the supported configurations and features at the same time ... These projects have made promises to users, as per the name technical debt these choices made over years have explicit costs that we have to take into account if we accept a project as is with the goal of taking the community with us. If we don't have the goal of taking the existing community with us and are instead aiming to simply make Cassandra work out of the box without external tools, then we don't have to continue fulfilling these promises. Instead I think the organizations that made those promises (TLP and Netflix in these specific cases) should continue keeping them, and the Cassandra management process should be incrementally built by the Cassandra community with decisions made as a community and we only GA it when the PMC/community is happy with making a promise of support for the features that we've merged (and since we're starting from a fresh start if people have strong opinions about fundamental architecture we can try to take those into account like we did with the months of feedback on repair scheduling runtime/architecture/design). If we can't prove value over other community tools for running 4.x, which is definitely a possibility, then we don't mark the management process GA, we re-focus on individual community tools, and imo failure is a reasonable result of attempted innovation. -Joey - 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
Most of the discussions have been around whether we take some side car or do a cherry pick approach where we add a feature at a time to side car and use the best implementation. We have been discussing this first in April and now for several days. I think we all want some progress here. We will start a vote soon..may be next week to decide which approach we will take. I don't see any other option to make progress besides a vote!! PS: I think these discussions are very good for the community and it shows people care about Apache Cassandra and it is a sign of healthy community. Several people offering to donate the side car or help build is showing the interest everyone has in it. On Sat, Sep 8, 2018 at 11:17 AM Joseph Lynch wrote: > On Fri, Sep 7, 2018 at 10:00 PM Blake Eggleston > wrote: > > > > Right, I understand the arguments for starting a new project. I’m not > saying reaper is, technically speaking, the best place to start. The point > I’m trying to make is that the non-technical advantages of using an > existing project as a starting point may outweigh the technical benefits of > a clean slate. Whether that’s the case or not, it’s not a strictly > technical decision, and the non-technical advantages of starting with > reaper need to be weighed. > > > > Technical debt doesn't just refer to the technical solutions, having > an existing user base means that a project has made promises in the > past (in the case of Priam 5+ years ago) that the new project would > have to keep if we make keeping users of those sidecars a goal (which > for the record I don't think should be a goal, I think the goal is to > make Cassandra the database work out of the box in the 4.x series). > > For example, Priam has to continue supporting the following as users > actively use them (including Netflix): > * Parallel token assignment and creation allowing parallel bootstrap > and parallel doubling of hundred node clusters at once (as long as you > use single tokens and run in AWS with asgs). > * 3+ backup solutions, as well as assumptions about where in e.g. S3 > backups are present and what format they're present in. > * Numerous configuration options and UI elements (mostly 5 year old JSON > APIs) > * Support for Cassandra 2.0, 2.1, 2.2, 3.0, 3.11 and soon 4.0 > > Reaper has to continue supporting the following as users actively use them: > * Postgres and h2 storage backends. These were the original storage > engines and users may not have (probably haven't?) migrated to the > relatively recently added Cassandra backend (which is probably the > only one an official sidecar should support imo). > * The three historical modes of running Reaper [1] all of which > involve remote JMX (disallowed by many companies security policies > including Netflix's) and none of which are a sidecar design (although > Mick says we can add that back in, at which point it has to support > four). > * Numerous configuration options and UI elements (e.g. a UI around a > single Reaper instance controlling many Cassandra clusters instead of > each cluster having a separate UI more consistent with how Cassandra > architecture works) > * Support for Cassandra 2.2, 3.0, 3.11, and soon 4.0 > > [1] http://cassandra-reaper.io/docs/usage/multi_dc/ > [2] https://github.com/hashbrowncipher/cassandra-mirror > > We can't "get the community" of these sidecars and drop support for > 90+% of the supported configurations and features at the same time ... > These projects have made promises to users, as per the name technical > debt these choices made over years have explicit costs that we have to > take into account if we accept a project as is with the goal of taking > the community with us. If we don't have the goal of taking the > existing community with us and are instead aiming to simply make > Cassandra work out of the box without external tools, then we don't > have to continue fulfilling these promises. > > Instead I think the organizations that made those promises (TLP and > Netflix in these specific cases) should continue keeping them, and the > Cassandra management process should be incrementally built by the > Cassandra community with decisions made as a community and we only GA > it when the PMC/community is happy with making a promise of support > for the features that we've merged (and since we're starting from a > fresh start if people have strong opinions about fundamental > architecture we can try to take those into account like we did with > the months of feedback on repair scheduling > runtime/architecture/design). If we can't prove value over other > community tools for running 4.x, which is definitely a possibility, > then we don't mark the management process GA, we re-focus on > individual community tools, and imo failure is a reasonable result of > attempted innovation. > > -Joey > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional com
NEQ-restriction in select-where clause
Hello. Does it make sense to implement != restriction in select-where clause? Is it possible? Thank you. PS. I want to implement that. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
