Re: [RELEASE] Apache Cassandra 3.0.11 released

2017-02-23 Thread Julien Anguenot
If this is the repository’s intended behavior then all good with me. I 
understand c).

Thank you for the reply Michael.

   J.

P.S: All our nodes are controlled by a Salt master so it was indeed rather easy 
to wget and reinstall as you described. Although easy, not very convenient.

> On Feb 23, 2017, at 8:28 PM, Michael Shuler  wrote:
> 
> This is correct, we use reprepro and leave the old versions in the pool.
> 
> I'm not exactly sure what you mean by "put them back to the apt cache",
> Julien. The only thing needed for a downgrade is:
>  `wget $URL && dpkg -i cassandra*.deb`
> 
> If you run lots of servers on a specific version, then I'd suggest
> dropping the specific version you need in a local apt repo and use
> `dpkg-scanpackages`.
> 
> Basically, it's intentional for a) getting users installing the latest
> version, b) saving on download size of metadata, and probably most
> importantly c) not needing a release manager to maintain a complete
> local debian archive in order to scan every old version for every
> release forever. We just build and upload the latest with reprepro.
> 
> -- 
> Kind regards,
> Michael
> 
> On 02/23/2017 07:28 PM, Murukesh Mohanan wrote:
>> This is speculation on my part, but this might be due to the software used
>> to set up the repository. reprepro is very simple to use (and so, somewhat
>> popular), but it only supports one version of a package at a time. Older
>> deb files are not removed, but they do get dropped from the Packages file.
>> This repo might be setup using reprepro.
>> 
>> On Fri, 24 Feb 2017 at 08:29 Julien Anguenot  wrote:
>> 
>>> Hey,
>>> 
>>> Any reasons why old versions get removed from the Debian repository when a
>>> new version gets promoted?
>>> 
>>> For instance, here one would expect to still be able to:
>>> 
>>>  $ apt-get install cassandra=3.0.10
>>> 
>>> But after that release only the latest 3.0.11 is available:
>>> 
>>> 
>>> http://dl.bintray.com/apache/cassandra/dists/30x/main/binary-amd64/Packages
>>> 
>>> Old versions are still available from there:
>>> 
>>>   http://dl.bintray.com/apache/cassandra/pool/main/c/cassandra/ <
>>> http://dl.bintray.com/apache/cassandra/pool/main/c/cassandra/>
>>> 
>>> But it requires to manually download and put them back to the apt cache.
>>> 
>>> It is quite handy for point releases when a rollback is required, and
>>> possible, because of regressions.
>>> 
>>> Thanks.
>>> 
>>>   J.
>>> 
>>> --
>>> Julien Anguenot (@anguenot)
>>> 
 On Feb 21, 2017, at 12:03 PM, Michael Shuler 
>>> wrote:
 
 The Cassandra team is pleased to announce the release of Apache
 Cassandra version 3.0.11.
 
 Apache Cassandra is a fully distributed database. It is the right choice
 when you need scalability and high availability without compromising
 performance.
 
 http://cassandra.apache.org/
 
 Downloads of source and binary distributions are listed in our download
 section:
 
 http://cassandra.apache.org/download/
 
 This version is a bug fix release[1] on the 3.0 series. As always,
 please pay attention to the release notes[2] and Let us know[3] if you
 were to encounter any problem.
 
 Enjoy!
 
 [1]: (CHANGES.txt)
 
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.0.11
 [2]: (NEWS.txt)
 
>>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.0.11
 [3]: https://issues.apache.org/jira/browse/CASSANDRA
 
>>> 
>>> --
>> 
>> Murukesh Mohanan,
>> Yahoo! Japan
>> 
> 

--
Julien Anguenot (@anguenot)



Re: [RELEASE] Apache Cassandra 3.0.11 released

2017-02-23 Thread Michael Shuler
This is correct, we use reprepro and leave the old versions in the pool.

I'm not exactly sure what you mean by "put them back to the apt cache",
Julien. The only thing needed for a downgrade is:
  `wget $URL && dpkg -i cassandra*.deb`

