Re: Design Proposal for Auditing feature in Cassandra

[Dinesh Joshi]

Hey Anuj,
Thanks for submitting the patch. I am looking at the design. Will comment on 
the Jira with my feedback.
Dinesh 

On Monday, February 26, 2018, 4:09:41 AM PST, Anuj Wadehra 
 wrote:  
 
 Hi,
Apache Cassandra doesn't provides an auditing feature. As Database auditing is 
critical for any production level database like Apache Cassandra, our team is 
keen on designing & implementing this feature in Apache Cassandra. 
I have submitted the Design proposal for "Database Auditing" feature under the 
JIRA: https://issues.apache.org/jira/browse/CASSANDRA-12151 . Can some of you 
please review the proposal and share your feedback?


ThanksAnuj

  

Timeout unit tests in trunk

[Dikang Gu]

Looks like there are a few flaky/timeout unit tests in trunk, wondering is
there anyone looking at them already?

testBuildRange - org.apache.cassandra.db.view.ViewBuilderTaskTest
testUnloggedPartitionsPerBatch -
org.apache.cassandra.metrics.BatchMetricsTest
testViewBuilderResume - org.apache.cassandra.cql3.ViewTest

https://circleci.com/gh/DikangGu/cassandra/20

-- 
Dikang

Re: Design Proposal for Auditing feature in Cassandra

[Vinay Kumar Chella]

Hi Anuj,

Thanks for the detailed design document. We had a similar requirement
recently for our internal 2.1 clusters and we implemented a simple version
(no "Separate Configuration for Whitelisted Users" etc…) for sox auditing.
As your design is very close to what we implemented, just a few differently
named classes, for the most part, I updated our patch for trunk
 and put it out there
for reviewing it. We could take an incremental approach, review what we
have on the trunk branch of the simple version and then add in some of the
more advanced features next. I believe this patch follows the design goals
that you put together.

Please review and let me know if you have any questions or concerns about
the first iteration. If folks are interested in the 3.x/2.x branches I can
put those up on my github as well.

@Dinesh,

Thanks in advance for your time in reviewing it.


Thanks,
Vinay Chella



Thanks,
Vinay Chella

On Mon, Feb 26, 2018 at 11:56 PM, Dinesh Joshi <
dinesh.jo...@yahoo.com.invalid> wrote:

> Hey Anuj,
> Thanks for submitting the patch. I am looking at the design. Will comment
> on the Jira with my feedback.
> Dinesh
>
> On Monday, February 26, 2018, 4:09:41 AM PST, Anuj Wadehra <
> anujw_2...@yahoo.co.in.INVALID> wrote:
>
>  Hi,
> Apache Cassandra doesn't provides an auditing feature. As Database
> auditing is critical for any production level database like Apache
> Cassandra, our team is keen on designing & implementing this feature in
> Apache Cassandra.
> I have submitted the Design proposal for "Database Auditing" feature under
> the JIRA: https://issues.apache.org/jira/browse/CASSANDRA-12151 . Can
> some of you please review the proposal and share your feedback?
>
>
> ThanksAnuj
>
>
>

Re: Timeout unit tests in trunk

[Dinesh Joshi]

Some tests might require additional resources to spin up the required 
components. 2 CPU / 4GB might not be sufficient. You may need to bump up the 
resources to 8CPU / 16GB.
Dinesh 

On Tuesday, February 27, 2018, 11:24:34 AM PST, Dikang Gu 
 wrote:  
 
 Looks like there are a few flaky/timeout unit tests in trunk, wondering is
there anyone looking at them already?

testBuildRange - org.apache.cassandra.db.view.ViewBuilderTaskTest
testUnloggedPartitionsPerBatch -
org.apache.cassandra.metrics.BatchMetricsTest
testViewBuilderResume - org.apache.cassandra.cql3.ViewTest

https://circleci.com/gh/DikangGu/cassandra/20

-- 
Dikang
  

Re: Timeout unit tests in trunk

[Michael Kjellman]

hey dikang: just chatted a little bit about this. proposal: let's add the 
equivalent of @resource_intensive to unit tests too.. and the first one is to 
stop from running the MV unit tests in the free circleci containers. thoughts?

