Re: [DISCUSS] Flume 1.9 release proposal

Thank you for the notification, it will be included. The RC is still in progress as some minor issue came up during the release process. On Tue, Dec 4, 2018 at 3:41 PM Ralph Goers wrote: > I am noticing that the release notes on the 1.9 branch have not been > updated to say changes to the

Re: [DISCUSS] Flume 1.9 release proposal

I am noticing that the release notes on the 1.9 branch have not been updated to say changes to the logging configuration will be required in the next release as it will be upgraded to Log4j 2. Ralph > On Nov 30, 2018, at 8:33 PM, Ralph Goers wrote: > > Ok, I’m fine with that. > > Ralph >

Re: [DISCUSS] Flume 1.9 release proposal

Ok, I’m fine with that. Ralph > On Nov 30, 2018, at 3:31 PM, Mike Percy wrote: > > Hi Ralph, > Let’s update the release notes to indicate that it is coming and do it in the > next release so people are forewarned of the change. After speaking with > others it sounds like Flume users are

Re: [DISCUSS] Flume 1.9 release proposal

Hi Ralph, Let’s update the release notes to indicate that it is coming and do it in the next release so people are forewarned of the change. After speaking with others it sounds like Flume users are willing to accept the change (some have already had to do it because of Solr) so I have changed

Re: [DISCUSS] Flume 1.9 release proposal

Mike, This response confuses me. Are you saying that because the customers are good with the config change Flume 1.9 can go out with Log4j 2 or are you saying you are good with updating the release notes to say it will happen in the next release? Ralph > On Nov 29, 2018, at 10:53 PM, Mike

Re: [DISCUSS] Flume 1.9 release proposal

After speaking with a couple of large users of Flume, because log4j2 is ABI compatible with log4j1 It sounds like the config change will be acceptable to them at upgrade time and so I am +1 on this proposal. Regards, Mike > On Nov 28, 2018, at 5:37 AM, Ralph Goers wrote: > > Again, please

Re: [DISCUSS] Flume 1.9 release proposal

Again, please update the release notes to indicate the logging configuration change will be coming with the next release. Ralph > On Nov 28, 2018, at 1:17 AM, Denes Arvay wrote: > > Hi All, > > I agree that the current content doesn't justify the 2.0 release, so I'd > vote for moving forward

Re: [DISCUSS] Flume 1.9 release proposal

Hi All, I agree that the current content doesn't justify the 2.0 release, so I'd vote for moving forward with the 1.9 as Ferenc recommended, i.e. without the 2 previously mentioned breaking changes. I also agree with the proposed new features, especially with the plugin system/modularization,

Re: [DISCUSS] Flume 1.9 release proposal

While Log4j 2 supports using properties files for configuration it is not syntactically compatible with Log4j 1. However, migrating a Log4j 1 configuration to Log4j 2 isn’t a difficult task. Ralph > On Nov 27, 2018, at 4:38 AM, Tristan Stevens > wrote: > > I did start thinking a while back

Re: [DISCUSS] Flume 1.9 release proposal

I did start thinking a while back about a REST API that could be used for configuring Flume, after which you could potentially bolt on a UI. I stopped work on it because it got tricky around configuring sources (and the way in which they relate to channels etc). If someone had more time I’d be

Re: [DISCUSS] Flume 1.9 release proposal

Since users were invited for comment I’ll simply say that for us having to change a bit of logging config is the least of worries, maybe an hour to deploy to ECS. Honestly making the code base more accessible to casual contributors, a plugin system and more frequent releases of connectors is

Re: [DISCUSS] Flume 1.9 release proposal

Yeah, I agree with this, especially classloader isolation would be great to have as well on the plugin side. Mike On Mon, Nov 26, 2018 at 11:50 AM Ralph Goers wrote: > I think people want to do more than just upgrade Log4j for a Flume 2.0 > release. I would like to make configuration much more