If you run lots of servers on a specific version, then I'd suggest
dropping the specific version you need in a local apt repo and use
`dpkg-scanpackages`.

Basically, it's intentional for a) getting users installing the latest
version, b) saving on download size of metadata, and probably most
importantly c) not needing a release manager to maintain a complete
local debian archive in order to scan every old version for every
release forever. We just build and upload the latest with reprepro.

-- 
Kind regards,
Michael

On 02/23/2017 07:28 PM, Murukesh Mohanan wrote:
> This is speculation on my part, but this might be due to the software used
> to set up the repository. reprepro is very simple to use (and so, somewhat
> popular), but it only supports one version of a package at a time. Older
> deb files are not removed, but they do get dropped from the Packages file.
> This repo might be setup using reprepro.
> 
> On Fri, 24 Feb 2017 at 08:29 Julien Anguenot  wrote:
> 
>> Hey,
>>
>> Any reasons why old versions get removed from the Debian repository when a
>> new version gets promoted?
>>
>> For instance, here one would expect to still be able to:
>>
>>   $ apt-get install cassandra=3.0.10
>>
>> But after that release only the latest 3.0.11 is available:
>>
>>
>> http://dl.bintray.com/apache/cassandra/dists/30x/main/binary-amd64/Packages
>>
>> Old versions are still available from there:
>>
>>http://dl.bintray.com/apache/cassandra/pool/main/c/cassandra/ <
>> http://dl.bintray.com/apache/cassandra/pool/main/c/cassandra/>
>>
>> But it requires to manually download and put them back to the apt cache.
>>
>> It is quite handy for point releases when a rollback is required, and
>> possible, because of regressions.
>>
>> Thanks.
>>
>>J.
>>
>> --
>> Julien Anguenot (@anguenot)
>>
>>> On Feb 21, 2017, at 12:03 PM, Michael Shuler 
>> wrote:
>>>
>>> The Cassandra team is pleased to announce the release of Apache
>>> Cassandra version 3.0.11.
>>>
>>> Apache Cassandra is a fully distributed database. It is the right choice
>>> when you need scalability and high availability without compromising
>>> performance.
>>>
>>> http://cassandra.apache.org/
>>>
>>> Downloads of source and binary distributions are listed in our download
>>> section:
>>>
>>> http://cassandra.apache.org/download/
>>>
>>> This version is a bug fix release[1] on the 3.0 series. As always,
>>> please pay attention to the release notes[2] and Let us know[3] if you
>>> were to encounter any problem.
>>>
>>> Enjoy!
>>>
>>> [1]: (CHANGES.txt)
>>>
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.0.11
>>> [2]: (NEWS.txt)
>>>
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.0.11
>>> [3]: https://issues.apache.org/jira/browse/CASSANDRA
>>>
>>
>> --
> 
> Murukesh Mohanan,
> Yahoo! Japan
> 



Re: [RELEASE] Apache Cassandra 3.0.11 released

2017-02-23 Thread Murukesh Mohanan
This is speculation on my part, but this might be due to the software used
to set up the repository. reprepro is very simple to use (and so, somewhat
popular), but it only supports one version of a package at a time. Older
deb files are not removed, but they do get dropped from the Packages file.
This repo might be setup using reprepro.

On Fri, 24 Feb 2017 at 08:29 Julien Anguenot  wrote:

