[jira] [Created] (RANGER-1612) When servicedef is accessed, one of the properties "enableDenyPolicies" is returned as "false" if there is no value set for it.

[Anuja Leekha (JIRA)]

Anuja Leekha created RANGER-1612:


 Summary: When servicedef is accessed, one of the properties 
"enableDenyPolicies" is returned as "false" if there is no value set for it.
 Key: RANGER-1612
 URL: https://issues.apache.org/jira/browse/RANGER-1612
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Reporter: Anuja Leekha
 Fix For: 1.0.0, 0.7.1


During the migration of hive service def When servicedef is accessed, one of 
the properties "enableDenyPolicies" is returned as "false" if there is no value 
set for it. 
Now, hive service def has changed (because URL as a resource is added to it). 
So when servicedef is updated, enableDenyPolicies property is updated in the 
database to be "false" which should not happen.
The migration script for service-def needs to check what the real value of this 
property is in the database and preserve it across migration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: 答复: Re: Patches with trivial changes

[Madhan Neethiraj]

Colm, Peng.jianhua,

 

> I will encourage future review requests that have a very trivial spelling

> fix to hold on to the fix for a while, so that we can fix multiple spelling

> fixes etc. at the same time.

Consolidating trivial updates into a single patch/JIRA will certainly help.

However, in my experience, such changes do add overheads while

backporting fixes – and as Peng.jianhua rightly pointed out, they add risk

of introducing an error. My suggestion is to avoid updates that solely focus

on trivial changes.

 

> Yes it may make backporting fixes a little more difficult, but it's hardly

> an intractable problem to figure out some whitespace changes between

> branches - it's not as if Ranger is a particularly large project.

The overhead is not only in backporting, but also to folks who currently

have updates (for bug fixes or features) in files modified for trivial changes.

Once again, my suggestion is to avoid updates that solely focus on trivial

changes.

 

> At the same time, we should strictly control the quality of the code

> to avoid similar problems.

Yes, I totally agree here. The more effort we take before a patch make

its way in, the better it is for the project.

 

Thanks,

Madhan

 

From: "peng.jian...@zte.com.cn" 
Reply-To: "dev@ranger.apache.org" 
Date: Wednesday, May 24, 2017 at 2:28 AM
To: "dev@ranger.apache.org" , 
"comm...@ranger.apache.org" 
Subject: 答复: Re: Patches with trivial changes

 

Hi Madhan,

 

Merging these small issues to other branches will increase the workload and the 
probability of error. If possible, we can undertake similar tasks when some 
important issues need to be merged into other branches. 

 

With the improvement of quality, these small issues will be gradually reduced 
until the last disappear. The current difficulties will gradually reduce if we 
continue to handle these issues. Otherwise with the function of the perfect, 
such small issue will be accumulated and increased.

At the same time, we should strictly control the quality of the code to avoid 
similar problems.

 

We will respect your opinion and control the quality of the code.

 

Peng.jianhua


发件人： ＜cohei...@apache.org＞;

收件人： ＜dev@ranger.apache.org＞;

抄送人： ＜comm...@ranger.apache.org＞;

日 期 ：2017年05月24日 16:49

主 题 ：Re: Patches with trivial changes

 

Hi Madhan,

Trivial commits provide a path to get new contributors on board to the
project - something that the project needs IMO. Yes it may make backporting
fixes a little more difficult, but it's hardly an intractable problem to
figure out some whitespace changes between branches - it's not as if Ranger
is a particularly large project.

Having said that I agree that some of the very trivial patches could maybe
be consolidated a bit more. I will encourage future review requests that
have a very trivial spelling fix to hold on to the fix for a while, so that
we can fix multiple spelling fixes etc. at the same time.

Colm.

On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj ＜mad...@apache.org＞ wrote:

＞ All,
＞
＞
＞
＞ I notice a number of recent patches address trivial issues like white
＞ space, spelling mistakes (one patch just changed a single letter in a
＞ label). And few other patches update a large number of files for
＞ trivial/non-functional changes – like whitespaces. I strongly suggest we
＞ refrain from authoring/encouraging such patches – for many reasons. One of
＞ the main reasons is the overhead such updates add in backporting
＞ real/critical fixes (that would come later) to other branches, as these
＞ changes might force dealing with merge conflicts.
＞
＞
＞
＞ Since the changes introduced in such patches are not essential, I would
＞ suggest to take these up when these source files are updated for other
＞ functional fixes. I would greatly appreciate if the patches focus on
＞ fixing/enhancing Ranger functionality; this would be benefit the community
＞ immensely.
＞
＞
＞
＞ Thanks,
＞
＞ Madhan
＞
＞
＞



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

 

 