also, might want to bug your management to see if you can get some paid 
circleci resources. it's game changing!

best,
kjellman

> On Feb 27, 2018, at 12:12 PM, Dinesh Joshi  
> wrote:
> 
> Some tests might require additional resources to spin up the required 
> components. 2 CPU / 4GB might not be sufficient. You may need to bump up the 
> resources to 8CPU / 16GB.
> Dinesh 
> 
>On Tuesday, February 27, 2018, 11:24:34 AM PST, Dikang Gu 
>  wrote:  
> 
> Looks like there are a few flaky/timeout unit tests in trunk, wondering is
> there anyone looking at them already?
> 
> testBuildRange - org.apache.cassandra.db.view.ViewBuilderTaskTest
> testUnloggedPartitionsPerBatch -
> org.apache.cassandra.metrics.BatchMetricsTest
> testViewBuilderResume - org.apache.cassandra.cql3.ViewTest
> 
> https://circleci.com/gh/DikangGu/cassandra/20
> 
> -- 
> Dikang


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

Re: Timeout unit tests in trunk

[Michael Kjellman]

well, turns out we already have a jira tracking the MV tests being broken on 
trunk. they are legit broken :) thanks jaso

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

not sure about the batch test timeout there though.. did you debug it at all by 
chance?


On Feb 27, 2018, at 1:27 PM, Michael Kjellman 
mailto:kjell...@apple.com>> wrote:

hey dikang: just chatted a little bit about this. proposal: let's add the 
equivalent of @resource_intensive to unit tests too.. and the first one is to 
stop from running the MV unit tests in the free circleci containers. thoughts?

also, might want to bug your management to see if you can get some paid 
circleci resources. it's game changing!

best,
kjellman

On Feb 27, 2018, at 12:12 PM, Dinesh Joshi 
mailto:dinesh.jo...@yahoo.com.INVALID>> wrote:

Some tests might require additional resources to spin up the required 
components. 2 CPU / 4GB might not be sufficient. You may need to bump up the 
resources to 8CPU / 16GB.
Dinesh

  On Tuesday, February 27, 2018, 11:24:34 AM PST, Dikang Gu 
mailto:dikan...@gmail.com>> wrote:

Looks like there are a few flaky/timeout unit tests in trunk, wondering is
there anyone looking at them already?

testBuildRange - org.apache.cassandra.db.view.ViewBuilderTaskTest
testUnloggedPartitionsPerBatch -
org.apache.cassandra.metrics.BatchMetricsTest
testViewBuilderResume - org.apache.cassandra.cql3.ViewTest

https://circleci.com/gh/DikangGu/cassandra/20

--
Dikang


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

Re: Expensive metrics?

[Nate McCall]

Hi Micke,
There is some good research in here - have you had a chance to create
some issues in Jira from this?