Re: [DISCUSS] Flume 1.9 release proposal

I think people want to do more than just upgrade Log4j for a Flume 2.0 release. I would like to make configuration much more pluggable for example. There was also talk about splitting all the sources, sinks, interceptors, etc out of the core module and making them some sort of plugin. At this

Re: [DISCUSS] Flume 1.9 release proposal

I wonder, is there anything blocking us from releasing 2.0 next instead of 1.x? Donat On Mon, Nov 26, 2018 at 6:27 PM Mike Percy wrote: > > If only the PMC would be affected by this decision, we could have had this > discussion on the PMC private list. But this decision impacts everybody >

Re: [DISCUSS] Flume 1.9 release proposal

If only the PMC would be affected by this decision, we could have had this discussion on the PMC private list. But this decision impacts everybody that uses Flume. So let's hear from anybody who cares about this, including committers, contributors, and users on whether they are okay with switching

Re: [DISCUSS] Flume 1.9 release proposal

I have directed it to the community, the PMC members. I am looking for a decision from the PMC members (including You) on whether we should continue as planned or not removing log4j2 form the minor release branch. On Mon, Nov 26, 2018 at 2:43 PM Ralph Goers wrote: > Was this directed at me? I

Re: [DISCUSS] Flume 1.9 release proposal

Was this directed at me? I am not sure what decision you are referring to. I stated my position in the email you replied to. Ralph > On Nov 26, 2018, at 5:29 AM, Ferenc Szabo wrote: > > With the new release, you can just replace the jars on the classpath as we > removed every code dependency

Re: [DISCUSS] Flume 1.9 release proposal

With the new release, you can just replace the jars on the classpath as we removed every code dependency and using slf4j. So you do not need to fork and change anything. Let me know your decision and we will continue with that. Regards, Ferenc On Mon, Nov 26, 2018 at 12:10 PM Apache wrote: >

Re: [DISCUSS] Flume 1.9 release proposal

As I said, I am fine with adding a notice to the release notes stating the logging will be changed in the next release regardless of its version number. This way the revert only needs to happen on the release branch for this release. Ralph > On Nov 25, 2018, at 9:59 PM, Mike Percy wrote: > >

Re: [DISCUSS] Flume 1.9 release proposal

While the committer veto rules are well documented here , and there is no mention of a time limit, I propose we shelve that discussion and work on getting to consensus on what we as a community want to include in the Flume 1.9 release. As far as

Re: [DISCUSS] Flume 1.9 release proposal

I should also point out that the time to raise this was a year ago when the PR for FLUME-2050 was reviewed and committed. As it stands now I could be a jerk and vote -1 on the patch for FLUME-3296 with valid technical grounds. If this was causing a true binary incompatibility I would approve

Re: [DISCUSS] Flume 1.9 release proposal

One of the security issues is https://www.cvedetails.com/cve/CVE-2017-5645/ . It is reported against log4j 2 because Log4j 1 is EOL, but the same vulnerability exists there. RedHat has created a fix for Log4j 1 for its Linux distribution [1] but I

Re: [DISCUSS] Flume 1.9 release proposal

I wasn't aware of this security issue. Do you have a link to the details? There's no ASF requirement for package names; it's really just a Java language convention, and especially not enforced for compatibility shims. Even Flume has some of those in the legacy sources. I understand that it's

Re: [DISCUSS] Flume 1.9 release proposal

> On Nov 24, 2018, at 2:35 PM, Mike Percy wrote: > > Flume has long had a policy of backwards compatibility with its own > configuration files and people expect things to "just work" when upgrading > Flume. If log4j2 can't parse the log4j1 config file format then it's an > incompatible upgrade

Re: [DISCUSS] Flume 1.9 release proposal

Flume has long had a policy of backwards compatibility with its own configuration files and people expect things to "just work" when upgrading Flume. If log4j2 can't parse the log4j1 config file format then it's an incompatible upgrade and should not be done in a minor Flume release. If log4j2