Re: Patches with trivial changes

[Madhan Neethiraj]

Zsombor,

>> Instead of discouraging contributions
My suggestion was to discourage patches that have *only* very, very tiny and 
non-essential updates – like changing case of a label word from “G” to “g”, 
removing a blank line, etc; or patches that touch hundreds of files for 
trivial/non-essential updates. I think these can’t be a way to ease into the 
project. A better way would be to take time to understand the project 
functionality and contribute towards enhancing it. I think an excellent example 
in this regard would be Colm’s initial contributions, which significantly 
improved the unit test coverage for Ranger plugins. It will help the Ranger 
community immensely if contributors take such a path.

>> Is there any particular reason, why the current workflow used as is ?
Ranger community has been using review-board since its beginning, and it seems 
to be working well. Many Apache project do use this approach.

As new contributors join the community, their experience/expectation might be 
different. Use of ‘pull requests’ to deal with patch/review/merge was suggested 
sometime back as well. I think we should give this a shot, to find if this 
approach makes it easier for everyone. However, bear in mind that people might 
have bias towards a specific approach, based on their prior experience and 
comfort level. Forcing everyone to change might take effort/time.

Thanks,
Madhan


On 5/24/17, 4:31 AM, "Zsombor"  wrote:

Instead of discouraging contributions, the project should ease the
contribution - and also the review process.
The current JIRA + Reviewboard infrastructure needs a lot's of unnecessary
manual steps, which hurts everyone who wants to help.
 Currently, the contributor needs to do the following, after they have a
working commit in their git repository
1, open a jira ticket
2, generate a patch from git
2, create a review boad request, uploading the patch to it
3, upload the patch to jira
4, if something is not correct, they have to repeat 2-3.

Similarly, for the reviewer, he has to manually download, apply, and run
the tests locally, even when he thinks the patch is ok.

My suggestion is to switch to a pull request based workflow, where the
manual patch creation, upload-download process could be omitted, and travis
or some other automatic build service should be introduced, to ensure, that
the base sanity tests are not omitted accidentally.
 With this process, a commiter could review and approve a trivial commits
in less than a minute.

Is there any particular reason, why the current workflow used as is ?

Regards,
 Zsombor


On Wed, May 24, 2017 at 12:28 PM, Gautam Borad  wrote:

> +1 for Madhan's recommendations,
>
> Colm, I agree that we should not discourage new contributions. However, I
> think, we should also not encourage such single line/whitespace
> contributions. We want contributors who can do more functionals/feature
> changes and while doing that they can also fix the trivial issues
> (whitespace etc)
>
> Since each contribution to Ranger requires creating Jira/RR, if we start
> having lot of such trivial contributions, the community will be 
overwhelmed
> with activities(mails etc) like this and that can lead to ignoring of a
> real functional change, when it comes.
>
> In fact, the Apache page on Contributors itself says :
>
> "Being a contributor simply means that you take an interest in the project
> and contribute in some way, ranging from asking sensible questions (which
> documents the project and provides feedback to developers) through to
> providing *new features* as patches."
>
>
> So yes, we should encourage contributors, but encourage them to try and
> understand Ranger and add more features/functionalities and eventually
> "earn" the title of a committer. Thanks.
>
>
>
> On Wed, May 24, 2017 at 2:19 PM, Colm O hEigeartaigh 
> wrote:
>
> > Hi Madhan,
> >
> > Trivial commits provide a path to get new contributors on board to the
> > project - something that the project needs IMO. Yes it may make
> backporting
> > fixes a little more difficult, but it's hardly an intractable problem to
> > figure out some whitespace changes between branches - it's not as if
> Ranger
> > is a particularly large project.
> >
> > Having said that I agree that some of the very trivial patches could
> maybe
> > be consolidated a bit more. I will encourage future review requests that
> > have a very trivial spelling fix to hold on to the fix for a while, so
> that
> > we can fix multiple spelling fixes etc. at the same time.
> >
> > Colm.
> >
> > On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj 

[jira] [Resolved] (RANGER-1575) Some users hope that the pid file of the Ranger Admin can be unified management when they integrate Ranger into the big data platform or business systems to uniform ins