On Fri, Feb 23, 2018 at 6:28 AM, Michael Burman  wrote:
> Hi,
>
> I was referring to this article by Shipilev (there are few small issues
> forgotten in that url you pasted):
>
> https://shipilev.net/blog/2014/nanotrusting-nanotime/
>
> And his lovely recommendation on it: "System.nanoTime is as bad as
> String.intern now: you can use it, but use it wisely. ". And Cassandra uses
> it quite a lot in the write path at least. There isn't necessarily a better
> option in Java for it, but for that reason we shouldn't push them everywhere
> in the code "for fun".
>
>   - Micke
>
>
>
> On 02/22/2018 06:08 PM, Jeremiah D Jordan wrote:
>>
>> re: nanoTime vs currentTimeMillis there is a good blog post here about the
>> timing of both and how your choice of Linux clock source can drastically
>> effect the speed of the calls, and also showing that in general on linux
>> there is no perf improvement for one over the other.
>> http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html
>>
>>> On Feb 22, 2018, at 11:01 AM, Blake Eggleston 
>>> wrote:
>>>
>>> Hi Micke,
>>>
>>> This is really cool, thanks for taking the time to investigate this. I
>>> believe the metrics around memtable insert time come in handy in identifying
>>> high partition contention in the memtable. I know I've been involved in a
>>> situation over the past year where we got actionable info from this metric.
>>> Reducing resolution to milliseconds is probably a no go since most things in
>>> this path should complete in less than a millisecond.
>>>
>>> Revisiting the use of the codahale metrics in the hot path like this
>>> definitely seems like a good idea though. I don't think it's been something
>>> we've talked about a lot, and it definitely looks like we could benefit from
>>> using something more specialized here. I think it's worth doing, especially
>>> since there won't be any major changes to how we do threading in 4.0. It's
>>> probably also worth opening a JIRA and investigating the calls to nano time.
>>> We at least need microsecond resolution here, and there could be something
>>> we haven't thought of? It's worth a look at least.
>>>
>>> Thanks,
>>>
>>> Blake
>>>
>>> On 2/22/18, 6:10 AM, "Michael Burman"  wrote:
>>>
>>> Hi,
>>>
>>> I wanted to get some input from the mailing list before making a JIRA
>>> and potential fixes. I'll touch the performance more on latter part,
>>> but
>>> there's one important question regarding the write latency metric
>>> recording place. Currently we measure the writeLatency (and metric
>>> write
>>> sampler..) in ColumnFamilyStore.apply() and this is also the metric
>>> we
>>> then replicate to Keyspace metrics etc.
>>>
>>> This is an odd place for writeLatency. Not to mention it is in a
>>> hot-path of Memtable-modifications, but it also does not measure the
>>> real write latency, since it completely ignores the CommitLog latency
>>> in
>>> that same process. Is the intention really to measure
>>> Memtable-modification latency only or the actual write latencies?
>>>
>>> Then the real issue.. this single metric is a cause of huge overhead
>>> in
>>> Memtable processing. There are several metrics / events in the CFS
>>> apply
>>> method, including metric sampler, storageHook reportWrite,
>>> colUpdateTimeDeltaHistogram and metric.writeLatency. These are not
>>> free
>>> at all when it comes to the processing. I made a small JMH benchmark
>>> here:
>>> https://gist.github.com/burmanm/b5b284bc9f1d410b1d635f6d3dac3ade
>>> that I'll be referring to.
>>>
>>> The most offending of all these metrics is the writeLatency metric.
>>> What
>>> it does is update the latency in codahale's timer, doing a histogram
>>> update and then going through all the parent metrics also which
>>> update
>>> the keyspace writeLatency and globalWriteLatency. When measuring the
>>> performance of Memtable.put with parameter of 1 partition (to reduce
>>> the
>>> ConcurrentSkipListMap search speed impact - that's separate issue and
>>> takes a little bit longer to solve although I've started to prototype
>>> something..) on my machine I see 1.3M/s performance with the metric
>>> and
>>> when it is disabled the performance climbs to 4M/s. So the overhead
>>> for
>>> this single metric is ~2/3 of total performance. That's insane. My
>>> perf
>>> stats indicate that the CPU is starved as it can't get enough data
>>> in.
>>>
>>> Removing the replication from TableMetrics to the Keyspace & global
>>> latencies in the write time (and doing this when metrics are
>>> requested
>>> instead) improves the performance to 2.1M/s on my machine. It's an
>>> improvement, but it's still huge amount. Even when we pressure the
>>> ConcurrentSkipListMap with 100 000 partitions in one active Memt

Re: Timeout unit tests in trunk

[Dikang Gu]

I took some look at the cql3.ViewTest, it seems too big and timeout very
often. Any objections if I split it into two or multiple tests?

On Tue, Feb 27, 2018 at 1:32 PM, Michael Kjellman 
wrote:

> well, turns out we already have a jira tracking the MV tests being broken
> on trunk. they are legit broken :) thanks jaso
>
> https://issues.apache.org/jira/browse/CASSANDRA-14194
>
> not sure about the batch test timeout there though.. did you debug it at
> all by chance?
>
>
> On Feb 27, 2018, at 1:27 PM, Michael Kjellman  kjell...@apple.com>> wrote:
>
> hey dikang: just chatted a little bit about this. proposal: let's add the
> equivalent of @resource_intensive to unit tests too.. and the first one is
> to stop from running the MV unit tests in the free circleci containers.
> thoughts?
>
> also, might want to bug your management to see if you can get some paid
> circleci resources. it's game changing!
>
> best,
> kjellman
>
> On Feb 27, 2018, at 12:12 PM, Dinesh Joshi  INVALID> wrote:
>
> Some tests might require additional resources to spin up the required
> components. 2 CPU / 4GB might not be sufficient. You may need to bump up
> the resources to 8CPU / 16GB.
> Dinesh
>
>   On Tuesday, February 27, 2018, 11:24:34 AM PST, Dikang Gu <
> dikan...@gmail.com> wrote:
>
> Looks like there are a few flaky/timeout unit tests in trunk, wondering is
> there anyone looking at them already?
>
> testBuildRange - org.apache.cassandra.db.view.ViewBuilderTaskTest
> testUnloggedPartitionsPerBatch -
> org.apache.cassandra.metrics.BatchMetricsTest
> testViewBuilderResume - org.apache.cassandra.cql3.ViewTest
>
> https://circleci.com/gh/DikangGu/cassandra/20
>
> --
> Dikang
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org unsubscr...@cassandra.apache.org>
> For additional commands, e-mail: dev-h...@cassandra.apache.org dev-h...@cassandra.apache.org>
>
>
>


-- 
Dikang

Fwd: Action Required: We are sunsetting CircleCI 1.0 on August 31, 2018

[Michael Kjellman]

FYI: we're already fully on circleci 2.0 for the 3.0, 3.11, and trunk branches 
so no action required for us here!

best,
kjellman

Begin forwarded message:

From: The CircleCI Team mailto:no-re...@circleci.com>>
Subject: Action Required: We are sunsetting CircleCI 1.0 on August 31, 2018
Date: February 27, 2018 at 2:44:01 PM PST
To: mkjell...@internalcircle.com
Reply-To: mailto:no-re...@circleci.com>>


Dear customer,

We wanted to let you know that we are planning on sunsetting CircleCI 1.0 on 
August 31st, 2018. Our goal as a company for 2018 is to invest in delivering 
more features and better performance on CircleCI 2.0, which unlocks faster 
builds and greater control. For more information, you can read our blog 
post on sunsetting CircleCI 1.0.

You’ll need to update all of your config files to the CircleCI 2.0 syntax in 
order to migrate your projects to CircleCI 2.0 over the next 6 months.

If all of your projects are already on 2.0, congratulations! No action is 
necessary. We are sending this announcement to all active users to make sure 
you have all of the information you need. Take a look at your builds 
dashboard to see if your 
projects are still building on CircleCI 1.0:

[https://www2.circleci.com/rs/485-ZMH-626/images/CircleCI%20Version%20Number.png]


These resources will help you get migrate your projects from 1.0 to 2.0:

Config.yml 
translator.
 Note: This will generate a baseline config.yml file that you can adjust to fit 
your needs.
1.0 to 2.0 migration 
documentation.
Language-specific 2.0 tutorials.

We will be sending you email reminders periodically with additional resources 
and links as they become available to help with your migration plan. We will 
also be updating this page with 
information relevant to sunsetting CircleCI 1.0. If you need additional 
migration assistance, open a support 
request and our support team 
will be in touch.


Cheers,

The CircleCI Team

Re: Timeout unit tests in trunk

[Michael Kjellman]

i've seen it timeout a lot too. if you think breaking it up will fix it that 
definitely sounds like a good approach!

> On Feb 27, 2018, at 2:57 PM, Dikang Gu  wrote:
> 
> I took some look at the cql3.ViewTest, it seems too big and timeout very
> often. Any objections if I split it into two or multiple tests?
> 
> On Tue, Feb 27, 2018 at 1:32 PM, Michael Kjellman 
> wrote:
> 
>> well, turns out we already have a jira tracking the MV tests being broken
>> on trunk. they are legit broken :) thanks jaso
>> 
>> https://issues.apache.org/jira/browse/CASSANDRA-14194
>> 
>> not sure about the batch test timeout there though.. did you debug it at
>> all by chance?
>> 
>> 
>> On Feb 27, 2018, at 1:27 PM, Michael Kjellman > kjell...@apple.com>> wrote:
>> 
>> hey dikang: just chatted a little bit about this. proposal: let's add the
>> equivalent of @resource_intensive to unit tests too.. and the first one is
>> to stop from running the MV unit tests in the free circleci containers.
>> thoughts?
>> 
>> also, might want to bug your management to see if you can get some paid
>> circleci resources. it's game changing!
>> 
>> best,
>> kjellman
>> 
>> On Feb 27, 2018, at 12:12 PM, Dinesh Joshi > INVALID> wrote:
>> 
>> Some tests might require additional resources to spin up the required
>> components. 2 CPU / 4GB might not be sufficient. You may need to bump up
>> the resources to 8CPU / 16GB.
>> Dinesh
>> 
>>  On Tuesday, February 27, 2018, 11:24:34 AM PST, Dikang Gu <
>> dikan...@gmail.com> wrote:
>> 
>> Looks like there are a few flaky/timeout unit tests in trunk, wondering is
>> there anyone looking at them already?
>> 
>> testBuildRange - org.apache.cassandra.db.view.ViewBuilderTaskTest
>> testUnloggedPartitionsPerBatch -
>> org.apache.cassandra.metrics.BatchMetricsTest
>> testViewBuilderResume - org.apache.cassandra.cql3.ViewTest
>> 
>> https://circleci.com/gh/DikangGu/cassandra/20
>> 
>> --
>> Dikang
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org> unsubscr...@cassandra.apache.org>
>> For additional commands, e-mail: dev-h...@cassandra.apache.org> dev-h...@cassandra.apache.org>
>> 
>> 
>> 
> 
> 
> -- 
> Dikang


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

Re: Timeout unit tests in trunk

[Dinesh Joshi]

Yes, give it a go. I am not 100% sure if it will help a whole lot but try it 
out and let's see what happens!
Dinesh 

On Tuesday, February 27, 2018, 2:57:41 PM PST, Dikang Gu 
 wrote:  
 
 I took some look at the cql3.ViewTest, it seems too big and timeout very
often. Any objections if I split it into two or multiple tests?

On Tue, Feb 27, 2018 at 1:32 PM, Michael Kjellman 
wrote:

> well, turns out we already have a jira tracking the MV tests being broken
> on trunk. they are legit broken :) thanks jaso
>
> https://issues.apache.org/jira/browse/CASSANDRA-14194
>
> not sure about the batch test timeout there though.. did you debug it at
> all by chance?
>
>
> On Feb 27, 2018, at 1:27 PM, Michael Kjellman  kjell...@apple.com>> wrote:
>
> hey dikang: just chatted a little bit about this. proposal: let's add the
> equivalent of @resource_intensive to unit tests too.. and the first one is
> to stop from running the MV unit tests in the free circleci containers.
> thoughts?
>
> also, might want to bug your management to see if you can get some paid
> circleci resources. it's game changing!
>
> best,
> kjellman
>
> On Feb 27, 2018, at 12:12 PM, Dinesh Joshi  INVALID> wrote:
>
> Some tests might require additional resources to spin up the required
> components. 2 CPU / 4GB might not be sufficient. You may need to bump up
> the resources to 8CPU / 16GB.
> Dinesh
>
>  On Tuesday, February 27, 2018, 11:24:34 AM PST, Dikang Gu <
> dikan...@gmail.com> wrote:
>
> Looks like there are a few flaky/timeout unit tests in trunk, wondering is
> there anyone looking at them already?
>
> testBuildRange - org.apache.cassandra.db.view.ViewBuilderTaskTest
> testUnloggedPartitionsPerBatch -
> org.apache.cassandra.metrics.BatchMetricsTest
> testViewBuilderResume - org.apache.cassandra.cql3.ViewTest
>
> https://circleci.com/gh/DikangGu/cassandra/20
>
> --
> Dikang
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org unsubscr...@cassandra.apache.org>
> For additional commands, e-mail: dev-h...@cassandra.apache.org dev-h...@cassandra.apache.org>
>
>
>


-- 
Dikang
  

Re: Action Required: We are sunsetting CircleCI 1.0 on August 31, 2018

[kurt greaves]

