Thanks, Nate. I’ll create this request.
Dinesh
On Aug 17, 2018, at 5:09 PM, Nate McCall wrote:
>> I'm not sure logistically how we get a new repo created and licensing and
>> such, but if someone helps make it we can cut the patch against it
>>
> This is pretty straight forward. For precedent,
> I'm not sure logistically how we get a new repo created and licensing and
> such, but if someone helps make it we can cut the patch against it
>
This is pretty straight forward. For precedent, see:
https://issues.apache.org/jira/browse/CASSANDRA-13634
We currently have three repositories:
https:
Thanks for the confirmation Andy.
Created a JIRA to track the guava upgrade
https://issues.apache.org/jira/browse/CASSANDRA-14655.
I current put target version as 4.x. If a compatible version of the driver
happens to be released soon enough, and if there is a consensus that we
should merge this i
Hi Jeff,
Thanks for the patch. I assigned the ticket to you. I'll be happy to review the
ticket later today.
Dinesh
On Friday, August 17, 2018, 1:24:33 PM PDT, Jeff Beck
wrote:
I submitted a patch for the feed to that ticket it also seemed like we
needed bundler to ensure we always us
I submitted a patch for the feed to that ticket it also seemed like we
needed bundler to ensure we always use the same gems.
On Thu, Aug 9, 2018 at 2:44 AM Jacques-Henri Berthemet <
jacques-henri.berthe...@genesys.com> wrote:
> Hi Scott,
>
> Here is the ticket: https://issues.apache.org/jira/brow
You can still use the same repo and go with different release cadence as
Jeremiah mentioned, and yes, you can just pull the management sidecar,
test, and rollout without rolling out the server.
It looks like there are merits to both approaches, but it is going to come
down to the appetite of the t
Both approaches have merits. However the general consensus seems to be that we
should put this in a separate repo and I agree.
Dinesh
On Friday, August 17, 2018, 10:46:04 AM PDT, Rahul Singh
wrote:
I understand the issues of managing different versions of two correlated
components —
I understand the issues of managing different versions of two correlated
components — but it is possible to create unit tests with core components of
both. It takes more effort but it is possible.
That being said, in my experience using Reaper and in the DataStax distribution
, using OpsCenter
Speaking from experience (Reaper), I can say that developing a sidecar
admin / repair tool out of tree that's compatible with multiple versions
really isn't that big of a problem. We've been doing it for a while now.
https://github.com/thelastpickle/cassandra-reaper/blob/master/.travis.yml
On Fr
While I would love to use a different build system (e.g. gradle) for the
sidecar, I agree with Dinesh that a separate repo would make sidecar
development much harder to verify, especially on the testing and
compatibility front. As Jeremiah mentioned we can always choose later to
release the sidecar
+1 in maintaining a separate project and release cycle for side car. We have
been running side car in production for 6+ years and the rate of changes to the
side car is much higher than to the actual data store. This will enable faster
iteration needed for the side car and help folks roll out ma
Not sure why the two things being in the same repo means they need the same
release process. You can always do interim releases of the management artifact
between server releases, or even have completely decoupled releases.
-Jeremiah
> On Aug 17, 2018, at 10:52 AM, Blake Eggleston wrote:
>
>
I'd be more in favor of making it a separate project, basically for all the
reasons listed below. I'm assuming we'd want a management process to work
across different versions, which will be more awkward if it's in tree. Even if
that's not the case, keeping it in a different repo at this point w
I definitely think we should include it in 4.0. TBH I think it's reasonable
for it to get done after the feature freeze seeing as it is a bug.
On 17 August 2018 at 21:06, Anuj Wadehra
wrote:
> Hi,
>
> I think CASSANDRA-14227 is pending for long time now. Though, the data
> loss issue was addres
Hi,
I think CASSANDRA-14227 is pending for long time now. Though, the data loss
issue was addressed in CASSANDRA-14092, Cassandra users are still prohibited to
use long TTLs (20+ years) as the maximum expiration timestamp that can be
represented by the storage engine is 2038-01-19T03:14:06+00:
> On Aug 16, 2018, at 9:27 PM, Sankalp Kohli wrote:
>
> I am bumping this thread because patch has landed for this with repair
> functionality.
>
> I have a following proposal for this which I can put in the JIRA or doc
>
> 1. We should see if we can keep this in a separate repo like Dtest.
16 matches
Mail list logo