[Qiang Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Qiang Zhang resolved RANGER-1575.
-
Resolution: Fixed

> Some users hope that the pid file of the Ranger Admin can be unified 
> management when they integrate Ranger into the big data platform or business 
> systems to uniform install and run Ranger.
> 
>
> Key: RANGER-1575
> URL: https://issues.apache.org/jira/browse/RANGER-1575
> Project: Ranger
>  Issue Type: New Feature
>  Components: admin
>Affects Versions: 1.0.0
>Reporter: peng.jianhua
>Assignee: peng.jianhua
>Priority: Minor
>  Labels: patch
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1575-Some-users-hope-that-the-pid-file-of-the.patch
>
>
> Some users hope that the pid file of the Ranger Admin can be unified 
> management when they integrate Ranger into the big data platform or business 
> systems to uniform install and run Ranger. 
> We should support the need in the case of compatibility with existing logic. 
> When running ranger, users can set the pid file to meet their own needs.
> We will explicitly document this change in the next release.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 59255: Some users hope that the pid file of the Ranger Admin can be unified management when they integrate Ranger into the big data platform or business systems to uniform install a

[Qiang Zhang]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59255/#review175947
---


Ship it!




Ship It!

- Qiang Zhang


On 五月 23, 2017, 4:07 a.m., pengjianhua wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59255/
> ---
> 
> (Updated 五月 23, 2017, 4:07 a.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, Velmurugan Periasamy, and Qiang Zhang.
> 
> 
> Bugs: RANGER-1575
> https://issues.apache.org/jira/browse/RANGER-1575
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Some users hope that the pid file of the Ranger Admin can be unified 
> management when they integrate Ranger into the big data platform or business 
> systems to uniform install and run Ranger.
> We should support the need in the case of compatibility with existing logic. 
> When running ranger, users can set the pid file to meet their own needs.
> 
> We will explicitly document this change in the next release.
> 
> 
> Diffs
> -
> 
>   embeddedwebserver/scripts/ranger-admin-services.sh a81219b 
> 
> 
> Diff: https://reviews.apache.org/r/59255/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> pengjianhua
> 
>

Re: Patches with trivial changes

[Zsombor]

Instead of discouraging contributions, the project should ease the
contribution - and also the review process.
The current JIRA + Reviewboard infrastructure needs a lot's of unnecessary
manual steps, which hurts everyone who wants to help.
 Currently, the contributor needs to do the following, after they have a
working commit in their git repository
1, open a jira ticket
2, generate a patch from git
2, create a review boad request, uploading the patch to it
3, upload the patch to jira
4, if something is not correct, they have to repeat 2-3.

Similarly, for the reviewer, he has to manually download, apply, and run
the tests locally, even when he thinks the patch is ok.

My suggestion is to switch to a pull request based workflow, where the
manual patch creation, upload-download process could be omitted, and travis
or some other automatic build service should be introduced, to ensure, that
the base sanity tests are not omitted accidentally.
 With this process, a commiter could review and approve a trivial commits
in less than a minute.

Is there any particular reason, why the current workflow used as is ?

Regards,
 Zsombor


On Wed, May 24, 2017 at 12:28 PM, Gautam Borad  wrote:

> +1 for Madhan's recommendations,
>
> Colm, I agree that we should not discourage new contributions. However, I
> think, we should also not encourage such single line/whitespace
> contributions. We want contributors who can do more functionals/feature
> changes and while doing that they can also fix the trivial issues
> (whitespace etc)
>
> Since each contribution to Ranger requires creating Jira/RR, if we start
> having lot of such trivial contributions, the community will be overwhelmed
> with activities(mails etc) like this and that can lead to ignoring of a
> real functional change, when it comes.
>
> In fact, the Apache page on Contributors itself says :
>
> "Being a contributor simply means that you take an interest in the project
> and contribute in some way, ranging from asking sensible questions (which
> documents the project and provides feedback to developers) through to
> providing *new features* as patches."
>
>
> So yes, we should encourage contributors, but encourage them to try and
> understand Ranger and add more features/functionalities and eventually
> "earn" the title of a committer. Thanks.
>
>
>
> On Wed, May 24, 2017 at 2:19 PM, Colm O hEigeartaigh 
> wrote:
>
> > Hi Madhan,
> >
> > Trivial commits provide a path to get new contributors on board to the
> > project - something that the project needs IMO. Yes it may make
> backporting
> > fixes a little more difficult, but it's hardly an intractable problem to
> > figure out some whitespace changes between branches - it's not as if
> Ranger
> > is a particularly large project.
> >
> > Having said that I agree that some of the very trivial patches could
> maybe
> > be consolidated a bit more. I will encourage future review requests that
> > have a very trivial spelling fix to hold on to the fix for a while, so
> that
> > we can fix multiple spelling fixes etc. at the same time.
> >
> > Colm.
> >
> > On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj 
> > wrote:
> >
> > > All,
> > >
> > >
> > >
> > > I notice a number of recent patches address trivial issues like white
> > > space, spelling mistakes (one patch just changed a single letter in a
> > > label). And few other patches update a large number of files for
> > > trivial/non-functional changes – like whitespaces. I strongly suggest
> we
> > > refrain from authoring/encouraging such patches – for many reasons. One
> > of
> > > the main reasons is the overhead such updates add in backporting
> > > real/critical fixes (that would come later) to other branches, as these
> > > changes might force dealing with merge conflicts.
> > >
> > >
> > >
> > > Since the changes introduced in such patches are not essential, I would
> > > suggest to take these up when these source files are updated for other
> > > functional fixes. I would greatly appreciate if the patches focus on
> > > fixing/enhancing Ranger functionality; this would be benefit the
> > community
> > > immensely.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Madhan
> > >
> > >
> > >
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
>
> --
> Regards,
> Gautam.
>

Review Request 59523: RANGER-689 - "For Solr plugin, use resources folders for adding Ranger properties".

[Colm O hEigeartaigh]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59523/
---

Review request for ranger.


Bugs: RANGER-689
https://issues.apache.org/jira/browse/RANGER-689


Repository: ranger


Description
---

Put the Ranger properties into the SOLR resource folder instead of the webapp.


Diffs
-

  agents-common/scripts/enable-agent.sh 76ba8f0d 


Diff: https://reviews.apache.org/r/59523/diff/1/


Testing
---

Tested with Solr 6.5.1.


Thanks,

Colm O hEigeartaigh

[jira] [Updated] (RANGER-689) For Solr plugin, use resources folders for adding Ranger properties

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated RANGER-689:
---
Attachment: 0001-RANGER-689-For-Solr-plugin-use-resources-folders-for.patch

> For Solr plugin, use resources folders for adding Ranger properties
> ---
>
> Key: RANGER-689
> URL: https://issues.apache.org/jira/browse/RANGER-689
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 0.5.0
>Reporter: Don Bosco Durai
>Assignee: Colm O hEigeartaigh
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-689-For-Solr-plugin-use-resources-folders-for.patch
>
>
> Currently, the jars required by Ranger are added to WEB-INF/lib and 
> WEB-INF/classes folders. However, Solr recommends to put all extension jars 
> in server/lib/ext and properties in server/resources
> We should update out plugin installer code to use the new location.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (RANGER-689) For Solr plugin, use resources folders for adding Ranger properties

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated RANGER-689:
---
Fix Version/s: 1.0.0

> For Solr plugin, use resources folders for adding Ranger properties
> ---
>
> Key: RANGER-689
> URL: https://issues.apache.org/jira/browse/RANGER-689
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 0.5.0
>Reporter: Don Bosco Durai
>Assignee: Colm O hEigeartaigh
> Fix For: 1.0.0
>
>
> Currently, the jars required by Ranger are added to WEB-INF/lib and 
> WEB-INF/classes folders. However, Solr recommends to put all extension jars 
> in server/lib/ext and properties in server/resources
> We should update out plugin installer code to use the new location.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (RANGER-689) For Solr plugin, use resources folders for adding Ranger properties

[Colm O hEigeartaigh (JIRA)]

[ 
https://issues.apache.org/jira/browse/RANGER-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16022697#comment-16022697
 ] 

Colm O hEigeartaigh commented on RANGER-689:


Putting the jars into service/lib/ext does not seem to work. I will submit a 
patch to put the resources into server/resources though.

> For Solr plugin, use resources folders for adding Ranger properties
> ---
>
> Key: RANGER-689
> URL: https://issues.apache.org/jira/browse/RANGER-689
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 0.5.0
>Reporter: Don Bosco Durai
>Assignee: Colm O hEigeartaigh
>
> Currently, the jars required by Ranger are added to WEB-INF/lib and 
> WEB-INF/classes folders. However, Solr recommends to put all extension jars 
> in server/lib/ext and properties in server/resources
> We should update out plugin installer code to use the new location.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (RANGER-689) For Solr plugin, use resources folders for adding Ranger properties

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated RANGER-689:
---
Summary: For Solr plugin, use resources folders for adding Ranger 
properties  (was: For Solr plugin, use lib/ext and resources folders for adding 
Ranger jars and properties)

> For Solr plugin, use resources folders for adding Ranger properties
> ---
>
> Key: RANGER-689
> URL: https://issues.apache.org/jira/browse/RANGER-689
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 0.5.0
>Reporter: Don Bosco Durai
>Assignee: Colm O hEigeartaigh
>
> Currently, the jars required by Ranger are added to WEB-INF/lib and 
> WEB-INF/classes folders. However, Solr recommends to put all extension jars 
> in server/lib/ext and properties in server/resources
> We should update out plugin installer code to use the new location.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (RANGER-689) For Solr plugin, use lib/ext and resources folders for adding Ranger jars and properties

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh reassigned RANGER-689:
--

Assignee: Colm O hEigeartaigh

> For Solr plugin, use lib/ext and resources folders for adding Ranger jars and 
> properties
> 
>
> Key: RANGER-689
> URL: https://issues.apache.org/jira/browse/RANGER-689
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Affects Versions: 0.5.0
>Reporter: Don Bosco Durai
>Assignee: Colm O hEigeartaigh
>
> Currently, the jars required by Ranger are added to WEB-INF/lib and 
> WEB-INF/classes folders. However, Solr recommends to put all extension jars 
> in server/lib/ext and properties in server/resources
> We should update out plugin installer code to use the new location.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Patches with trivial changes

[Gautam Borad]

+1 for Madhan's recommendations,

Colm, I agree that we should not discourage new contributions. However, I
think, we should also not encourage such single line/whitespace
contributions. We want contributors who can do more functionals/feature
changes and while doing that they can also fix the trivial issues
(whitespace etc)

Since each contribution to Ranger requires creating Jira/RR, if we start
having lot of such trivial contributions, the community will be overwhelmed
with activities(mails etc) like this and that can lead to ignoring of a
real functional change, when it comes.

In fact, the Apache page on Contributors itself says :

"Being a contributor simply means that you take an interest in the project
and contribute in some way, ranging from asking sensible questions (which
documents the project and provides feedback to developers) through to
providing *new features* as patches."


So yes, we should encourage contributors, but encourage them to try and
understand Ranger and add more features/functionalities and eventually
"earn" the title of a committer. Thanks.



On Wed, May 24, 2017 at 2:19 PM, Colm O hEigeartaigh 
wrote:

> Hi Madhan,
>
> Trivial commits provide a path to get new contributors on board to the
> project - something that the project needs IMO. Yes it may make backporting
> fixes a little more difficult, but it's hardly an intractable problem to
> figure out some whitespace changes between branches - it's not as if Ranger
> is a particularly large project.
>
> Having said that I agree that some of the very trivial patches could maybe
> be consolidated a bit more. I will encourage future review requests that
> have a very trivial spelling fix to hold on to the fix for a while, so that
> we can fix multiple spelling fixes etc. at the same time.
>
> Colm.
>
> On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj 
> wrote:
>
> > All,
> >
> >
> >
> > I notice a number of recent patches address trivial issues like white
> > space, spelling mistakes (one patch just changed a single letter in a
> > label). And few other patches update a large number of files for
> > trivial/non-functional changes – like whitespaces. I strongly suggest we
> > refrain from authoring/encouraging such patches – for many reasons. One
> of
> > the main reasons is the overhead such updates add in backporting
> > real/critical fixes (that would come later) to other branches, as these
> > changes might force dealing with merge conflicts.
> >
> >
> >
> > Since the changes introduced in such patches are not essential, I would
> > suggest to take these up when these source files are updated for other
> > functional fixes. I would greatly appreciate if the patches focus on
> > fixing/enhancing Ranger functionality; this would be benefit the
> community
> > immensely.
> >
> >
> >
> > Thanks,
> >
> > Madhan
> >
> >
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



-- 
Regards,
Gautam.

答复: Re: Patches with trivial changes

[peng.jianhua]

Hi Madhan,




Merging these small issues to other branches will increase the workload and the 
probability of error. If possible, we can undertake similar tasks when some 
important issues need to be merged into other branches. 




With the improvement of quality, these small issues will be gradually reduced 
until the last disappear. The current difficulties will gradually reduce if we 
continue to handle these issues. Otherwise with the function of the perfect, 
such small issue will be accumulated and increased.

At the same time, we should strictly control the quality of the code to avoid 
similar problems.




We will respect your opinion and control the quality of the code.




Peng.jianhua




发件人： ＜cohei...@apache.org＞







收件人： ＜dev@ranger.apache.org＞
抄送人： ＜comm...@ranger.apache.org＞
日 期 ：2017年05月24日 16:49
主 题 ：Re: Patches with trivial changes





Hi Madhan,

Trivial commits provide a path to get new contributors on board to the
project - something that the project needs IMO. Yes it may make backporting
fixes a little more difficult, but it's hardly an intractable problem to
figure out some whitespace changes between branches - it's not as if Ranger
is a particularly large project.

Having said that I agree that some of the very trivial patches could maybe
be consolidated a bit more. I will encourage future review requests that
have a very trivial spelling fix to hold on to the fix for a while, so that
we can fix multiple spelling fixes etc. at the same time.

Colm.

On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj ＜mad...@apache.org＞ wrote:

＞ All,
＞
＞
＞
＞ I notice a number of recent patches address trivial issues like white
＞ space, spelling mistakes (one patch just changed a single letter in a
＞ label). And few other patches update a large number of files for
＞ trivial/non-functional changes – like whitespaces. I strongly suggest we
＞ refrain from authoring/encouraging such patches – for many reasons. One of
＞ the main reasons is the overhead such updates add in backporting
＞ real/critical fixes (that would come later) to other branches, as these
＞ changes might force dealing with merge conflicts.
＞
＞
＞
＞ Since the changes introduced in such patches are not essential, I would
＞ suggest to take these up when these source files are updated for other
＞ functional fixes. I would greatly appreciate if the patches focus on
＞ fixing/enhancing Ranger functionality this would be benefit the community
＞ immensely.
＞
＞
＞
＞ Thanks,
＞
＞ Madhan
＞
＞
＞



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

[jira] [Updated] (RANGER-1584) Allow tagsync to support log directory from Ambari configuration

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated RANGER-1584:

Fix Version/s: 1.0.0

> Allow tagsync to support log directory from Ambari configuration
> 
>
> Key: RANGER-1584
> URL: https://issues.apache.org/jira/browse/RANGER-1584
> Project: Ranger
>  Issue Type: Bug
>  Components: tagsync
>Affects Versions: master, 0.7.1
>Reporter: Yujie Li
>Assignee: Yujie Li
>Priority: Minor
> Fix For: 1.0.0, 0.7.1
>
> Attachments: 
> 0001-RANGER-1584-Allow-tagsync-to-support-log-directory-f.patch
>
>
> Currently Tagsync hardcodes the log directory as /var/log/ranger/tagsync. It 
> doesn't support customization setting for log location from Ambari side.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 59255: Some users hope that the pid file of the Ranger Admin can be unified management when they integrate Ranger into the big data platform or business systems to uniform install a

[Colm O hEigeartaigh]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59255/#review175914
---


Ship it!




Ship It!

- Colm O hEigeartaigh


On May 23, 2017, 4:07 a.m., pengjianhua wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59255/
> ---
> 
> (Updated May 23, 2017, 4:07 a.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, Velmurugan Periasamy, and Qiang Zhang.
> 
> 
> Bugs: RANGER-1575
> https://issues.apache.org/jira/browse/RANGER-1575
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Some users hope that the pid file of the Ranger Admin can be unified 
> management when they integrate Ranger into the big data platform or business 
> systems to uniform install and run Ranger.
> We should support the need in the case of compatibility with existing logic. 
> When running ranger, users can set the pid file to meet their own needs.
> 
> We will explicitly document this change in the next release.
> 
> 
> Diffs
> -
> 
>   embeddedwebserver/scripts/ranger-admin-services.sh a81219b 
> 
> 
> Diff: https://reviews.apache.org/r/59255/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> pengjianhua
> 
>

[jira] [Closed] (RANGER-1049) Testing connection at a Kerberos server

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed RANGER-1049.
---

> Testing connection at a Kerberos server
> ---
>
> Key: RANGER-1049
> URL: https://issues.apache.org/jira/browse/RANGER-1049
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, plugins
>Affects Versions: 0.5.3
> Environment: CenOS6.7/zookeeper3.4.6/hadoop2.7.1/Ranger0.5.3
>Reporter: Myungsun
>Priority: Minor
>
> Hi~
> The Ranger's HDFS connection test failed in a Kerberos Server.
> Of course, I refer to this [RANGER-399]
> Please Give your help
> ## Ranger  ERROR xa_portal.log ## 
> 2016-06-22 17:17:20,327 [timed-executor-pool-0] INFO  
> org.apache.ranger.plugin.client.BaseClient (BaseClient.java:100) - Init 
> Login: using username/password
> 2016-06-22 17:17:20,339 [timed-executor-pool-0] ERROR 
> apache.ranger.services.hdfs.client.HdfsResourceMgr (HdfsResourceMgr.java:48) 
> - <== HdfsResourceMgr.testConnection Error: 
> org.apache.ranger.plugin.client.HadoopException: Unable to login to Hadoop 
> environment [hadoop]
> 2016-06-22 17:17:20,339 [timed-executor-pool-0] ERROR 
> org.apache.ranger.services.hdfs.RangerServiceHdfs (RangerServiceHdfs.java:59) 
> - <== RangerServiceHdfs.validateConfig 
> Error:org.apache.ranger.plugin.client.HadoopException: Unable to login to 
> Hadoop environment [hadoop]
> 2016-06-22 17:17:20,339 [timed-executor-pool-0] ERROR 
> org.apache.ranger.biz.ServiceMgr$TimedCallable (ServiceMgr.java:434) - 
> TimedCallable.call: Error:org.apache.ranger.plugin.client.HadoopException: 
> Unable to login to Hadoop environment [hadoop]
> 2016-06-22 17:17:20,339 [timed-executor-pool-0] DEBUG 
> org.apache.ranger.biz.ServiceMgr$TimedCallable (ServiceMgr.java:442) - <== 
> TimedCallable: validate config for service[hadoop]: wait time[0 ms], 
> execution time [12 ms]
> 2016-06-22 17:17:20,339 [http-bio-6080-exec-5] DEBUG 
> org.apache.ranger.common.TimedExecutor (TimedExecutor.java:92) - 
> TimedExecutor: Caught exception[java.util.concurrent.ExecutionException] for 
> callable[validate config for service[hadoop]]: 
> detail[org.apache.ranger.plugin.client.HadoopException: Unable to login to 
> Hadoop environment [hadoop]].  Re-throwing...
> 2016-06-22 17:17:20,340 [http-bio-6080-exec-5] ERROR 
> org.apache.ranger.biz.ServiceMgr (ServiceMgr.java:120) - ==> 
> ServiceMgr.validateConfig Error:java.util.concurrent.ExecutionException: 
> org.apache.ranger.plugin.client.HadoopException: Unable to login to Hadoop 
> environment [hadoop]
> 2016-06-22 17:17:20,340 [http-bio-6080-exec-5] DEBUG 
> org.apache.ranger.biz.ServiceMgr (ServiceMgr.java:125) - ==> 
> ServiceMgr.validateConfig for Response: 
> (VXResponse={org.apache.ranger.view.VXResponse@1cf17880statusCode={1} 
> msgDesc={Unable to connect repository with given config for hadoop} 
> messageList={[VXMessage={org.apache.ranger.view.VXMessage@311e2a58name={null} 
> rbKey={null} message={Unable to connect repository with given config for 
> hadoop} objectId={null} fieldName={null} }]} })
>  Ranger HDFS 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (RANGER-1050) Change my name on all systems

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh closed RANGER-1050.
---

> Change my name on all systems
> -
>
> Key: RANGER-1050
> URL: https://issues.apache.org/jira/browse/RANGER-1050
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Reporter: Josephine Agyekum-Bonsu
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (RANGER-1050) Change my name on all systems

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh resolved RANGER-1050.
-
Resolution: Not A Problem

> Change my name on all systems
> -
>
> Key: RANGER-1050
> URL: https://issues.apache.org/jira/browse/RANGER-1050
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Reporter: Josephine Agyekum-Bonsu
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Patches with trivial changes

[Colm O hEigeartaigh]

Hi Madhan,

Trivial commits provide a path to get new contributors on board to the
project - something that the project needs IMO. Yes it may make backporting
fixes a little more difficult, but it's hardly an intractable problem to
figure out some whitespace changes between branches - it's not as if Ranger
is a particularly large project.

Having said that I agree that some of the very trivial patches could maybe
be consolidated a bit more. I will encourage future review requests that
have a very trivial spelling fix to hold on to the fix for a while, so that
we can fix multiple spelling fixes etc. at the same time.

Colm.

On Wed, May 24, 2017 at 7:27 AM, Madhan Neethiraj  wrote:

> All,
>
>
>
> I notice a number of recent patches address trivial issues like white
> space, spelling mistakes (one patch just changed a single letter in a
> label). And few other patches update a large number of files for
> trivial/non-functional changes – like whitespaces. I strongly suggest we
> refrain from authoring/encouraging such patches – for many reasons. One of
> the main reasons is the overhead such updates add in backporting
> real/critical fixes (that would come later) to other branches, as these
> changes might force dealing with merge conflicts.
>
>
>
> Since the changes introduced in such patches are not essential, I would
> suggest to take these up when these source files are updated for other
> functional fixes. I would greatly appreciate if the patches focus on
> fixing/enhancing Ranger functionality; this would be benefit the community
> immensely.
>
>
>
> Thanks,
>
> Madhan
>
>
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

[jira] [Resolved] (RANGER-1610) Modify the Logger scope and keep the consistent info in XPolicyService.java

[Qiang Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Qiang Zhang resolved RANGER-1610.
-
Resolution: Invalid

> Modify the Logger scope and keep the consistent info  in XPolicyService.java
> 
>
> Key: RANGER-1610
> URL: https://issues.apache.org/jira/browse/RANGER-1610
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: master
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>Priority: Minor
> Attachments: 
> 0001-RANGER-1610-Modify-the-Logger-scope-and-keep-the-con.patch
>
>
> Modify the Logger scope from Logger logger = 
> Logger.getLogger(XPolicyService.class);
> to private static final Logger logger = 
> Logger.getLogger(XPolicyService.class);
>  and keep the consistent info 
> if (xxGroup == null) {
> logger.error("No UserGroup found with this name : "+ group);
> throw restErrorUtil.createRESTException(
> "No Group found with name : " + group,
> MessageEnums.DATA_NOT_FOUND);
>   }
> to 
> if (xxGroup == null) {
> logger.error("No Group found with  name : "+ group);
> throw restErrorUtil.createRESTException(
> "No Group found with name : " + group,
> MessageEnums.DATA_NOT_FOUND);



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (RANGER-1610) Modify the Logger scope and keep the consistent info in XPolicyService.java

[Qiang Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RANGER-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Qiang Zhang reassigned RANGER-1610:
---

Assignee: Qiang Zhang

> Modify the Logger scope and keep the consistent info  in XPolicyService.java
> 
>
> Key: RANGER-1610
> URL: https://issues.apache.org/jira/browse/RANGER-1610
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: master
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>Priority: Minor
> Attachments: 
> 0001-RANGER-1610-Modify-the-Logger-scope-and-keep-the-con.patch
>
>
> Modify the Logger scope from Logger logger = 
> Logger.getLogger(XPolicyService.class);
> to private static final Logger logger = 
> Logger.getLogger(XPolicyService.class);
>  and keep the consistent info 
> if (xxGroup == null) {
> logger.error("No UserGroup found with this name : "+ group);
> throw restErrorUtil.createRESTException(
> "No Group found with name : " + group,
> MessageEnums.DATA_NOT_FOUND);
>   }
> to 
> if (xxGroup == null) {
> logger.error("No Group found with  name : "+ group);
> throw restErrorUtil.createRESTException(
> "No Group found with name : " + group,
> MessageEnums.DATA_NOT_FOUND);



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Patches with trivial changes

[Madhan Neethiraj]

All,

 

I notice a number of recent patches address trivial issues like white space, 
spelling mistakes (one patch just changed a single letter in a label). And few 
other patches update a large number of files for trivial/non-functional changes 
– like whitespaces. I strongly suggest we refrain from authoring/encouraging 
such patches – for many reasons. One of the main reasons is the overhead such 
updates add in backporting real/critical fixes (that would come later) to other 
branches, as these changes might force dealing with merge conflicts.

 

Since the changes introduced in such patches are not essential, I would suggest 
to take these up when these source files are updated for other functional 
fixes. I would greatly appreciate if the patches focus on fixing/enhancing 
Ranger functionality; this would be benefit the community immensely.

 

Thanks,

Madhan