Not that much gets committed to 2.1 and 2.2 anymore, but is this also true
for those branches?

On 27 February 2018 at 22:58, Michael Kjellman  wrote:

> FYI: we're already fully on circleci 2.0 for the 3.0, 3.11, and trunk
> branches so no action required for us here!
>
> best,
> kjellman
>
> Begin forwarded message:
>
> From: The CircleCI Team  no-re...@circleci.com>>
> Subject: Action Required: We are sunsetting CircleCI 1.0 on August 31, 2018
> Date: February 27, 2018 at 2:44:01 PM PST
> To: mkjell...@internalcircle.com
> Reply-To: mailto:no-re...@circleci.com>>
>
>
> Dear customer,
>
> We wanted to let you know that we are planning on sunsetting CircleCI 1.0
> on August 31st, 2018. Our goal as a company for 2018 is to invest in
> delivering more features and better performance on CircleCI 2.0, which
> unlocks faster builds and greater control. For more information, you can
> read our blog post on
> sunsetting CircleCI 1.0.
>
> You’ll need to update all of your config files to the CircleCI 2.0 syntax
> in order to migrate your projects to CircleCI 2.0 over the next 6 months.
>
> If all of your projects are already on 2.0, congratulations! No action is
> necessary. We are sending this announcement to all active users to make
> sure you have all of the information you need. Take a look at your builds
> dashboard to see if your
> projects are still building on CircleCI 1.0:
>
> [https://www2.circleci.com/rs/485-ZMH-626/images/CircleCI%
> 20Version%20Number.png]
>
>
> These resources will help you get migrate your projects from 1.0 to 2.0:
>
> Config.yml translator.<
> http://go.circleci.com/ZMkaU018240m720GHZ0> Note: This will generate
> a baseline config.yml file that you can adjust to fit your needs.
> 1.0 to 2.0 migration documentation. X2G0U9M0k000H0am4021Z80>
> Language-specific 2.0 tutorials. com/Q00H0mM0Z92G40k1200aaU0>
>
> We will be sending you email reminders periodically with additional
> resources and links as they become available to help with your migration
> plan. We will also be updating this page ga0makG04201MH02Z000b0U> with information relevant to sunsetting CircleCI
> 1.0. If you need additional migration assistance, open a support request<
> http://go.circleci.com/R00Gam1M420020U0ZbH0ck0> and our support team will
> be in touch.
>
>
> Cheers,
>
> The CircleCI Team
>
>
>
>
>

Re: Action Required: We are sunsetting CircleCI 1.0 on August 31, 2018

[Michael Kjellman]

2.2: yes
2.1: no.

i don't think it's worth the effort to get it working on 2.1 at this point -- 
and i hope we've fully moved on from 2.1 by August 31, 2018 ;)

> On Feb 27, 2018, at 5:35 PM, kurt greaves  wrote:
> 
> Not that much gets committed to 2.1 and 2.2 anymore, but is this also true
> for those branches?
> 
> On 27 February 2018 at 22:58, Michael Kjellman  wrote:
> 
>> FYI: we're already fully on circleci 2.0 for the 3.0, 3.11, and trunk
>> branches so no action required for us here!
>> 
>> best,
>> kjellman
>> 
>> Begin forwarded message:
>> 
>> From: The CircleCI Team > no-re...@circleci.com>>
>> Subject: Action Required: We are sunsetting CircleCI 1.0 on August 31, 2018
>> Date: February 27, 2018 at 2:44:01 PM PST
>> To: mkjell...@internalcircle.com
>> Reply-To: mailto:no-re...@circleci.com>>
>> 
>> 
>> Dear customer,
>> 
>> We wanted to let you know that we are planning on sunsetting CircleCI 1.0
>> on August 31st, 2018. Our goal as a company for 2018 is to invest in
>> delivering more features and better performance on CircleCI 2.0, which
>> unlocks faster builds and greater control. For more information, you can
>> read our blog post on
>> sunsetting CircleCI 1.0.
>> 
>> You’ll need to update all of your config files to the CircleCI 2.0 syntax
>> in order to migrate your projects to CircleCI 2.0 over the next 6 months.
>> 
>> If all of your projects are already on 2.0, congratulations! No action is
>> necessary. We are sending this announcement to all active users to make
>> sure you have all of the information you need. Take a look at your builds
>> dashboard to see if your
>> projects are still building on CircleCI 1.0:
>> 
>> [https://www2.circleci.com/rs/485-ZMH-626/images/CircleCI%
>> 20Version%20Number.png]
>> 
>> 
>> These resources will help you get migrate your projects from 1.0 to 2.0:
>> 
>> Config.yml translator.<
>> http://go.circleci.com/ZMkaU018240m720GHZ0> Note: This will generate
>> a baseline config.yml file that you can adjust to fit your needs.
>> 1.0 to 2.0 migration documentation.> X2G0U9M0k000H0am4021Z80>
>> Language-specific 2.0 tutorials.> com/Q00H0mM0Z92G40k1200aaU0>
>> 
>> We will be sending you email reminders periodically with additional
>> resources and links as they become available to help with your migration
>> plan. We will also be updating this page> ga0makG04201MH02Z000b0U> with information relevant to sunsetting CircleCI
>> 1.0. If you need additional migration assistance, open a support request<
>> http://go.circleci.com/R00Gam1M420020U0ZbH0ck0> and our support team will
>> be in touch.
>> 
>> 
>> Cheers,
>> 
>> The CircleCI Team
>> 
>> 
>> 
>> 
>> 

