Re: [DISCUSS] Flume 1.4 release plan
On Fri, Jun 21, 2013 at 2:59 PM, Edward Sargisson wrote: > 1. The patch to build with elasticsearch 0.90.1 is in FLUME-2049 and the > review is here: https://reviews.apache.org/r/11581/ > I think we really need that one in Flume because otherwise anybody who > wants to use Flume with anything other than elasticsearch 0.19 (really old) > will have to do a custom compile. > I just committed this. 2. I mentioned issues with Flume logging via itself. I got those to a point > where I thought I understood the problem and have raised work items either > in Flume or with Log4j2 to document. These do not hold up Flume 1.4.0 > If any of this is ready please point me to the JIRA / patch and I'll take a look from the Flume perspective. 3. Ideally, we'd do FLUME-2092 to document that the index name needs to > match a Kibana setting. > Can you provide a patch? Happy to commit it. 4. It would probably be nice to get the patch from FLUME-2089 in > (unexpected character sets cause a YAMLException). However, I think we need > a unit test for this. > If we can get a unit test, or a follow-up JIRA that includes a unit test then I'll commit both. BTW I'm aiming for tomorrow evening for an RC. Thanks Edward! Mike On Wed, May 22, 2013 at 9:28 AM, Edward Sargisson wrote: > >> Hi All, >> +1/+1 for 1.4 and Mike. >> >> >> I'm very keen to have a 1.4 for the environments I manage. There's a lot >> of stuff I'm keen on in there. >> >> On my pre-1.4 list: >> 1. compile with elasticsearch 0.90 >> 2. figure out file channel state issue which is stopping Flume logging >> via itself. >> >> 1. Currently we compile with es 0.19. If somebody wants to run es 0.20 >> they have to recompile (es made an interface change that is source >> compatible but requires a recompile). es 0.90 has been out for 2-ish weeks >> so safe enough to change the compile to. I think I'll raise an empty Jira >> to record this. >> >> 2. I haven't reported this because I haven't isolated it well enough. I'm >> having issues with the 1.3.1 file channel which I'd like to resolve. >> >> Cheers, >> Edward >> >> "Hi folks, >> We have had over 100 commits since 1.3.1, and a bunch of new features and >> improvements including a Thrift source, much improved ElasticSearch sink, >> support for a new plugins directory and layout, compression support in the >> avro sink/source, improved checkpointing in the file channel and more, >> plus >> a lot of bug fixes. >> >> It seems to me that it's time to start thinking about cutting a 1.4 >> release. I would be happy to volunteer to RM the release. Worth noting >> that >> I will be unavailable for the next two weeks... but after that I'd be >> happy >> to pick this up and run with it. That's also a decent amount of time for >> people to get moving on patches and reviews for their favorite features, >> bug fixes, etc. >> >> If this all sounds OK, I'd like to suggest targeting the last week of June >> as a release date. If we can release in time for Hadoop Summit then that >> would be pretty nice. Otherwise, if something comes up and we can't get >> the >> release out that week, let's shoot for the first week of July at the >> latest. >> >> Please let me know your thoughts. >> >> Regards, >> Mike >> >> +1 for Flume 1.4 >> +1 for Mike being RM. >> >> >> Cheers, >> Hari" >> > >
Re: [DISCUSS] Flume 1.4 release plan
Hi all, I thought I'd give an update from the ElasticSearchSink perspective. I know that we're very keen to see a 1.4 release and will test RCs, etc. when they come out when priorities allow. 1. The patch to build with elasticsearch 0.90.1 is in FLUME-2049 and the review is here: https://reviews.apache.org/r/11581/ I think we really need that one in Flume because otherwise anybody who wants to use Flume with anything other than elasticsearch 0.19 (really old) will have to do a custom compile. 2. I mentioned issues with Flume logging via itself. I got those to a point where I thought I understood the problem and have raised work items either in Flume or with Log4j2 to document. These do not hold up Flume 1.4.0 3. Ideally, we'd do FLUME-2092 to document that the index name needs to match a Kibana setting. 4. It would probably be nice to get the patch from FLUME-2089 in (unexpected character sets cause a YAMLException). However, I think we need a unit test for this. Cheers, Edward On Wed, May 22, 2013 at 9:28 AM, Edward Sargisson wrote: > Hi All, > +1/+1 for 1.4 and Mike. > > > I'm very keen to have a 1.4 for the environments I manage. There's a lot > of stuff I'm keen on in there. > > On my pre-1.4 list: > 1. compile with elasticsearch 0.90 > 2. figure out file channel state issue which is stopping Flume logging via > itself. > > 1. Currently we compile with es 0.19. If somebody wants to run es 0.20 > they have to recompile (es made an interface change that is source > compatible but requires a recompile). es 0.90 has been out for 2-ish weeks > so safe enough to change the compile to. I think I'll raise an empty Jira > to record this. > > 2. I haven't reported this because I haven't isolated it well enough. I'm > having issues with the 1.3.1 file channel which I'd like to resolve. > > Cheers, > Edward > > "Hi folks, > We have had over 100 commits since 1.3.1, and a bunch of new features and > improvements including a Thrift source, much improved ElasticSearch sink, > support for a new plugins directory and layout, compression support in the > avro sink/source, improved checkpointing in the file channel and more, plus > a lot of bug fixes. > > It seems to me that it's time to start thinking about cutting a 1.4 > release. I would be happy to volunteer to RM the release. Worth noting that > I will be unavailable for the next two weeks... but after that I'd be happy > to pick this up and run with it. That's also a decent amount of time for > people to get moving on patches and reviews for their favorite features, > bug fixes, etc. > > If this all sounds OK, I'd like to suggest targeting the last week of June > as a release date. If we can release in time for Hadoop Summit then that > would be pretty nice. Otherwise, if something comes up and we can't get the > release out that week, let's shoot for the first week of July at the > latest. > > Please let me know your thoughts. > > Regards, > Mike > > +1 for Flume 1.4 > +1 for Mike being RM. > > > Cheers, > Hari" >
Re: [DISCUSS] Flume 1.4 release plan
Hi Roshan, I'm OK with that if no one else has any concerns. I'll start a separate thread with a scoping discussion. Thanks, Mike On Thu, Jun 6, 2013 at 11:29 AM, Roshan Naik wrote: > shall i go ahead and file a jira on dropping the Recoverable Memory Channel > from 1.4 ? > > > On Wed, May 29, 2013 at 3:36 PM, Roshan Naik > wrote: > > > Perhaps this is a good point to consider dropping the Recoverable Memory > > Channel from 1.4 ... since it has been deprecated. > > > > > > On Wed, May 29, 2013 at 8:49 AM, Ralph Goers >wrote: > > > >> I don't consider this a showstopper, but it should be a learning > >> experience. First, Flume should probably release more often. Second, > where > >> possible deprecate stuff in one release and delete it in the next. > >> > >> > >> Ralph > >> > >> On May 28, 2013, at 6:47 AM, Mike Percy wrote: > >> > >> > Hmm, I wish we had agreed on the use of those APIs outside the project > >> up > >> > front. The interfaces log4j2 used to embed Flume were not designed to > be > >> > public. Now that we have a stable API, hopefully log4j2 can have > another > >> > release soon which takes advantage of the embedded agent APIs. > >> > > >> > AFAICT it's not going to be straightforward to provide backward > >> > compatibility with the previous APIs, but I'm willing to be proven > >> wrong... > >> > > >> > Regards, > >> > Mike > >> > > >> > > >> > > >> > On Sun, May 26, 2013 at 7:58 AM, Ralph Goers < > >> ralph.go...@dslextreme.com>wrote: > >> > > >> >> The one concern I have is that when adding support for embedded > agents > >> >> some classes were removed. This means if users of Log4j 2 try to use > >> 1.4 > >> >> they will have problems until it is modified to use Flume 1.4. It > >> would > >> >> have been nice to have had at least one release where both were > >> present. > >> >> > >> >> Ralph > >> >> > >> >> On May 22, 2013, at 12:33 AM, Mike Percy wrote: > >> >> > >> >>> Hi folks, > >> >>> We have had over 100 commits since 1.3.1, and a bunch of new > features > >> and > >> >>> improvements including a Thrift source, much improved ElasticSearch > >> sink, > >> >>> support for a new plugins directory and layout, compression support > in > >> >> the > >> >>> avro sink/source, improved checkpointing in the file channel and > more, > >> >> plus > >> >>> a lot of bug fixes. > >> >>> > >> >>> It seems to me that it's time to start thinking about cutting a 1.4 > >> >>> release. I would be happy to volunteer to RM the release. Worth > noting > >> >> that > >> >>> I will be unavailable for the next two weeks... but after that I'd > be > >> >> happy > >> >>> to pick this up and run with it. That's also a decent amount of time > >> for > >> >>> people to get moving on patches and reviews for their favorite > >> features, > >> >>> bug fixes, etc. > >> >>> > >> >>> If this all sounds OK, I'd like to suggest targeting the last week > of > >> >> June > >> >>> as a release date. If we can release in time for Hadoop Summit then > >> that > >> >>> would be pretty nice. Otherwise, if something comes up and we can't > >> get > >> >> the > >> >>> release out that week, let's shoot for the first week of July at the > >> >> latest. > >> >>> > >> >>> Please let me know your thoughts. > >> >>> > >> >>> Regards, > >> >>> Mike > >> >> > >> >> > >> > >> > > >
Re: [DISCUSS] Flume 1.4 release plan
shall i go ahead and file a jira on dropping the Recoverable Memory Channel from 1.4 ? On Wed, May 29, 2013 at 3:36 PM, Roshan Naik wrote: > Perhaps this is a good point to consider dropping the Recoverable Memory > Channel from 1.4 ... since it has been deprecated. > > > On Wed, May 29, 2013 at 8:49 AM, Ralph Goers > wrote: > >> I don't consider this a showstopper, but it should be a learning >> experience. First, Flume should probably release more often. Second, where >> possible deprecate stuff in one release and delete it in the next. >> >> >> Ralph >> >> On May 28, 2013, at 6:47 AM, Mike Percy wrote: >> >> > Hmm, I wish we had agreed on the use of those APIs outside the project >> up >> > front. The interfaces log4j2 used to embed Flume were not designed to be >> > public. Now that we have a stable API, hopefully log4j2 can have another >> > release soon which takes advantage of the embedded agent APIs. >> > >> > AFAICT it's not going to be straightforward to provide backward >> > compatibility with the previous APIs, but I'm willing to be proven >> wrong... >> > >> > Regards, >> > Mike >> > >> > >> > >> > On Sun, May 26, 2013 at 7:58 AM, Ralph Goers < >> ralph.go...@dslextreme.com>wrote: >> > >> >> The one concern I have is that when adding support for embedded agents >> >> some classes were removed. This means if users of Log4j 2 try to use >> 1.4 >> >> they will have problems until it is modified to use Flume 1.4. It >> would >> >> have been nice to have had at least one release where both were >> present. >> >> >> >> Ralph >> >> >> >> On May 22, 2013, at 12:33 AM, Mike Percy wrote: >> >> >> >>> Hi folks, >> >>> We have had over 100 commits since 1.3.1, and a bunch of new features >> and >> >>> improvements including a Thrift source, much improved ElasticSearch >> sink, >> >>> support for a new plugins directory and layout, compression support in >> >> the >> >>> avro sink/source, improved checkpointing in the file channel and more, >> >> plus >> >>> a lot of bug fixes. >> >>> >> >>> It seems to me that it's time to start thinking about cutting a 1.4 >> >>> release. I would be happy to volunteer to RM the release. Worth noting >> >> that >> >>> I will be unavailable for the next two weeks... but after that I'd be >> >> happy >> >>> to pick this up and run with it. That's also a decent amount of time >> for >> >>> people to get moving on patches and reviews for their favorite >> features, >> >>> bug fixes, etc. >> >>> >> >>> If this all sounds OK, I'd like to suggest targeting the last week of >> >> June >> >>> as a release date. If we can release in time for Hadoop Summit then >> that >> >>> would be pretty nice. Otherwise, if something comes up and we can't >> get >> >> the >> >>> release out that week, let's shoot for the first week of July at the >> >> latest. >> >>> >> >>> Please let me know your thoughts. >> >>> >> >>> Regards, >> >>> Mike >> >> >> >> >> >> >
Re: [DISCUSS] Flume 1.4 release plan
Perhaps this is a good point to consider dropping the Recoverable Memory Channel from 1.4 ... since it has been deprecated. On Wed, May 29, 2013 at 8:49 AM, Ralph Goers wrote: > I don't consider this a showstopper, but it should be a learning > experience. First, Flume should probably release more often. Second, where > possible deprecate stuff in one release and delete it in the next. > > > Ralph > > On May 28, 2013, at 6:47 AM, Mike Percy wrote: > > > Hmm, I wish we had agreed on the use of those APIs outside the project up > > front. The interfaces log4j2 used to embed Flume were not designed to be > > public. Now that we have a stable API, hopefully log4j2 can have another > > release soon which takes advantage of the embedded agent APIs. > > > > AFAICT it's not going to be straightforward to provide backward > > compatibility with the previous APIs, but I'm willing to be proven > wrong... > > > > Regards, > > Mike > > > > > > > > On Sun, May 26, 2013 at 7:58 AM, Ralph Goers >wrote: > > > >> The one concern I have is that when adding support for embedded agents > >> some classes were removed. This means if users of Log4j 2 try to use 1.4 > >> they will have problems until it is modified to use Flume 1.4. It would > >> have been nice to have had at least one release where both were present. > >> > >> Ralph > >> > >> On May 22, 2013, at 12:33 AM, Mike Percy wrote: > >> > >>> Hi folks, > >>> We have had over 100 commits since 1.3.1, and a bunch of new features > and > >>> improvements including a Thrift source, much improved ElasticSearch > sink, > >>> support for a new plugins directory and layout, compression support in > >> the > >>> avro sink/source, improved checkpointing in the file channel and more, > >> plus > >>> a lot of bug fixes. > >>> > >>> It seems to me that it's time to start thinking about cutting a 1.4 > >>> release. I would be happy to volunteer to RM the release. Worth noting > >> that > >>> I will be unavailable for the next two weeks... but after that I'd be > >> happy > >>> to pick this up and run with it. That's also a decent amount of time > for > >>> people to get moving on patches and reviews for their favorite > features, > >>> bug fixes, etc. > >>> > >>> If this all sounds OK, I'd like to suggest targeting the last week of > >> June > >>> as a release date. If we can release in time for Hadoop Summit then > that > >>> would be pretty nice. Otherwise, if something comes up and we can't get > >> the > >>> release out that week, let's shoot for the first week of July at the > >> latest. > >>> > >>> Please let me know your thoughts. > >>> > >>> Regards, > >>> Mike > >> > >> > >
Re: [DISCUSS] Flume 1.4 release plan
I don't consider this a showstopper, but it should be a learning experience. First, Flume should probably release more often. Second, where possible deprecate stuff in one release and delete it in the next. Ralph On May 28, 2013, at 6:47 AM, Mike Percy wrote: > Hmm, I wish we had agreed on the use of those APIs outside the project up > front. The interfaces log4j2 used to embed Flume were not designed to be > public. Now that we have a stable API, hopefully log4j2 can have another > release soon which takes advantage of the embedded agent APIs. > > AFAICT it's not going to be straightforward to provide backward > compatibility with the previous APIs, but I'm willing to be proven wrong... > > Regards, > Mike > > > > On Sun, May 26, 2013 at 7:58 AM, Ralph Goers > wrote: > >> The one concern I have is that when adding support for embedded agents >> some classes were removed. This means if users of Log4j 2 try to use 1.4 >> they will have problems until it is modified to use Flume 1.4. It would >> have been nice to have had at least one release where both were present. >> >> Ralph >> >> On May 22, 2013, at 12:33 AM, Mike Percy wrote: >> >>> Hi folks, >>> We have had over 100 commits since 1.3.1, and a bunch of new features and >>> improvements including a Thrift source, much improved ElasticSearch sink, >>> support for a new plugins directory and layout, compression support in >> the >>> avro sink/source, improved checkpointing in the file channel and more, >> plus >>> a lot of bug fixes. >>> >>> It seems to me that it's time to start thinking about cutting a 1.4 >>> release. I would be happy to volunteer to RM the release. Worth noting >> that >>> I will be unavailable for the next two weeks... but after that I'd be >> happy >>> to pick this up and run with it. That's also a decent amount of time for >>> people to get moving on patches and reviews for their favorite features, >>> bug fixes, etc. >>> >>> If this all sounds OK, I'd like to suggest targeting the last week of >> June >>> as a release date. If we can release in time for Hadoop Summit then that >>> would be pretty nice. Otherwise, if something comes up and we can't get >> the >>> release out that week, let's shoot for the first week of July at the >> latest. >>> >>> Please let me know your thoughts. >>> >>> Regards, >>> Mike >> >>
Re: [DISCUSS] Flume 1.4 release plan
Hmm, I wish we had agreed on the use of those APIs outside the project up front. The interfaces log4j2 used to embed Flume were not designed to be public. Now that we have a stable API, hopefully log4j2 can have another release soon which takes advantage of the embedded agent APIs. AFAICT it's not going to be straightforward to provide backward compatibility with the previous APIs, but I'm willing to be proven wrong... Regards, Mike On Sun, May 26, 2013 at 7:58 AM, Ralph Goers wrote: > The one concern I have is that when adding support for embedded agents > some classes were removed. This means if users of Log4j 2 try to use 1.4 > they will have problems until it is modified to use Flume 1.4. It would > have been nice to have had at least one release where both were present. > > Ralph > > On May 22, 2013, at 12:33 AM, Mike Percy wrote: > > > Hi folks, > > We have had over 100 commits since 1.3.1, and a bunch of new features and > > improvements including a Thrift source, much improved ElasticSearch sink, > > support for a new plugins directory and layout, compression support in > the > > avro sink/source, improved checkpointing in the file channel and more, > plus > > a lot of bug fixes. > > > > It seems to me that it's time to start thinking about cutting a 1.4 > > release. I would be happy to volunteer to RM the release. Worth noting > that > > I will be unavailable for the next two weeks... but after that I'd be > happy > > to pick this up and run with it. That's also a decent amount of time for > > people to get moving on patches and reviews for their favorite features, > > bug fixes, etc. > > > > If this all sounds OK, I'd like to suggest targeting the last week of > June > > as a release date. If we can release in time for Hadoop Summit then that > > would be pretty nice. Otherwise, if something comes up and we can't get > the > > release out that week, let's shoot for the first week of July at the > latest. > > > > Please let me know your thoughts. > > > > Regards, > > Mike > >
Re: [DISCUSS] Flume 1.4 release plan
The one concern I have is that when adding support for embedded agents some classes were removed. This means if users of Log4j 2 try to use 1.4 they will have problems until it is modified to use Flume 1.4. It would have been nice to have had at least one release where both were present. Ralph On May 22, 2013, at 12:33 AM, Mike Percy wrote: > Hi folks, > We have had over 100 commits since 1.3.1, and a bunch of new features and > improvements including a Thrift source, much improved ElasticSearch sink, > support for a new plugins directory and layout, compression support in the > avro sink/source, improved checkpointing in the file channel and more, plus > a lot of bug fixes. > > It seems to me that it's time to start thinking about cutting a 1.4 > release. I would be happy to volunteer to RM the release. Worth noting that > I will be unavailable for the next two weeks... but after that I'd be happy > to pick this up and run with it. That's also a decent amount of time for > people to get moving on patches and reviews for their favorite features, > bug fixes, etc. > > If this all sounds OK, I'd like to suggest targeting the last week of June > as a release date. If we can release in time for Hadoop Summit then that > would be pretty nice. Otherwise, if something comes up and we can't get the > release out that week, let's shoot for the first week of July at the latest. > > Please let me know your thoughts. > > Regards, > Mike
Re: [DISCUSS] Flume 1.4 release plan
+1 for Flume 1.4 +1 for Mike being RM. On Wed, May 22, 2013 at 1:25 PM, Roshan Naik wrote: > +1 for both (non binding) > > > On Wed, May 22, 2013 at 10:41 AM, Mubarak Seyed wrote: > > > +1 for Flume 1.4 > > +1 for Mike being RM > > > > > > -Mubarak > > > > On May 22, 2013, at 9:51 AM, Venkatesh S R wrote: > > > > > +1 for both! Thanks Mike! > > > > > > Best, > > > Venkatesh > > > > > > > > > On Wed, May 22, 2013 at 9:41 AM, Will McQueen > wrote: > > > > > >> +1 for Flume 1.4 > > >> +1 for Mike being RM. > > >> > > >> On May 22, 2013, at 9:28 AM, Edward Sargisson > wrote: > > >> > > >>> Hi All, > > >>> +1/+1 for 1.4 and Mike. > > >>> > > >>> > > >>> I'm very keen to have a 1.4 for the environments I manage. There's a > > lot > > >> of > > >>> stuff I'm keen on in there. > > >>> > > >>> On my pre-1.4 list: > > >>> 1. compile with elasticsearch 0.90 > > >>> 2. figure out file channel state issue which is stopping Flume > logging > > >> via > > >>> itself. > > >>> > > >>> 1. Currently we compile with es 0.19. If somebody wants to run es > 0.20 > > >> they > > >>> have to recompile (es made an interface change that is source > > compatible > > >>> but requires a recompile). es 0.90 has been out for 2-ish weeks so > safe > > >>> enough to change the compile to. I think I'll raise an empty Jira to > > >> record > > >>> this. > > >>> > > >>> 2. I haven't reported this because I haven't isolated it well enough. > > I'm > > >>> having issues with the 1.3.1 file channel which I'd like to resolve. > > >>> > > >>> Cheers, > > >>> Edward > > >>> > > >>> "Hi folks, > > >>> We have had over 100 commits since 1.3.1, and a bunch of new features > > and > > >>> improvements including a Thrift source, much improved ElasticSearch > > sink, > > >>> support for a new plugins directory and layout, compression support > in > > >> the > > >>> avro sink/source, improved checkpointing in the file channel and > more, > > >> plus > > >>> a lot of bug fixes. > > >>> > > >>> It seems to me that it's time to start thinking about cutting a 1.4 > > >>> release. I would be happy to volunteer to RM the release. Worth > noting > > >> that > > >>> I will be unavailable for the next two weeks... but after that I'd be > > >> happy > > >>> to pick this up and run with it. That's also a decent amount of time > > for > > >>> people to get moving on patches and reviews for their favorite > > features, > > >>> bug fixes, etc. > > >>> > > >>> If this all sounds OK, I'd like to suggest targeting the last week of > > >> June > > >>> as a release date. If we can release in time for Hadoop Summit then > > that > > >>> would be pretty nice. Otherwise, if something comes up and we can't > get > > >> the > > >>> release out that week, let's shoot for the first week of July at the > > >> latest. > > >>> > > >>> Please let me know your thoughts. > > >>> > > >>> Regards, > > >>> Mike > > >>> > > >>> +1 for Flume 1.4 > > >>> +1 for Mike being RM. > > >>> > > >>> > > >>> Cheers, > > >>> Hari" > > >> > > > > > -- Apache MRUnit - Unit testing MapReduce - http://mrunit.apache.org
Re: [DISCUSS] Flume 1.4 release plan
+1 for both (non binding) On Wed, May 22, 2013 at 10:41 AM, Mubarak Seyed wrote: > +1 for Flume 1.4 > +1 for Mike being RM > > > -Mubarak > > On May 22, 2013, at 9:51 AM, Venkatesh S R wrote: > > > +1 for both! Thanks Mike! > > > > Best, > > Venkatesh > > > > > > On Wed, May 22, 2013 at 9:41 AM, Will McQueen wrote: > > > >> +1 for Flume 1.4 > >> +1 for Mike being RM. > >> > >> On May 22, 2013, at 9:28 AM, Edward Sargisson wrote: > >> > >>> Hi All, > >>> +1/+1 for 1.4 and Mike. > >>> > >>> > >>> I'm very keen to have a 1.4 for the environments I manage. There's a > lot > >> of > >>> stuff I'm keen on in there. > >>> > >>> On my pre-1.4 list: > >>> 1. compile with elasticsearch 0.90 > >>> 2. figure out file channel state issue which is stopping Flume logging > >> via > >>> itself. > >>> > >>> 1. Currently we compile with es 0.19. If somebody wants to run es 0.20 > >> they > >>> have to recompile (es made an interface change that is source > compatible > >>> but requires a recompile). es 0.90 has been out for 2-ish weeks so safe > >>> enough to change the compile to. I think I'll raise an empty Jira to > >> record > >>> this. > >>> > >>> 2. I haven't reported this because I haven't isolated it well enough. > I'm > >>> having issues with the 1.3.1 file channel which I'd like to resolve. > >>> > >>> Cheers, > >>> Edward > >>> > >>> "Hi folks, > >>> We have had over 100 commits since 1.3.1, and a bunch of new features > and > >>> improvements including a Thrift source, much improved ElasticSearch > sink, > >>> support for a new plugins directory and layout, compression support in > >> the > >>> avro sink/source, improved checkpointing in the file channel and more, > >> plus > >>> a lot of bug fixes. > >>> > >>> It seems to me that it's time to start thinking about cutting a 1.4 > >>> release. I would be happy to volunteer to RM the release. Worth noting > >> that > >>> I will be unavailable for the next two weeks... but after that I'd be > >> happy > >>> to pick this up and run with it. That's also a decent amount of time > for > >>> people to get moving on patches and reviews for their favorite > features, > >>> bug fixes, etc. > >>> > >>> If this all sounds OK, I'd like to suggest targeting the last week of > >> June > >>> as a release date. If we can release in time for Hadoop Summit then > that > >>> would be pretty nice. Otherwise, if something comes up and we can't get > >> the > >>> release out that week, let's shoot for the first week of July at the > >> latest. > >>> > >>> Please let me know your thoughts. > >>> > >>> Regards, > >>> Mike > >>> > >>> +1 for Flume 1.4 > >>> +1 for Mike being RM. > >>> > >>> > >>> Cheers, > >>> Hari" > >> > >
Re: [DISCUSS] Flume 1.4 release plan
+1 for Flume 1.4 +1 for Mike being RM -Mubarak On May 22, 2013, at 9:51 AM, Venkatesh S R wrote: > +1 for both! Thanks Mike! > > Best, > Venkatesh > > > On Wed, May 22, 2013 at 9:41 AM, Will McQueen wrote: > >> +1 for Flume 1.4 >> +1 for Mike being RM. >> >> On May 22, 2013, at 9:28 AM, Edward Sargisson wrote: >> >>> Hi All, >>> +1/+1 for 1.4 and Mike. >>> >>> >>> I'm very keen to have a 1.4 for the environments I manage. There's a lot >> of >>> stuff I'm keen on in there. >>> >>> On my pre-1.4 list: >>> 1. compile with elasticsearch 0.90 >>> 2. figure out file channel state issue which is stopping Flume logging >> via >>> itself. >>> >>> 1. Currently we compile with es 0.19. If somebody wants to run es 0.20 >> they >>> have to recompile (es made an interface change that is source compatible >>> but requires a recompile). es 0.90 has been out for 2-ish weeks so safe >>> enough to change the compile to. I think I'll raise an empty Jira to >> record >>> this. >>> >>> 2. I haven't reported this because I haven't isolated it well enough. I'm >>> having issues with the 1.3.1 file channel which I'd like to resolve. >>> >>> Cheers, >>> Edward >>> >>> "Hi folks, >>> We have had over 100 commits since 1.3.1, and a bunch of new features and >>> improvements including a Thrift source, much improved ElasticSearch sink, >>> support for a new plugins directory and layout, compression support in >> the >>> avro sink/source, improved checkpointing in the file channel and more, >> plus >>> a lot of bug fixes. >>> >>> It seems to me that it's time to start thinking about cutting a 1.4 >>> release. I would be happy to volunteer to RM the release. Worth noting >> that >>> I will be unavailable for the next two weeks... but after that I'd be >> happy >>> to pick this up and run with it. That's also a decent amount of time for >>> people to get moving on patches and reviews for their favorite features, >>> bug fixes, etc. >>> >>> If this all sounds OK, I'd like to suggest targeting the last week of >> June >>> as a release date. If we can release in time for Hadoop Summit then that >>> would be pretty nice. Otherwise, if something comes up and we can't get >> the >>> release out that week, let's shoot for the first week of July at the >> latest. >>> >>> Please let me know your thoughts. >>> >>> Regards, >>> Mike >>> >>> +1 for Flume 1.4 >>> +1 for Mike being RM. >>> >>> >>> Cheers, >>> Hari" >>
Re: [DISCUSS] Flume 1.4 release plan
+1 for both! Thanks Mike! Best, Venkatesh On Wed, May 22, 2013 at 9:41 AM, Will McQueen wrote: > +1 for Flume 1.4 > +1 for Mike being RM. > > On May 22, 2013, at 9:28 AM, Edward Sargisson wrote: > > > Hi All, > > +1/+1 for 1.4 and Mike. > > > > > > I'm very keen to have a 1.4 for the environments I manage. There's a lot > of > > stuff I'm keen on in there. > > > > On my pre-1.4 list: > > 1. compile with elasticsearch 0.90 > > 2. figure out file channel state issue which is stopping Flume logging > via > > itself. > > > > 1. Currently we compile with es 0.19. If somebody wants to run es 0.20 > they > > have to recompile (es made an interface change that is source compatible > > but requires a recompile). es 0.90 has been out for 2-ish weeks so safe > > enough to change the compile to. I think I'll raise an empty Jira to > record > > this. > > > > 2. I haven't reported this because I haven't isolated it well enough. I'm > > having issues with the 1.3.1 file channel which I'd like to resolve. > > > > Cheers, > > Edward > > > > "Hi folks, > > We have had over 100 commits since 1.3.1, and a bunch of new features and > > improvements including a Thrift source, much improved ElasticSearch sink, > > support for a new plugins directory and layout, compression support in > the > > avro sink/source, improved checkpointing in the file channel and more, > plus > > a lot of bug fixes. > > > > It seems to me that it's time to start thinking about cutting a 1.4 > > release. I would be happy to volunteer to RM the release. Worth noting > that > > I will be unavailable for the next two weeks... but after that I'd be > happy > > to pick this up and run with it. That's also a decent amount of time for > > people to get moving on patches and reviews for their favorite features, > > bug fixes, etc. > > > > If this all sounds OK, I'd like to suggest targeting the last week of > June > > as a release date. If we can release in time for Hadoop Summit then that > > would be pretty nice. Otherwise, if something comes up and we can't get > the > > release out that week, let's shoot for the first week of July at the > latest. > > > > Please let me know your thoughts. > > > > Regards, > > Mike > > > > +1 for Flume 1.4 > > +1 for Mike being RM. > > > > > > Cheers, > > Hari" >
Re: [DISCUSS] Flume 1.4 release plan
+1 for Flume 1.4 +1 for Mike being RM. On May 22, 2013, at 9:28 AM, Edward Sargisson wrote: > Hi All, > +1/+1 for 1.4 and Mike. > > > I'm very keen to have a 1.4 for the environments I manage. There's a lot of > stuff I'm keen on in there. > > On my pre-1.4 list: > 1. compile with elasticsearch 0.90 > 2. figure out file channel state issue which is stopping Flume logging via > itself. > > 1. Currently we compile with es 0.19. If somebody wants to run es 0.20 they > have to recompile (es made an interface change that is source compatible > but requires a recompile). es 0.90 has been out for 2-ish weeks so safe > enough to change the compile to. I think I'll raise an empty Jira to record > this. > > 2. I haven't reported this because I haven't isolated it well enough. I'm > having issues with the 1.3.1 file channel which I'd like to resolve. > > Cheers, > Edward > > "Hi folks, > We have had over 100 commits since 1.3.1, and a bunch of new features and > improvements including a Thrift source, much improved ElasticSearch sink, > support for a new plugins directory and layout, compression support in the > avro sink/source, improved checkpointing in the file channel and more, plus > a lot of bug fixes. > > It seems to me that it's time to start thinking about cutting a 1.4 > release. I would be happy to volunteer to RM the release. Worth noting that > I will be unavailable for the next two weeks... but after that I'd be happy > to pick this up and run with it. That's also a decent amount of time for > people to get moving on patches and reviews for their favorite features, > bug fixes, etc. > > If this all sounds OK, I'd like to suggest targeting the last week of June > as a release date. If we can release in time for Hadoop Summit then that > would be pretty nice. Otherwise, if something comes up and we can't get the > release out that week, let's shoot for the first week of July at the latest. > > Please let me know your thoughts. > > Regards, > Mike > > +1 for Flume 1.4 > +1 for Mike being RM. > > > Cheers, > Hari"
Re: [DISCUSS] Flume 1.4 release plan
Hi All, +1/+1 for 1.4 and Mike. I'm very keen to have a 1.4 for the environments I manage. There's a lot of stuff I'm keen on in there. On my pre-1.4 list: 1. compile with elasticsearch 0.90 2. figure out file channel state issue which is stopping Flume logging via itself. 1. Currently we compile with es 0.19. If somebody wants to run es 0.20 they have to recompile (es made an interface change that is source compatible but requires a recompile). es 0.90 has been out for 2-ish weeks so safe enough to change the compile to. I think I'll raise an empty Jira to record this. 2. I haven't reported this because I haven't isolated it well enough. I'm having issues with the 1.3.1 file channel which I'd like to resolve. Cheers, Edward "Hi folks, We have had over 100 commits since 1.3.1, and a bunch of new features and improvements including a Thrift source, much improved ElasticSearch sink, support for a new plugins directory and layout, compression support in the avro sink/source, improved checkpointing in the file channel and more, plus a lot of bug fixes. It seems to me that it's time to start thinking about cutting a 1.4 release. I would be happy to volunteer to RM the release. Worth noting that I will be unavailable for the next two weeks... but after that I'd be happy to pick this up and run with it. That's also a decent amount of time for people to get moving on patches and reviews for their favorite features, bug fixes, etc. If this all sounds OK, I'd like to suggest targeting the last week of June as a release date. If we can release in time for Hadoop Summit then that would be pretty nice. Otherwise, if something comes up and we can't get the release out that week, let's shoot for the first week of July at the latest. Please let me know your thoughts. Regards, Mike +1 for Flume 1.4 +1 for Mike being RM. Cheers, Hari"
Re: [DISCUSS] Flume 1.4 release plan
+1 (non-binding) for both! Thanks for the effort, Mike! On May 22, 2013, at 10:09 AM, Jarek Jarcec Cecho wrote: > +1 for releasing Flume 1.4 > +1 for Mike being the RM for this release > > Jarcec > > On Wed, May 22, 2013 at 01:02:06AM -0700, Arvind Prabhakar wrote: >> Thanks for taking this initiative Mike! >> >> +1 for 1.4 and Mike as RM. >> >> Regards, >> Arvind Prabhakar >> >> On Wed, May 22, 2013 at 12:45 AM, Hari Shreedharan < >> hshreedha...@cloudera.com> wrote: >> >>> +1 for Flume 1.4 >>> +1 for Mike being RM. >>> >>> >>> Cheers, >>> Hari >>> >>> >>> On Wednesday, May 22, 2013 at 12:33 AM, Mike Percy wrote: >>> Hi folks, We have had over 100 commits since 1.3.1, and a bunch of new features and improvements including a Thrift source, much improved ElasticSearch sink, support for a new plugins directory and layout, compression support in >>> the avro sink/source, improved checkpointing in the file channel and more, >>> plus a lot of bug fixes. It seems to me that it's time to start thinking about cutting a 1.4 release. I would be happy to volunteer to RM the release. Worth noting >>> that I will be unavailable for the next two weeks... but after that I'd be >>> happy to pick this up and run with it. That's also a decent amount of time for people to get moving on patches and reviews for their favorite features, bug fixes, etc. If this all sounds OK, I'd like to suggest targeting the last week of >>> June as a release date. If we can release in time for Hadoop Summit then that would be pretty nice. Otherwise, if something comes up and we can't get >>> the release out that week, let's shoot for the first week of July at the >>> latest. Please let me know your thoughts. Regards, Mike >>> >>> >>> -- Alexander Alten-Lorenz http://mapredit.blogspot.com German Hadoop LinkedIn Group: http://goo.gl/N8pCF
Re: [DISCUSS] Flume 1.4 release plan
+1 for releasing Flume 1.4 +1 for Mike being the RM for this release Jarcec On Wed, May 22, 2013 at 01:02:06AM -0700, Arvind Prabhakar wrote: > Thanks for taking this initiative Mike! > > +1 for 1.4 and Mike as RM. > > Regards, > Arvind Prabhakar > > On Wed, May 22, 2013 at 12:45 AM, Hari Shreedharan < > hshreedha...@cloudera.com> wrote: > > > +1 for Flume 1.4 > > +1 for Mike being RM. > > > > > > Cheers, > > Hari > > > > > > On Wednesday, May 22, 2013 at 12:33 AM, Mike Percy wrote: > > > > > Hi folks, > > > We have had over 100 commits since 1.3.1, and a bunch of new features and > > > improvements including a Thrift source, much improved ElasticSearch sink, > > > support for a new plugins directory and layout, compression support in > > the > > > avro sink/source, improved checkpointing in the file channel and more, > > plus > > > a lot of bug fixes. > > > > > > It seems to me that it's time to start thinking about cutting a 1.4 > > > release. I would be happy to volunteer to RM the release. Worth noting > > that > > > I will be unavailable for the next two weeks... but after that I'd be > > happy > > > to pick this up and run with it. That's also a decent amount of time for > > > people to get moving on patches and reviews for their favorite features, > > > bug fixes, etc. > > > > > > If this all sounds OK, I'd like to suggest targeting the last week of > > June > > > as a release date. If we can release in time for Hadoop Summit then that > > > would be pretty nice. Otherwise, if something comes up and we can't get > > the > > > release out that week, let's shoot for the first week of July at the > > latest. > > > > > > Please let me know your thoughts. > > > > > > Regards, > > > Mike > > > > > > > > > > > > signature.asc Description: Digital signature
Re: [DISCUSS] Flume 1.4 release plan
Thanks for taking this initiative Mike! +1 for 1.4 and Mike as RM. Regards, Arvind Prabhakar On Wed, May 22, 2013 at 12:45 AM, Hari Shreedharan < hshreedha...@cloudera.com> wrote: > +1 for Flume 1.4 > +1 for Mike being RM. > > > Cheers, > Hari > > > On Wednesday, May 22, 2013 at 12:33 AM, Mike Percy wrote: > > > Hi folks, > > We have had over 100 commits since 1.3.1, and a bunch of new features and > > improvements including a Thrift source, much improved ElasticSearch sink, > > support for a new plugins directory and layout, compression support in > the > > avro sink/source, improved checkpointing in the file channel and more, > plus > > a lot of bug fixes. > > > > It seems to me that it's time to start thinking about cutting a 1.4 > > release. I would be happy to volunteer to RM the release. Worth noting > that > > I will be unavailable for the next two weeks... but after that I'd be > happy > > to pick this up and run with it. That's also a decent amount of time for > > people to get moving on patches and reviews for their favorite features, > > bug fixes, etc. > > > > If this all sounds OK, I'd like to suggest targeting the last week of > June > > as a release date. If we can release in time for Hadoop Summit then that > > would be pretty nice. Otherwise, if something comes up and we can't get > the > > release out that week, let's shoot for the first week of July at the > latest. > > > > Please let me know your thoughts. > > > > Regards, > > Mike > > > > > > >
Re: [DISCUSS] Flume 1.4 release plan
+1 for Flume 1.4 +1 for Mike being RM. Cheers, Hari On Wednesday, May 22, 2013 at 12:33 AM, Mike Percy wrote: > Hi folks, > We have had over 100 commits since 1.3.1, and a bunch of new features and > improvements including a Thrift source, much improved ElasticSearch sink, > support for a new plugins directory and layout, compression support in the > avro sink/source, improved checkpointing in the file channel and more, plus > a lot of bug fixes. > > It seems to me that it's time to start thinking about cutting a 1.4 > release. I would be happy to volunteer to RM the release. Worth noting that > I will be unavailable for the next two weeks... but after that I'd be happy > to pick this up and run with it. That's also a decent amount of time for > people to get moving on patches and reviews for their favorite features, > bug fixes, etc. > > If this all sounds OK, I'd like to suggest targeting the last week of June > as a release date. If we can release in time for Hadoop Summit then that > would be pretty nice. Otherwise, if something comes up and we can't get the > release out that week, let's shoot for the first week of July at the latest. > > Please let me know your thoughts. > > Regards, > Mike > >
[DISCUSS] Flume 1.4 release plan
Hi folks, We have had over 100 commits since 1.3.1, and a bunch of new features and improvements including a Thrift source, much improved ElasticSearch sink, support for a new plugins directory and layout, compression support in the avro sink/source, improved checkpointing in the file channel and more, plus a lot of bug fixes. It seems to me that it's time to start thinking about cutting a 1.4 release. I would be happy to volunteer to RM the release. Worth noting that I will be unavailable for the next two weeks... but after that I'd be happy to pick this up and run with it. That's also a decent amount of time for people to get moving on patches and reviews for their favorite features, bug fixes, etc. If this all sounds OK, I'd like to suggest targeting the last week of June as a release date. If we can release in time for Hadoop Summit then that would be pretty nice. Otherwise, if something comes up and we can't get the release out that week, let's shoot for the first week of July at the latest. Please let me know your thoughts. Regards, Mike