> Hey,
>
> Any reasons why old versions get removed from the Debian repository when a
> new version gets promoted?
>
> For instance, here one would expect to still be able to:
>
>   $ apt-get install cassandra=3.0.10
>
> But after that release only the latest 3.0.11 is available:
>
>
> http://dl.bintray.com/apache/cassandra/dists/30x/main/binary-amd64/Packages
>
> Old versions are still available from there:
>
>http://dl.bintray.com/apache/cassandra/pool/main/c/cassandra/ <
> http://dl.bintray.com/apache/cassandra/pool/main/c/cassandra/>
>
> But it requires to manually download and put them back to the apt cache.
>
> It is quite handy for point releases when a rollback is required, and
> possible, because of regressions.
>
> Thanks.
>
>J.
>
> --
> Julien Anguenot (@anguenot)
>
> > On Feb 21, 2017, at 12:03 PM, Michael Shuler 
> wrote:
> >
> > The Cassandra team is pleased to announce the release of Apache
> > Cassandra version 3.0.11.
> >
> > Apache Cassandra is a fully distributed database. It is the right choice
> > when you need scalability and high availability without compromising
> > performance.
> >
> > http://cassandra.apache.org/
> >
> > Downloads of source and binary distributions are listed in our download
> > section:
> >
> > http://cassandra.apache.org/download/
> >
> > This version is a bug fix release[1] on the 3.0 series. As always,
> > please pay attention to the release notes[2] and Let us know[3] if you
> > were to encounter any problem.
> >
> > Enjoy!
> >
> > [1]: (CHANGES.txt)
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.0.11
> > [2]: (NEWS.txt)
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.0.11
> > [3]: https://issues.apache.org/jira/browse/CASSANDRA
> >
>
> --

Murukesh Mohanan,
Yahoo! Japan


Re: [RELEASE] Apache Cassandra 3.0.11 released

2017-02-23 Thread Julien Anguenot
Hey, 

Any reasons why old versions get removed from the Debian repository when a new 
version gets promoted?

For instance, here one would expect to still be able to:

  $ apt-get install cassandra=3.0.10

But after that release only the latest 3.0.11 is available:

   http://dl.bintray.com/apache/cassandra/dists/30x/main/binary-amd64/Packages

Old versions are still available from there:

   http://dl.bintray.com/apache/cassandra/pool/main/c/cassandra/ 


But it requires to manually download and put them back to the apt cache.

It is quite handy for point releases when a rollback is required, and possible, 
because of regressions.

Thanks. 

   J.

--
Julien Anguenot (@anguenot)

> On Feb 21, 2017, at 12:03 PM, Michael Shuler  wrote:
> 
> The Cassandra team is pleased to announce the release of Apache
> Cassandra version 3.0.11.
> 
> Apache Cassandra is a fully distributed database. It is the right choice
> when you need scalability and high availability without compromising
> performance.
> 
> http://cassandra.apache.org/
> 
> Downloads of source and binary distributions are listed in our download
> section:
> 
> http://cassandra.apache.org/download/
> 
> This version is a bug fix release[1] on the 3.0 series. As always,
> please pay attention to the release notes[2] and Let us know[3] if you
> were to encounter any problem.
> 
> Enjoy!
> 
> [1]: (CHANGES.txt)
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.0.11
> [2]: (NEWS.txt)
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.0.11
> [3]: https://issues.apache.org/jira/browse/CASSANDRA
> 



Re: Truncate operation not available in Mutation Object

2017-02-23 Thread Sanal Vasudevan
Thank you Chris.

On Fri, Feb 24, 2017 at 4:00 AM, Chris Lohfink 
wrote:

> The truncates are written to the truncated_at field in system.local and
> should be honored by the commit log replayer (
> https://github.com/apache/cassandra/blob/af3fe39dcabd9ef77a00309ce67412
> 68423206df/src/java/org/apache/cassandra/db/commitlog/
> CommitLogReplayer.java#L102
> ).
>
> Chris
>
> On Wed, Feb 22, 2017 at 7:02 PM, Sanal Vasudevan 
> wrote:
>
> > Thanks Jeremy.
> > Any way I could detect that such a truncate operation was performed on
> the
> > table? Does it leave a trace that the truncate happened anywhere?
> >
> >
> > Best regards,
> > Sanal
> >
> > On Thu, Feb 23, 2017 at 11:47 AM, Jeremy Hanna <
> jeremy.hanna1...@gmail.com
> > >
> > wrote:
> >
> > > Everything in that table is deleted. There's no mutation or anything in
> > > the commitlog. It's a deletion of all the sstables for that table. To
> > make
> > > sure everything is gone, it first does a flush, then a snapshot to
> > protect
> > > against a mistake, then the truncate itself.
> > >
> > > > On Feb 22, 2017, at 6:05 PM, Sanal Vasudevan 
> > > wrote:
> > > >
> > > > Hi Folks,
> > > >
> > > > I am trying to read Mutations from commit log files through an
> > > > implementation of CommitLogReadHandler interface.
> > > >
> > > > For a truncate CQL operation, I do not see a Mutation object.
> > > >
> > > > Does C* skip writing the truncate operation into the commit log file?
> > > >
> > > >
> > > > Thanks for your help.
> > > >
> > > > Best regards,
> > > > Sanal
> > >
> >
> >
> >
> > --
> > Sanal Vasudevan Nair
> >
>