Re: Timeout unit tests in trunk

[Jason Brown]

All,

As @kjellman pointed out, the timeouts on ViewTest & ViewBuilderTaskTest
are being addressed in CASSANDRA-14194
 (I have a patch,
almost ready to release).

@dikang if you want to refactor those tests for fun, go for it - but note
that the timeouts are currently not due to size.

I have no idea about the BatchMetricsTest, but I can see if it is related
to the others. @dikang, Do you have any details to share about the
failures?

-Jason

On Tue, Feb 27, 2018 at 5:16 PM, Dinesh Joshi <
dinesh.jo...@yahoo.com.invalid> wrote:

> Yes, give it a go. I am not 100% sure if it will help a whole lot but try
> it out and let's see what happens!
> Dinesh
>
> On Tuesday, February 27, 2018, 2:57:41 PM PST, Dikang Gu <
> dikan...@gmail.com> wrote:
>
>  I took some look at the cql3.ViewTest, it seems too big and timeout very
> often. Any objections if I split it into two or multiple tests?
>
> On Tue, Feb 27, 2018 at 1:32 PM, Michael Kjellman 
> wrote:
>
> > well, turns out we already have a jira tracking the MV tests being broken
> > on trunk. they are legit broken :) thanks jaso
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-14194
> >
> > not sure about the batch test timeout there though.. did you debug it at
> > all by chance?
> >
> >
> > On Feb 27, 2018, at 1:27 PM, Michael Kjellman   > kjell...@apple.com>> wrote:
> >
> > hey dikang: just chatted a little bit about this. proposal: let's add the
> > equivalent of @resource_intensive to unit tests too.. and the first one
> is
> > to stop from running the MV unit tests in the free circleci containers.
> > thoughts?
> >
> > also, might want to bug your management to see if you can get some paid
> > circleci resources. it's game changing!
> >
> > best,
> > kjellman
> >
> > On Feb 27, 2018, at 12:12 PM, Dinesh Joshi  > INVALID> wrote:
> >
> > Some tests might require additional resources to spin up the required
> > components. 2 CPU / 4GB might not be sufficient. You may need to bump up
> > the resources to 8CPU / 16GB.
> > Dinesh
> >
> >  On Tuesday, February 27, 2018, 11:24:34 AM PST, Dikang Gu <
> > dikan...@gmail.com> wrote:
> >
> > Looks like there are a few flaky/timeout unit tests in trunk, wondering
> is
> > there anyone looking at them already?
> >
> > testBuildRange - org.apache.cassandra.db.view.ViewBuilderTaskTest
> > testUnloggedPartitionsPerBatch -
> > org.apache.cassandra.metrics.BatchMetricsTest
> > testViewBuilderResume - org.apache.cassandra.cql3.ViewTest
> >
> > https://circleci.com/gh/DikangGu/cassandra/20
> >
> > --
> > Dikang
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > unsubscr...@cassandra.apache.org>
> > For additional commands, e-mail: dev-h...@cassandra.apache.org > dev-h...@cassandra.apache.org>
> >
> >
> >
>
>
> --
> Dikang
>
>