Re: [DISCUSS] Flume 1.9 release proposal

No, you are correct. However, requiring a change to logging configuration has never been considered a binary compatibility break in any project I have ever worked on. Ralph > On Nov 23, 2018, at 10:05 AM, Ferenc Szabo > wrote: > > As you mentioned, you have the freedom to use Log4j 2 and

Re: [DISCUSS] Flume 1.9 release proposal

Sure, we will wait. Thank you for your remarks! On Fri, Nov 23, 2018 at 6:04 PM Ralph Goers wrote: > I should also note that since today is a semi-holiday in the US please do > not commit anything with regards to this until this is cleared up as I may > or may not be able to respond

Re: [DISCUSS] Flume 1.9 release proposal

As you mentioned, you have the freedom to use Log4j 2 and the same time we have to keep the out of the box experience the same in a minor version. Users should be able to upgrade flume without changing any of their configurations. If they have a log4j.properties (Log4j 1) then they would not be

Re: [DISCUSS] Flume 1.9 release proposal

I should also note that since today is a semi-holiday in the US please do not commit anything with regards to this until this is cleared up as I may or may not be able to respond immediately. Ralph > On Nov 23, 2018, at 9:47 AM, Ralph Goers wrote: > > I do not understand this at all. Log4j

Re: [DISCUSS] Flume 1.9 release proposal

Also, please put details in the Jira issues. It is much easier to find out why something was done by searching Jira later on then searching the mailing list. Ralph > On Nov 23, 2018, at 9:47 AM, Ralph Goers wrote: > > I do not understand this at all. Log4j 2 provides runtime compatibility

Re: [DISCUSS] Flume 1.9 release proposal

I do not understand this at all. Log4j 2 provides runtime compatibility with Log4j 1. What is the problem that requires a revert? I have been running Flume with Log4j 2 since 1.6 so I don’t understand what the problem could possibly be. Ralph > On Nov 23, 2018, at 8:50 AM, Ferenc Szabo

Re: [DISCUSS] Flume 1.9 release proposal

Hi Ferenc, Thank you for your effort on the release so far. I definitely agree that those breaking changes should be deferred to the 2.0 release, so +1 from me for your plan. Feel free to ping me if you need any assistance on creating the RC. Regards, Denes On Fri, Nov 23, 2018, 16:50 Ferenc

Re: [DISCUSS] Flume 1.9 release proposal

Hi everyone I am about to branch the 1.9 release from trunk. On the 1.9 branch we will revert the following breaking changes: - FLUME-2957. Remove Guava from our public API: https://github.com/apache/flume/commit/7f85df9e473ee675d461d5b76650694c5a6c0088 - part of FLUME-2050. Upgrade to Log4j

Re: [DISCUSS] Flume 1.9 release proposal

Hi Ferenc, +1 I am working on FLUME-3281 Update to Kafka 2.0 client, should be able to finish it till the suggested deadline. I am also happy to do some reviews. Regards Endre On 2018/11/06 21:23:17, Ferenc Szabo wrote: > Hello Flume Community, > > 1.8 was released about a year ago and

Re: [DISCUSS] Flume 1.9 release proposal

Hi Ferenc, +1 Please let me know if I can help you in any way. At the moment I am working on FLUME-3133 (PR is expected tomorrow) which can be added to the release too. Then I will continue with reviewing the PR-s. Regards, Peter On Wed, Nov 7, 2018 at 8:56 AM Bessenyei Balázs Donát wrote: >

Re: [DISCUSS] Flume 1.9 release proposal

Hi Ferenc, Thanks for volunteering to RM! +1 from me on this proposal. I am also happy to help with anything that requires PMC access, just let me know if there is anything I can do to help. Donat On Wed, Nov 7, 2018, 03:08 Mike Percy Hi Ferenc, > Thanks for volunteering to RM! > > +1 from