-- 
Sanal Vasudevan Nair


Re: Truncate operation not available in Mutation Object

2017-02-23 Thread Jeremy Hanna
thanks Chris

> On Feb 23, 2017, at 11:00 AM, Chris Lohfink  
> wrote:
> 
> The truncates are written to the truncated_at field in system.local and
> should be honored by the commit log replayer (
> https://github.com/apache/cassandra/blob/af3fe39dcabd9ef77a00309ce6741268423206df/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L102
> ).
> 
> Chris
> 
> On Wed, Feb 22, 2017 at 7:02 PM, Sanal Vasudevan 
> wrote:
> 
>> Thanks Jeremy.
>> Any way I could detect that such a truncate operation was performed on the
>> table? Does it leave a trace that the truncate happened anywhere?
>> 
>> 
>> Best regards,
>> Sanal
>> 
>> On Thu, Feb 23, 2017 at 11:47 AM, Jeremy Hanna >> 
>> wrote:
>> 
>>> Everything in that table is deleted. There's no mutation or anything in
>>> the commitlog. It's a deletion of all the sstables for that table. To
>> make
>>> sure everything is gone, it first does a flush, then a snapshot to
>> protect
>>> against a mistake, then the truncate itself.
>>> 
 On Feb 22, 2017, at 6:05 PM, Sanal Vasudevan 
>>> wrote:
 
 Hi Folks,
 
 I am trying to read Mutations from commit log files through an
 implementation of CommitLogReadHandler interface.
 
 For a truncate CQL operation, I do not see a Mutation object.
 
 Does C* skip writing the truncate operation into the commit log file?
 
 
 Thanks for your help.
 
 Best regards,
 Sanal
>>> 
>> 
>> 
>> 
>> --
>> Sanal Vasudevan Nair
>> 



Re: Truncate operation not available in Mutation Object

2017-02-23 Thread Chris Lohfink
The truncates are written to the truncated_at field in system.local and
should be honored by the commit log replayer (
https://github.com/apache/cassandra/blob/af3fe39dcabd9ef77a00309ce6741268423206df/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L102
).

Chris

On Wed, Feb 22, 2017 at 7:02 PM, Sanal Vasudevan 
wrote:

> Thanks Jeremy.
> Any way I could detect that such a truncate operation was performed on the
> table? Does it leave a trace that the truncate happened anywhere?
>
>
> Best regards,
> Sanal
>
> On Thu, Feb 23, 2017 at 11:47 AM, Jeremy Hanna  >
> wrote:
>
> > Everything in that table is deleted. There's no mutation or anything in
> > the commitlog. It's a deletion of all the sstables for that table. To
> make
> > sure everything is gone, it first does a flush, then a snapshot to
> protect
> > against a mistake, then the truncate itself.
> >
> > > On Feb 22, 2017, at 6:05 PM, Sanal Vasudevan 
> > wrote:
> > >
> > > Hi Folks,
> > >
> > > I am trying to read Mutations from commit log files through an
> > > implementation of CommitLogReadHandler interface.
> > >
> > > For a truncate CQL operation, I do not see a Mutation object.
> > >
> > > Does C* skip writing the truncate operation into the commit log file?
> > >
> > >
> > > Thanks for your help.
> > >
> > > Best regards,
> > > Sanal
> >
>
>
>
> --
> Sanal Vasudevan Nair
>