Re: Timeout unit tests in trunk

[Dikang Gu]

Cool, I think I fixed the ViewTest by changing from updateView("TRUNCATE
%s") to execute("TRUNCATE %s").

I also split it into several smaller unit tests. Patch is here:
https://issues.apache.org/jira/browse/CASSANDRA-14280

I haven't got time to look into BatchMetricsTest yet.

Thanks
Dikang.

On Tue, Feb 27, 2018 at 6:00 PM, Jason Brown  wrote:

> All,
>
> As @kjellman pointed out, the timeouts on ViewTest & ViewBuilderTaskTest
> are being addressed in CASSANDRA-14194
>  (I have a patch,
> almost ready to release).
>
> @dikang if you want to refactor those tests for fun, go for it - but note
> that the timeouts are currently not due to size.
>
> I have no idea about the BatchMetricsTest, but I can see if it is related
> to the others. @dikang, Do you have any details to share about the
> failures?
>
> -Jason
>
> On Tue, Feb 27, 2018 at 5:16 PM, Dinesh Joshi <
> dinesh.jo...@yahoo.com.invalid> wrote:
>
> > Yes, give it a go. I am not 100% sure if it will help a whole lot but try
> > it out and let's see what happens!
> > Dinesh
> >
> > On Tuesday, February 27, 2018, 2:57:41 PM PST, Dikang Gu <
> > dikan...@gmail.com> wrote:
> >
> >  I took some look at the cql3.ViewTest, it seems too big and timeout very
> > often. Any objections if I split it into two or multiple tests?
> >
> > On Tue, Feb 27, 2018 at 1:32 PM, Michael Kjellman 
> > wrote:
> >
> > > well, turns out we already have a jira tracking the MV tests being
> broken
> > > on trunk. they are legit broken :) thanks jaso
> > >
> > > https://issues.apache.org/jira/browse/CASSANDRA-14194
> > >
> > > not sure about the batch test timeout there though.. did you debug it
> at
> > > all by chance?
> > >
> > >
> > > On Feb 27, 2018, at 1:27 PM, Michael Kjellman  >  > > kjell...@apple.com>> wrote:
> > >
> > > hey dikang: just chatted a little bit about this. proposal: let's add
> the
> > > equivalent of @resource_intensive to unit tests too.. and the first one
> > is
> > > to stop from running the MV unit tests in the free circleci containers.
> > > thoughts?
> > >
> > > also, might want to bug your management to see if you can get some paid
> > > circleci resources. it's game changing!
> > >
> > > best,
> > > kjellman
> > >
> > > On Feb 27, 2018, at 12:12 PM, Dinesh Joshi  > > INVALID> wrote:
> > >
> > > Some tests might require additional resources to spin up the required
> > > components. 2 CPU / 4GB might not be sufficient. You may need to bump
> up
> > > the resources to 8CPU / 16GB.
> > > Dinesh
> > >
> > >  On Tuesday, February 27, 2018, 11:24:34 AM PST, Dikang Gu <
> > > dikan...@gmail.com> wrote:
> > >
> > > Looks like there are a few flaky/timeout unit tests in trunk, wondering
> > is
> > > there anyone looking at them already?
> > >
> > > testBuildRange - org.apache.cassandra.db.view.ViewBuilderTaskTest
> > > testUnloggedPartitionsPerBatch -
> > > org.apache.cassandra.metrics.BatchMetricsTest
> > > testViewBuilderResume - org.apache.cassandra.cql3.ViewTest
> > >
> > > https://circleci.com/gh/DikangGu/cassandra/20
> > >
> > > --
> > > Dikang
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org dev-
> > > unsubscr...@cassandra.apache.org>
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > dev-h...@cassandra.apache.org>
> > >
> > >
> > >
> >
> >
> > --
> > Dikang
> >
> >
>



-- 
Dikang