[jira] [Commented] (KNOX-18) IdentityAssertionHttpServletRequestWrapper should only be used when required by the service
[ https://issues.apache.org/jira/browse/KNOX-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987936#comment-15987936 ] Shi Wang commented on KNOX-18: -- [~kminder] I recently encounter an issue regarding to 1) in your comment. Say if we specify a rewrite filter for the request body and in the filter we want to change type application/x-www-form-urlencoded to asType application/octet-stream, then this personalized filter will be invalid since the request body will still be applied contentType as application/x-www-form-urlencoded. Maybe we should check if there is any asType for request body first before doing the urlEncode? > IdentityAssertionHttpServletRequestWrapper should only be used when required > by the service > --- > > Key: KNOX-18 > URL: https://issues.apache.org/jira/browse/KNOX-18 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 0.2.0 >Reporter: Kevin Minder > Fix For: Future > > > From BUG-4297 > This is a performance issue since it filters the request stream. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-816) Make private inner classes static
[ https://issues.apache.org/jira/browse/KNOX-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987565#comment-15987565 ] Larry McCay commented on KNOX-816: -- [~coheigea] - thank you for this contribution - I've committed it to master which will make it available in 0.13.0/1.0.0! > Make private inner classes static > - > > Key: KNOX-816 > URL: https://issues.apache.org/jira/browse/KNOX-816 > Project: Apache Knox > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Trivial > Fix For: 0.13.0 > > Attachments: 0001-KNOX-816-Make-private-inner-classes-static.patch > > > As discussed on KNOX-792, this JIRA is a placeholder for a patch to make all > private inner classes static for performance reasons. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KNOX-816) Make private inner classes static
[ https://issues.apache.org/jira/browse/KNOX-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay updated KNOX-816: - Resolution: Fixed Status: Resolved (was: Patch Available) > Make private inner classes static > - > > Key: KNOX-816 > URL: https://issues.apache.org/jira/browse/KNOX-816 > Project: Apache Knox > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Trivial > Fix For: 0.13.0 > > Attachments: 0001-KNOX-816-Make-private-inner-classes-static.patch > > > As discussed on KNOX-792, this JIRA is a placeholder for a patch to make all > private inner classes static for performance reasons. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-816) Make private inner classes static
[ https://issues.apache.org/jira/browse/KNOX-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987564#comment-15987564 ] ASF subversion and git services commented on KNOX-816: -- Commit 5dac768d2ed2ad051724b998db5a7a1f39a599b0 in knox's branch refs/heads/master from [~lmccay] [ https://git-wip-us.apache.org/repos/asf?p=knox.git;h=5dac768 ] KNOX-816 - Make private inner classes static (Colm O hEigeartaigh via lmccay) > Make private inner classes static > - > > Key: KNOX-816 > URL: https://issues.apache.org/jira/browse/KNOX-816 > Project: Apache Knox > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Trivial > Fix For: 0.13.0 > > Attachments: 0001-KNOX-816-Make-private-inner-classes-static.patch > > > As discussed on KNOX-792, this JIRA is a placeholder for a patch to make all > private inner classes static for performance reasons. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KNOX-892) Fix FindBugs "Dodgy Code" issues
[ https://issues.apache.org/jira/browse/KNOX-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay updated KNOX-892: - Resolution: Fixed Status: Resolved (was: Patch Available) > Fix FindBugs "Dodgy Code" issues > > > Key: KNOX-892 > URL: https://issues.apache.org/jira/browse/KNOX-892 > Project: Apache Knox > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 0.13.0 > > Attachments: 0001-KNOX-892-Fix-FindBugs-Dodgy-Code-issues.patch > > > This task is to fix some of the FindBugs "Dodgy Code" issues. Among the > issues fixed are: > a) Write to static variables from instance methods > b) Replaced EMPTY_* with empty* to remove some warnings > c) Removed some unnecessary testing for null > d) Fixed some potential NPEs on File.listFiles() if the path refers to a file > rather than a directory. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-892) Fix FindBugs "Dodgy Code" issues
[ https://issues.apache.org/jira/browse/KNOX-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987487#comment-15987487 ] Larry McCay commented on KNOX-892: -- [~coheigea] - thank you for this cleanup task. I committed this to master and it will be available in 0.13.0/1.0.0! > Fix FindBugs "Dodgy Code" issues > > > Key: KNOX-892 > URL: https://issues.apache.org/jira/browse/KNOX-892 > Project: Apache Knox > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 0.13.0 > > Attachments: 0001-KNOX-892-Fix-FindBugs-Dodgy-Code-issues.patch > > > This task is to fix some of the FindBugs "Dodgy Code" issues. Among the > issues fixed are: > a) Write to static variables from instance methods > b) Replaced EMPTY_* with empty* to remove some warnings > c) Removed some unnecessary testing for null > d) Fixed some potential NPEs on File.listFiles() if the path refers to a file > rather than a directory. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-892) Fix FindBugs "Dodgy Code" issues
[ https://issues.apache.org/jira/browse/KNOX-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987471#comment-15987471 ] ASF subversion and git services commented on KNOX-892: -- Commit 5cb614de4dcaf6da1a04d60db73e58306b4c6c22 in knox's branch refs/heads/master from [~lmccay] [ https://git-wip-us.apache.org/repos/asf?p=knox.git;h=5cb614d ] KNOX-892 - Fix FindBugs "Dodgy Code" issues (Colm O hEigeartaigh via lmccay) > Fix FindBugs "Dodgy Code" issues > > > Key: KNOX-892 > URL: https://issues.apache.org/jira/browse/KNOX-892 > Project: Apache Knox > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 0.13.0 > > Attachments: 0001-KNOX-892-Fix-FindBugs-Dodgy-Code-issues.patch > > > This task is to fix some of the FindBugs "Dodgy Code" issues. Among the > issues fixed are: > a) Write to static variables from instance methods > b) Replaced EMPTY_* with empty* to remove some warnings > c) Removed some unnecessary testing for null > d) Fixed some potential NPEs on File.listFiles() if the path refers to a file > rather than a directory. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (KNOX-461) Leverage Directory Computed Attribute for User Group Discovery
[ https://issues.apache.org/jira/browse/KNOX-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987272#comment-15987272 ] Ryan LaMothe edited comment on KNOX-461 at 4/27/17 7:48 PM: [~lmccay] Thank you for the quick response! PAM does not currently work for us, for a variety of reasons, although we are migrating all cluster nodes to SSSD w/group lookups so it may be worth re-investigating in the future. I was unaware of the Hadoop Group Lookup Provider, that may just work for us, as we already have the rest of our Hadoop services looking up AD/LDAP groups correctly. We'll give it a try and get back to you if it doesn't meet our needs. Thanks again! was (Author: rlamothe): [~lmccay] Thank you for the quick response! PAM does not currently work for us, for a variety of reasons, although we are currently migrating all cluster nodes to SSSD w/group lookups so it may be worth investigating in the future. I was unaware of the Hadoop Group Lookup Provider, that may just work for us, as we already have the rest of our Hadoop services looking up AD/LDAP groups correctly. We'll give it a try and get back to you if it doesn't meet our needs. Thanks again! > Leverage Directory Computed Attribute for User Group Discovery > --- > > Key: KNOX-461 > URL: https://issues.apache.org/jira/browse/KNOX-461 > Project: Apache Knox > Issue Type: Improvement >Reporter: Dilli Arumugam >Priority: Critical > Fix For: Future > > > Leverage Directory Computed Attribute for User Group Discovery > We should use computed attribute memberof supported by Active Driectory to > discover groups of the authenticated user. This would significantly boost > performance as compared we computing groups using group search. > OpenLDAP also could be configured to return computed groups. > However, OpenLDAP would return this attribute as memberof. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (KNOX-461) Leverage Directory Computed Attribute for User Group Discovery
[ https://issues.apache.org/jira/browse/KNOX-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987272#comment-15987272 ] Ryan LaMothe edited comment on KNOX-461 at 4/27/17 7:47 PM: [~lmccay] Thank you for the quick response! PAM does not currently work for us, for a variety of reasons, although we are currently migrating all cluster nodes to SSSD w/group lookups so it may be worth investigating in the future. I was unaware of the Hadoop Group Lookup Provider, that may just work for us, as we already have the rest of our Hadoop services looking up AD/LDAP groups correctly. We'll give it a try and get back to you if it doesn't meet our needs. Thanks again! was (Author: rlamothe): [~lmccay] Thank you for the quick response! PAM does not work for us, for a variety of reasons, although we are currently migrating all cluster nodes to SSSD w/group lookups so it may be worth investigating in the future. I was unaware of the Hadoop Group Lookup Provider, that may just work for us, as we already have the rest of our Hadoop services looking up AD/LDAP groups correctly. We'll give it a try and get back to you if it doesn't meet our needs. Thanks again! > Leverage Directory Computed Attribute for User Group Discovery > --- > > Key: KNOX-461 > URL: https://issues.apache.org/jira/browse/KNOX-461 > Project: Apache Knox > Issue Type: Improvement >Reporter: Dilli Arumugam >Priority: Critical > Fix For: Future > > > Leverage Directory Computed Attribute for User Group Discovery > We should use computed attribute memberof supported by Active Driectory to > discover groups of the authenticated user. This would significantly boost > performance as compared we computing groups using group search. > OpenLDAP also could be configured to return computed groups. > However, OpenLDAP would return this attribute as memberof. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (KNOX-461) Leverage Directory Computed Attribute for User Group Discovery
[ https://issues.apache.org/jira/browse/KNOX-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987272#comment-15987272 ] Ryan LaMothe edited comment on KNOX-461 at 4/27/17 6:57 PM: [~lmccay] Thank you for the quick response! PAM does not work for us, for a variety of reasons, although we are currently migrating all cluster nodes to SSSD w/group lookups so it may be worth investigating in the future. I was unaware of the Hadoop Group Lookup Provider, that may just work for us, as we already have the rest of our Hadoop services looking up AD/LDAP groups correctly. We'll give it a try and get back to you if it doesn't meet our needs. Thanks again! was (Author: rlamothe): [~lmccay] Thank you for the quick response! PAM would not work for us, for a variety of reasons, although we are currently migrating all cluster nodes to SSSD w/group lookups so it may be worth investigating in the future. I was unaware of the Hadoop Group Lookup Provider, that may just work for us, as we already have the rest of our Hadoop services looking up AD/LDAP groups correctly. We'll give it a try and get back to you if it doesn't meet our needs. Thanks again! > Leverage Directory Computed Attribute for User Group Discovery > --- > > Key: KNOX-461 > URL: https://issues.apache.org/jira/browse/KNOX-461 > Project: Apache Knox > Issue Type: Improvement >Reporter: Dilli Arumugam >Priority: Critical > Fix For: Future > > > Leverage Directory Computed Attribute for User Group Discovery > We should use computed attribute memberof supported by Active Driectory to > discover groups of the authenticated user. This would significantly boost > performance as compared we computing groups using group search. > OpenLDAP also could be configured to return computed groups. > However, OpenLDAP would return this attribute as memberof. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-461) Leverage Directory Computed Attribute for User Group Discovery
[ https://issues.apache.org/jira/browse/KNOX-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987272#comment-15987272 ] Ryan LaMothe commented on KNOX-461: --- [~lmccay] Thank you for the quick response! PAM would not work for us, for a variety of reasons, although we are currently migrating all cluster nodes to SSSD w/group lookups so it may be worth investigating in the future. I was unaware of the Hadoop Group Lookup Provider, that may just work for us, as we already have the rest of our Hadoop services looking up AD/LDAP groups correctly. We'll give it a try and get back to you if it doesn't meet our needs. Thanks again! > Leverage Directory Computed Attribute for User Group Discovery > --- > > Key: KNOX-461 > URL: https://issues.apache.org/jira/browse/KNOX-461 > Project: Apache Knox > Issue Type: Improvement >Reporter: Dilli Arumugam >Priority: Critical > Fix For: Future > > > Leverage Directory Computed Attribute for User Group Discovery > We should use computed attribute memberof supported by Active Driectory to > discover groups of the authenticated user. This would significantly boost > performance as compared we computing groups using group search. > OpenLDAP also could be configured to return computed groups. > However, OpenLDAP would return this attribute as memberof. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-789) Apache Atlas REST API support
[ https://issues.apache.org/jira/browse/KNOX-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987144#comment-15987144 ] Shi Wang commented on KNOX-789: --- Thanks for this valuable info [~mad...@apache.org], I'll test with Atlas 0.8 then. > Apache Atlas REST API support > - > > Key: KNOX-789 > URL: https://issues.apache.org/jira/browse/KNOX-789 > Project: Apache Knox > Issue Type: New Feature > Environment: all >Reporter: Jeffrey E Rodriguez >Assignee: Shi Wang > Fix For: 0.13.0 > > > Apache REST API support through Knox > https://atlas.incubator.apache.org/api/rest.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (KNOX-919) Upgrade Knox 0.9.1 to 0.12 - Url matching failed
[
https://issues.apache.org/jira/browse/KNOX-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Larry McCay resolved KNOX-919.
--
Resolution: Cannot Reproduce
Setting this to cannot reproduce. Please feel free to reopen it - if
appropriate.
> Upgrade Knox 0.9.1 to 0.12 - Url matching failed
>
>
> Key: KNOX-919
> URL: https://issues.apache.org/jira/browse/KNOX-919
> Project: Apache Knox
> Issue Type: Bug
> Components: Release
>Affects Versions: 0.12.0
> Environment: Hadoop Cluster
> LDAP/Kerberos
>Reporter: Yoann Bellet
>Priority: Blocker
> Fix For: 0.13.0
>
>
> Hello,
> I'm trying to upgrade our Knox on Preproduction plateform from version 0.9.1
> to 0.12, (I deployed the same configuration, i don't see any big differencies
> on this side).
> Logs seems to be identicals
> I'm trying these commands :
> {code}
> ./bin/knoxcli.sh user-auth-test --cluster bigdata --u user--p passwd--g --d
> ./bin/knoxcli.sh validate-topology --cluster bigdata
> {code}
> And it works for the two versions.
> But when I'm trying to contact webhdfs with this curl command
> curl -ivk -u user-X GET
> 'https://knox01:8443/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS'
> with 0.9.1 :
> {code}
> 2017-04-03T15:36:24.111779+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFSaccess|uri|/gateway/bigdata/webhdfs/v1/user/user?OP=LISTSTATUS|unavailable|Request
> method: GET
> 2017-04-03T15:36:24.112571+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFS|user|||authentication|uri|/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS|success|
> 2017-04-03T15:36:24.112709+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFS|user|||authentication|uri|/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS|success|Groups:
> []
> 2017-04-03T15:36:24.114225+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFS|user|||dispatch|uri|http://namenode01:50070/webhdfs/v1/user?doAs=user&OP=LISTSTATUS|unavailable|Request
> method: GET
> 2017-04-03T15:36:24.146810+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFS|user|||dispatch|uri|http://namenode01:50070/webhdfs/v1/user?doAs=user&OP=LISTSTATUS|success|Response
> status: 200
> 2017-04-03T15:36:24.152511+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFS|user|||access|uri|/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS|success|Response
> status: 200
> {code}
> whith 0.12 :
> {code}
> 2017-04-03T15:37:01.651295+02:00 localhost 17/04/03 15:37:01
> ||8c8c0ef2-db5c-4bc4-83c3-5ef35a7e482e|audit|access|uri|/gateway/bigdata/gateway/bigdata/webhdfs/v1/user/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS|unavailable|Request
> method: GET
> 2017-04-03T15:37:01+02:00 knox01 knox WARN - org.apache.hadoop.gatewayFailed
> to match path /gateway/bigdata/webhdfs/v1/user
> 2017-04-03T15:37:01.652123+02:00 localhost 17/04/03 15:37:01
> ||8c8c0ef2-db5c-4bc4-83c3-5ef35a7e482e|audit|access|uri|/gateway/bigdata/gateway/bigdata/webhdfs/v1/user/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS|success|Response
> status: 404
> {code}
> Authentication is not tested and namenode is not call on Knox 0.12 because
> uri matching reveal an error, i don't know why Knox add "gateway/bigdata"
> many times on uri...
> Regards.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KNOX-789) Apache Atlas REST API support
[ https://issues.apache.org/jira/browse/KNOX-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987120#comment-15987120 ] Madhan Neethiraj commented on KNOX-789: --- [~jeffreyr97], [~Wancy] - Atlas 0.8 (incubating) release introduces new REST API listed at http://atlas.incubator.apache.org/api/v2/index.html. Most of earlier version REST API (listed in https://atlas.incubator.apache.org/api/rest.html) are now deprecated. Please review and consider adding support for the APIs in 0.8 release. > Apache Atlas REST API support > - > > Key: KNOX-789 > URL: https://issues.apache.org/jira/browse/KNOX-789 > Project: Apache Knox > Issue Type: New Feature > Environment: all >Reporter: Jeffrey E Rodriguez >Assignee: Shi Wang > Fix For: 0.13.0 > > > Apache REST API support through Knox > https://atlas.incubator.apache.org/api/rest.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (KNOX-922) Document default.app.topology.name in User Guide
[ https://issues.apache.org/jira/browse/KNOX-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay resolved KNOX-922. -- Resolution: Won't Fix This feature is going to be superseded by the portmapping based way to provide "gateway/topology"-less URLs. > Document default.app.topology.name in User Guide > > > Key: KNOX-922 > URL: https://issues.apache.org/jira/browse/KNOX-922 > Project: Apache Knox > Issue Type: Task > Components: Site >Affects Versions: 0.5.0, 0.6.0, 0.7.0, 0.8.0, 0.9.0, 0.10.0, 0.11.0 >Reporter: Rick Kellogg > Fix For: 0.13.0 > > > Add the following to the Gateway Server Configuration table of the User Guide > documentation: > default.app.topology.name > Specifies topology mapped to the default topology (without an explicit > gateway-path) in the URL. > This setting was mentioned in the URL Mapping -> Default Topology URL but not > listed in the table. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-788) Apache Atlas Admin UI Support through Knox
[ https://issues.apache.org/jira/browse/KNOX-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987119#comment-15987119 ] Jeffrey Rodriguez commented on KNOX-788: Thanks Chandana. > Apache Atlas Admin UI Support through Knox > -- > > Key: KNOX-788 > URL: https://issues.apache.org/jira/browse/KNOX-788 > Project: Apache Knox > Issue Type: New Feature > Components: Server >Reporter: Jeffrey E Rodriguez >Assignee: Chandana Mirashi > Fix For: 0.13.0 > > > Apache Atlas Admin UI Support through Knox. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-788) Apache Atlas Admin UI Support through Knox
[ https://issues.apache.org/jira/browse/KNOX-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987116#comment-15987116 ] Chandana Mirashi commented on KNOX-788: --- I would like to work on it. > Apache Atlas Admin UI Support through Knox > -- > > Key: KNOX-788 > URL: https://issues.apache.org/jira/browse/KNOX-788 > Project: Apache Knox > Issue Type: New Feature > Components: Server >Reporter: Jeffrey E Rodriguez >Assignee: Chandana Mirashi > Fix For: 0.13.0 > > > Apache Atlas Admin UI Support through Knox. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (KNOX-788) Apache Atlas Admin UI Support through Knox
[ https://issues.apache.org/jira/browse/KNOX-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandana Mirashi reassigned KNOX-788: - Assignee: Chandana Mirashi > Apache Atlas Admin UI Support through Knox > -- > > Key: KNOX-788 > URL: https://issues.apache.org/jira/browse/KNOX-788 > Project: Apache Knox > Issue Type: New Feature > Components: Server >Reporter: Jeffrey E Rodriguez >Assignee: Chandana Mirashi > Fix For: 0.13.0 > > > Apache Atlas Admin UI Support through Knox. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release
Sounds great ! On Thu, Apr 27, 2017 at 12:32 PM, larry mccay wrote: > That sounds reasonable to me. > I was hoping to get as many of the patches available and important bugs > fixed before the split as well. > Minimizing the double commits/patches is definitely in our interest. > > At the same time, we need to have enough time to spend on refactoring as > well. > I'm thinking that May 15th may be a good branch point - giving us 2 weeks > to concentrate on repackaging and adapter classes. > > > On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More > wrote: > > > Oh, I guess it depends on when we split, I was planning on taking up the > > new feature (mentioned in earlier email). > > If we decide to go for the feature I was hoping to get it in sooner > (before > > the split) if possible. > > > > > > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay wrote: > > > > > Actually, I meant 5/31 for a release date. > > > You think that is too early for a repackaged and narrowly scoped 1.0.0? > > > > > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More > > > wrote: > > > > > > > Great, thanks Larry for starting the discussion and the KIP ! > > > > > > > > May 31st target date sounds good, just to be sure, this date is when > we > > > > split 0.13 right ? > > > > > > > > KIP-5 looks good, I will try to see whether I can find any extended > > > classes > > > > that might need adapter classes. > > > > > > > > Best, > > > > Sandeep > > > > > > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay > > wrote: > > > > > > > > > Forgot to add the [1] to the initial mail. > > > > > > > > > > Enjoy... > > > > > > > > > > 1. > > > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704. > > > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T- > > > > rFEHJG6G5sB4Q%40mail.gmail. > > > > > com%3E > > > > > > > > > > > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay > > > wrote: > > > > > > > > > > > All - > > > > > > > > > > > > After many recent distractions, I would like to start the scoping > > and > > > > > > planning for what will likely be our 1.0.0 release. > > > > > > > > > > > > As discussed in [1], we will begin to repackaging/refactor master > > > after > > > > > > branching for an 0.13.0 release and only release 0.13.0 if the > work > > > on > > > > > > repackaging master doesn't seem like it will make whatever date > we > > > > chose > > > > > > for the release. > > > > > > > > > > > > That said, I would like to limit scope to only those new features > > and > > > > bug > > > > > > fixes that are absolutely necessary or low risk for breaking > > backward > > > > > > compatibility. > > > > > > > > > > > > I propose that the following is needed: > > > > > > > > > > > > * A KIP (KIP-5) be created for the repackaging/refactoring work > > > > required > > > > > > for the 1.0.0 release > > > > > > * Determine the existing JIRAs and patches that must/can be in > the > > > > > release > > > > > > but try and defer as many as possible > > > > > > * Determine required improvements - I have a few security related > > > > > > improvements in mind > > > > > > * Write up KIPs for features that involve architectural and/or > > > > strategic > > > > > > feature details > > > > > > * Determine when to branch for 0.13.0 and take on double commits > > for > > > > > 1.0.0 > > > > > > parity > > > > > > * Agree on a target release date > > > > > > > > > > > > My initial thought is to target May 31st as the release date. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > --larry > > > > > > > > > > > > > > > > > > > > >
Re: [FEATURE] Port Mapping for Topologies (Default Topologies per port)
Cool, glad you liked it ! I will start on the KIP and JIRA !
On Thu, Apr 27, 2017 at 12:28 PM, larry mccay wrote:
> Hi Sandeep -
>
> That sounds like a great improvement.
> Instead of having a single "default topology" we can map topologies to
> specific ports and have a dedicated URL without the gateway specific app
> context.
>
> This would provide interesting possibilities for existing hadoop cli's and
> possibly distcp.
> We will need to address the inabilitiy for the hadoop java client to deal
> with spnego challenges from the DN redirect next!
>
> Great idea - please write up the KIP and file a related JIRA.
>
> I will remove the default topology JIRAs from 0.13.0 for now in the
> interest of scope planning.
>
> thanks!
>
> --larry
>
> On Thu, Apr 27, 2017 at 12:06 PM, Sandeep More
> wrote:
>
> > As you might know, currently the default topology feature [1] is broken
> > [2], there were few attempts made to fix it but looks like the most
> recent
> > refactoring might have broken it again.
> >
> > I would like to propose a feature (similar to Default Topology) where one
> > can specify port a topology can listen on. The requests to this topology
> do
> > not have to include the {gateway} and {topology} elements. So essentially
> > it will be Default Topology feature but now we can have support for
> > multiple topologies (listening on different ports).
> >
> > Off-course the standard port configured through gateway config will work
> > just the way it always has, so all the existing features will not be
> > affected.
> >
> > I am planning to start a new KIP and try to put more information there. I
> > think this will be an exciting new feature and a good value add.
> >
> > Please let me know your thoughts !
> >
> > Best,
> > Sandeep
> >
> >
> >
> > [1]
> > http://knox.apache.org/books/knox-0-12-0/user-guide.html#
> > Default+Topology+URLs
> > [2] https://issues.apache.org/jira/browse/KNOX-797
> >
>
[jira] [Updated] (KNOX-438) Support both templeton and webhcat URLs
[ https://issues.apache.org/jira/browse/KNOX-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay updated KNOX-438: - Fix Version/s: (was: 0.13.0) Future > Support both templeton and webhcat URLs > --- > > Key: KNOX-438 > URL: https://issues.apache.org/jira/browse/KNOX-438 > Project: Apache Knox > Issue Type: Improvement > Components: Server >Affects Versions: 0.5.0 >Reporter: Larry McCay > Fix For: Future > > Attachments: KNOX-438-2.patch > > > WebHCatDeploymentContributor should add a pattern to the patterns and rules > for webhcat. This is a convenience to better align the role in the topology > file with the API - even though templeton is still officially used. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KNOX-486) Configuration Item gateway.gateway.conf.dir is Obsolete
[
https://issues.apache.org/jira/browse/KNOX-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Larry McCay updated KNOX-486:
-
Fix Version/s: (was: 0.13.0)
Future
> Configuration Item gateway.gateway.conf.dir is Obsolete
> ---
>
> Key: KNOX-486
> URL: https://issues.apache.org/jira/browse/KNOX-486
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.5.0
>Reporter: Larry McCay
>Assignee: Kevin Minder
> Fix For: Future
>
> Attachments: KNOX-486.1.patch
>
>
> Configuration Name in gateway-default.xml is not same as the name used in
> "org.apache.hadoop.gateway.config.impl.GatewayConfigImpl"
> * The deployments directory is no longer found in the conf directory.
> * This config item is not actually referenced anywhere in the server that I
> see with a quick grep
> * Perhaps we can use this to override the default conf dir location itself?
> * or perhaps it should just be removed
> * GatewayConfigImpl class level javadocs are also obsolete and should be
> addressed by this effort as well.
> Incorrect Configuration name in gateway-default.xml
> {noformat}
>
> gateway.gateway.conf.dir
> deployments
> The directory within GATEWAY_HOME that contains gateway
> topology deployments.
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (KNOX-503) Tests which include expected unreachable hosts fail with wildcard DNS records
[ https://issues.apache.org/jira/browse/KNOX-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay updated KNOX-503: - Fix Version/s: (was: 0.13.0) Future > Tests which include expected unreachable hosts fail with wildcard DNS records > - > > Key: KNOX-503 > URL: https://issues.apache.org/jira/browse/KNOX-503 > Project: Apache Knox > Issue Type: Bug > Components: Tests >Affects Versions: 0.6.0 >Reporter: Kristopher Kane >Priority: Minor > Fix For: Future > > Attachments: KNOX-503-AuditLoggingTest-01.patch, > KNOX-503-HttpClientDispatchTest-01.patch, > KNOX-503-WebHdfsHaHttpClientDispatchTest-01.patch > > > If the DNS zone of the build host contains wildcard DNS entries > (http://en.wikipedia.org/wiki/Wildcard_DNS_record) the following tests will > fail because 'unreachable-host' and 'outbound-host' will actually resolve: > AuditLoggingTest.java > HttpClientDispatchTest.java > WebHdfsHaHttpClientDispatchTest.java -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KNOX-727) Authorization Support for Knox Hosted Applications
[ https://issues.apache.org/jira/browse/KNOX-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay updated KNOX-727: - Fix Version/s: (was: 0.13.0) Future > Authorization Support for Knox Hosted Applications > -- > > Key: KNOX-727 > URL: https://issues.apache.org/jira/browse/KNOX-727 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 0.9.0 >Reporter: Zachary Blanco >Assignee: Zachary Blanco > Fix For: Future > > Attachments: admin.xml, knoxsso.xml > > > In the process of making an Administrator UI for the Knox, I've encountered > an issue where we can log into the app as an unauthorized user, but then fail > to make any AJAX requests. The Ajax requests return a 403 - which is probably > what should happen when logging into the app with an unauthorized user. > Steps to reproduce: > 1. Set up the Knox admin UI app using the instructions here: > https://github.com/ZacBlanco/knox-admin-ui/blob/master/README.md > 2. Place attached knoxsso and admin topology files under conf/topologies > 3. Navigate to https://www.local.com:8443/gateway/admin/knox-manager > 4. Attempt to login with guest:guest-password > The knox-manager page should render but in the dev console you should see > 403-Forbidden on the Ajax requests. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KNOX-761) KnoxSSO Needs to Support Multi-tenant Usecases
[ https://issues.apache.org/jira/browse/KNOX-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay updated KNOX-761: - Fix Version/s: (was: 0.13.0) Future > KnoxSSO Needs to Support Multi-tenant Usecases > -- > > Key: KNOX-761 > URL: https://issues.apache.org/jira/browse/KNOX-761 > Project: Apache Knox > Issue Type: Bug > Components: Server >Reporter: Larry McCay >Assignee: Larry McCay > Fix For: Future > > > In a deployment that separates tenant access to Hadoop resources through > dedicated topologies with tenant specific authentication, there are a couple > issues: > * pac4j provider seems to be caching config settings in a singleton which > makes the redirect url nondeterministic. > * knoxsso cookie would be trusted across tenant specific topologies which > could lead to unauthorized access to resources that belongs to another tenant > The use of tenant specific audience claims within the JWT token could be used > to mitigate the cross tenant trust issue. > We need to investigate the pac4j provider issue with the singleton config. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-784) java.lang.IllegalArgumentException: A metric named org.apache.http.conn.HttpClientConnectionManager.available-connections already exists
[ https://issues.apache.org/jira/browse/KNOX-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987070#comment-15987070 ] Larry McCay commented on KNOX-784: -- [~sumit.gupta]??? > java.lang.IllegalArgumentException: A metric named > org.apache.http.conn.HttpClientConnectionManager.available-connections > already exists > - > > Key: KNOX-784 > URL: https://issues.apache.org/jira/browse/KNOX-784 > Project: Apache Knox > Issue Type: Bug >Reporter: Nishant Bangarwa >Assignee: Sumit Gupta > Fix For: 0.13.0 > > > Facing this error on latest trunk version - > Caused by: java.lang.IllegalArgumentException: A metric named > org.apache.http.conn.HttpClientConnectionManager.available-connections > already exists > at > com.codahale.metrics.MetricRegistry.register(MetricRegistry.java:91) > at > com.codahale.metrics.httpclient.InstrumentedHttpClientConnectionManager.(InstrumentedHttpClientConnectionManager.java:63) > at > com.codahale.metrics.httpclient.InstrumentedHttpClientConnectionManager.(InstrumentedHttpClientConnectionManager.java:49) > at > com.codahale.metrics.httpclient.InstrumentedHttpClientConnectionManager.(InstrumentedHttpClientConnectionManager.java:41) > at > com.codahale.metrics.httpclient.InstrumentedHttpClientConnectionManager.(InstrumentedHttpClientConnectionManager.java:36) > at > org.apache.hadoop.gateway.services.metrics.impl.instr.InstrHttpClientBuilderProvider.getInstrumented(InstrHttpClientBuilderProvider.java:41) > at > org.apache.hadoop.gateway.services.metrics.impl.instr.InstrHttpClientBuilderProvider.getInstrumented(InstrHttpClientBuilderProvider.java:36) > at > org.apache.hadoop.gateway.services.metrics.impl.DefaultMetricsService.getInstrumented(DefaultMetricsService.java:128) > at > org.apache.hadoop.gateway.dispatch.DefaultHttpClientFactory.createHttpClient(DefaultHttpClientFactory.java:67) > at > org.apache.hadoop.gateway.dispatch.GatewayDispatchFilter.init(GatewayDispatchFilter.java:75) > at > org.apache.hadoop.gateway.GatewayFilter$Holder.getInstance(GatewayFilter.java:362) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-788) Apache Atlas Admin UI Support through Knox
[ https://issues.apache.org/jira/browse/KNOX-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987067#comment-15987067 ] Larry McCay commented on KNOX-788: -- [~Wancy] - are you planning to take this one on as well? > Apache Atlas Admin UI Support through Knox > -- > > Key: KNOX-788 > URL: https://issues.apache.org/jira/browse/KNOX-788 > Project: Apache Knox > Issue Type: New Feature > Components: Server >Reporter: Jeffrey E Rodriguez > Fix For: 0.13.0 > > > Apache Atlas Admin UI Support through Knox. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (KNOX-793) fail to put when the filesize equal 8g
[ https://issues.apache.org/jira/browse/KNOX-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay resolved KNOX-793. -- Resolution: Invalid > fail to put when the filesize equal 8g > --- > > Key: KNOX-793 > URL: https://issues.apache.org/jira/browse/KNOX-793 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 0.9.1 >Reporter: linwaterbin > Fix For: 0.13.0 > > > when I put a file that size over 8g must fail,but when I test other item as > following: > 1、the filesize is 7.9g，will success > 2、the filesize is 8.1g，will success > 3、the filesize is 8g，will fail > my command is: > curl -i -k -u root:123 -L -T l_3306_20161126_041435_xtra.split.0 -X PUT > "https://1.1.5.3:8080/db/st/webhdfs/v1/IED/l_3306_20161126_041435_xtra.split.0?op=CREATE"; > the 8g is a magic size，anyone can help me，thanks before :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-793) fail to put when the filesize equal 8g
[ https://issues.apache.org/jira/browse/KNOX-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987058#comment-15987058 ] Larry McCay commented on KNOX-793: -- Was unable to reproduce this issue - resolving as invalid. > fail to put when the filesize equal 8g > --- > > Key: KNOX-793 > URL: https://issues.apache.org/jira/browse/KNOX-793 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 0.9.1 >Reporter: linwaterbin > Fix For: 0.13.0 > > > when I put a file that size over 8g must fail,but when I test other item as > following: > 1、the filesize is 7.9g，will success > 2、the filesize is 8.1g，will success > 3、the filesize is 8g，will fail > my command is: > curl -i -k -u root:123 -L -T l_3306_20161126_041435_xtra.split.0 -X PUT > "https://1.1.5.3:8080/db/st/webhdfs/v1/IED/l_3306_20161126_041435_xtra.split.0?op=CREATE"; > the 8g is a magic size，anyone can help me，thanks before :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KNOX-797) Default Topology Feature Not Working
[
https://issues.apache.org/jira/browse/KNOX-797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Larry McCay updated KNOX-797:
-
Fix Version/s: (was: 0.13.0)
Future
> Default Topology Feature Not Working
>
>
> Key: KNOX-797
> URL: https://issues.apache.org/jira/browse/KNOX-797
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Reporter: Larry McCay
>Assignee: Larry McCay
> Fix For: Future
>
>
> From Mohammad Islam:
> I set "default.app.topology.name" in gateway-site.xml to "uber" (my default
> topology name).
> It worked fine if I gave the full URL. The command looks like this "curl
> http:///gateway/uber/webhdfs/v1/?op=GETHOMEDIRECTORY'".
>
> However, when I tried with command "curl
> http:///webhdfs/v1/?op=GETHOMEDIRECTORY'". I got the HTTP error
> code 500. I looked into gateway.log file and found quite a few error related
> to rewrite. The exact error messages are shown below:
> Error message
> {noformat}
> 2016-11-30 00:39:51,565 ERROR hadoop.gateway
> (UrlRewriteProcessor.java:rewrite(169)) - Failed to rewrite URL:
> http:///webhdfs/v1/?op=GETHOMEDIRECTORY, direction: IN via rule:
> WEBHDFS/webhdfs/inbound/namenode/root, status: FAILURE
> 2016-11-30 00:39:51,565 ERROR hadoop.gateway
> (UrlRewriteProcessor.java:rewrite(169)) - Failed to rewrite URL:
> http:///webhdfs/v1/?op=GETHOMEDIRECTORY, direction: IN via rule:
> WEBHDFS/webhdfs/inbound/namenode/root, status: FAILURE
> {noformat}
> After that, I modified the webhdfs/2.4.0/rewrite.xml by rewriting the
> following pattern and it worked for short URL but long URL faces the same
> issue.
> Original:
> {noformat}
> pattern="*://*:*/**/webhdfs/{version}/?{**}">
>
>
> {noformat}
> Modified :
> {noformat}
> pattern="*://*:*/webhdfs/{version}/?{**}">
>
>
> {noformat}
>
> Overall, the rewrite pattern may be the issue. We will need to support for
> both short and long URL. May be, we can add multiple rewrite rules for each
> route in service.xml.
> Is there any other cleaner way which may work for all cases such as webhdfs,
> yarn, hive, UIs etc?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KNOX-461) Leverage Directory Computed Attribute for User Group Discovery
[ https://issues.apache.org/jira/browse/KNOX-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987046#comment-15987046 ] Larry McCay commented on KNOX-461: -- Hi [~rlamothe] - thank you for this comment. I am curious whether you have considered either of these alternatives: 1. using PAM based authentication - http://knox.apache.org/books/knox-0-12-0/user-guide.html#PAM+based+Authentication 2. using the Hadoop Group Lookup Provider - http://knox.apache.org/books/knox-0-12-0/user-guide.html#Hadoop+Group+Lookup+Provider Either should give you what you need and #2 in particular will give you exactly the same group lookup as is used in Hadoop. If you think we should continue to invest in the Shiro provider group lookup then I'd like to understand why the other alternatives don't meet your needs. Thanks again for your comment - these insights are especially important to us! > Leverage Directory Computed Attribute for User Group Discovery > --- > > Key: KNOX-461 > URL: https://issues.apache.org/jira/browse/KNOX-461 > Project: Apache Knox > Issue Type: Improvement >Reporter: Dilli Arumugam >Priority: Critical > Fix For: Future > > > Leverage Directory Computed Attribute for User Group Discovery > We should use computed attribute memberof supported by Active Driectory to > discover groups of the authenticated user. This would significantly boost > performance as compared we computing groups using group search. > OpenLDAP also could be configured to return computed groups. > However, OpenLDAP would return this attribute as memberof. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-921) Httpclient max connections are always set to default values
[ https://issues.apache.org/jira/browse/KNOX-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987038#comment-15987038 ] Chandana Mirashi commented on KNOX-921: --- [~lmccay] Yes, I have started working on it. Will attach patch after testing. > Httpclient max connections are always set to default values > --- > > Key: KNOX-921 > URL: https://issues.apache.org/jira/browse/KNOX-921 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 0.11.0 >Reporter: Chandana Mirashi >Assignee: Chandana Mirashi > Fix For: 0.13.0 > > > When httpclient object gets created it is always set with default number of > max connections per route(2) and max connections total(20) irrespective of > value set in gateway.httpclient.maxConnections property. > When gateway.metrics.enabled property is set to false, only then > gateway.httpclient.maxConnections values take effect. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-461) Leverage Directory Computed Attribute for User Group Discovery
[ https://issues.apache.org/jira/browse/KNOX-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987004#comment-15987004 ] Ryan LaMothe commented on KNOX-461: --- Currently, KNOX is the only Hadoop component that we use which does not support Active Directory virtual attribute reverse lookups, which is forcing us to create complex work-arounds to try and use KNOX in our environment. In our case, we have hundreds of thousands of groups (e.g. RBAC) in Active Directory, so all of our enterprise software and tooling looks up Users first, then searches the User's 'memberOf' list and performs a reverse lookup of Groups. This works well because each User is typically only a 'memberOf' a few tens or hundreds of groups. It is also an extremely fast lookup, compared to group lookups, which is a primary reason Microsoft implemented the feature. By having KNOX perform group lookups first, then searching each group's 'member' list for Users, KNOX fails to scale or perform and this feature needs to be implemented ASAP in KNOX. > Leverage Directory Computed Attribute for User Group Discovery > --- > > Key: KNOX-461 > URL: https://issues.apache.org/jira/browse/KNOX-461 > Project: Apache Knox > Issue Type: Improvement >Reporter: Dilli Arumugam >Priority: Critical > Fix For: Future > > > Leverage Directory Computed Attribute for User Group Discovery > We should use computed attribute memberof supported by Active Driectory to > discover groups of the authenticated user. This would significantly boost > performance as compared we computing groups using group search. > OpenLDAP also could be configured to return computed groups. > However, OpenLDAP would return this attribute as memberof. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release
That sounds reasonable to me. I was hoping to get as many of the patches available and important bugs fixed before the split as well. Minimizing the double commits/patches is definitely in our interest. At the same time, we need to have enough time to spend on refactoring as well. I'm thinking that May 15th may be a good branch point - giving us 2 weeks to concentrate on repackaging and adapter classes. On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More wrote: > Oh, I guess it depends on when we split, I was planning on taking up the > new feature (mentioned in earlier email). > If we decide to go for the feature I was hoping to get it in sooner (before > the split) if possible. > > > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay wrote: > > > Actually, I meant 5/31 for a release date. > > You think that is too early for a repackaged and narrowly scoped 1.0.0? > > > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More > > wrote: > > > > > Great, thanks Larry for starting the discussion and the KIP ! > > > > > > May 31st target date sounds good, just to be sure, this date is when we > > > split 0.13 right ? > > > > > > KIP-5 looks good, I will try to see whether I can find any extended > > classes > > > that might need adapter classes. > > > > > > Best, > > > Sandeep > > > > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay > wrote: > > > > > > > Forgot to add the [1] to the initial mail. > > > > > > > > Enjoy... > > > > > > > > 1. > > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704. > > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T- > > > rFEHJG6G5sB4Q%40mail.gmail. > > > > com%3E > > > > > > > > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay > > wrote: > > > > > > > > > All - > > > > > > > > > > After many recent distractions, I would like to start the scoping > and > > > > > planning for what will likely be our 1.0.0 release. > > > > > > > > > > As discussed in [1], we will begin to repackaging/refactor master > > after > > > > > branching for an 0.13.0 release and only release 0.13.0 if the work > > on > > > > > repackaging master doesn't seem like it will make whatever date we > > > chose > > > > > for the release. > > > > > > > > > > That said, I would like to limit scope to only those new features > and > > > bug > > > > > fixes that are absolutely necessary or low risk for breaking > backward > > > > > compatibility. > > > > > > > > > > I propose that the following is needed: > > > > > > > > > > * A KIP (KIP-5) be created for the repackaging/refactoring work > > > required > > > > > for the 1.0.0 release > > > > > * Determine the existing JIRAs and patches that must/can be in the > > > > release > > > > > but try and defer as many as possible > > > > > * Determine required improvements - I have a few security related > > > > > improvements in mind > > > > > * Write up KIPs for features that involve architectural and/or > > > strategic > > > > > feature details > > > > > * Determine when to branch for 0.13.0 and take on double commits > for > > > > 1.0.0 > > > > > parity > > > > > * Agree on a target release date > > > > > > > > > > My initial thought is to target May 31st as the release date. > > > > > > > > > > Thoughts? > > > > > > > > > > --larry > > > > > > > > > > > > > > >
Re: [FEATURE] Port Mapping for Topologies (Default Topologies per port)
Hi Sandeep -
That sounds like a great improvement.
Instead of having a single "default topology" we can map topologies to
specific ports and have a dedicated URL without the gateway specific app
context.
This would provide interesting possibilities for existing hadoop cli's and
possibly distcp.
We will need to address the inabilitiy for the hadoop java client to deal
with spnego challenges from the DN redirect next!
Great idea - please write up the KIP and file a related JIRA.
I will remove the default topology JIRAs from 0.13.0 for now in the
interest of scope planning.
thanks!
--larry
On Thu, Apr 27, 2017 at 12:06 PM, Sandeep More
wrote:
> As you might know, currently the default topology feature [1] is broken
> [2], there were few attempts made to fix it but looks like the most recent
> refactoring might have broken it again.
>
> I would like to propose a feature (similar to Default Topology) where one
> can specify port a topology can listen on. The requests to this topology do
> not have to include the {gateway} and {topology} elements. So essentially
> it will be Default Topology feature but now we can have support for
> multiple topologies (listening on different ports).
>
> Off-course the standard port configured through gateway config will work
> just the way it always has, so all the existing features will not be
> affected.
>
> I am planning to start a new KIP and try to put more information there. I
> think this will be an exciting new feature and a good value add.
>
> Please let me know your thoughts !
>
> Best,
> Sandeep
>
>
>
> [1]
> http://knox.apache.org/books/knox-0-12-0/user-guide.html#
> Default+Topology+URLs
> [2] https://issues.apache.org/jira/browse/KNOX-797
>
Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release
Oh, I guess it depends on when we split, I was planning on taking up the new feature (mentioned in earlier email). If we decide to go for the feature I was hoping to get it in sooner (before the split) if possible. On Thu, Apr 27, 2017 at 11:53 AM, larry mccay wrote: > Actually, I meant 5/31 for a release date. > You think that is too early for a repackaged and narrowly scoped 1.0.0? > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More > wrote: > > > Great, thanks Larry for starting the discussion and the KIP ! > > > > May 31st target date sounds good, just to be sure, this date is when we > > split 0.13 right ? > > > > KIP-5 looks good, I will try to see whether I can find any extended > classes > > that might need adapter classes. > > > > Best, > > Sandeep > > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay wrote: > > > > > Forgot to add the [1] to the initial mail. > > > > > > Enjoy... > > > > > > 1. > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704. > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T- > > rFEHJG6G5sB4Q%40mail.gmail. > > > com%3E > > > > > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay > wrote: > > > > > > > All - > > > > > > > > After many recent distractions, I would like to start the scoping and > > > > planning for what will likely be our 1.0.0 release. > > > > > > > > As discussed in [1], we will begin to repackaging/refactor master > after > > > > branching for an 0.13.0 release and only release 0.13.0 if the work > on > > > > repackaging master doesn't seem like it will make whatever date we > > chose > > > > for the release. > > > > > > > > That said, I would like to limit scope to only those new features and > > bug > > > > fixes that are absolutely necessary or low risk for breaking backward > > > > compatibility. > > > > > > > > I propose that the following is needed: > > > > > > > > * A KIP (KIP-5) be created for the repackaging/refactoring work > > required > > > > for the 1.0.0 release > > > > * Determine the existing JIRAs and patches that must/can be in the > > > release > > > > but try and defer as many as possible > > > > * Determine required improvements - I have a few security related > > > > improvements in mind > > > > * Write up KIPs for features that involve architectural and/or > > strategic > > > > feature details > > > > * Determine when to branch for 0.13.0 and take on double commits for > > > 1.0.0 > > > > parity > > > > * Agree on a target release date > > > > > > > > My initial thought is to target May 31st as the release date. > > > > > > > > Thoughts? > > > > > > > > --larry > > > > > > > > > >
[FEATURE] Port Mapping for Topologies (Default Topologies per port)
As you might know, currently the default topology feature [1] is broken
[2], there were few attempts made to fix it but looks like the most recent
refactoring might have broken it again.
I would like to propose a feature (similar to Default Topology) where one
can specify port a topology can listen on. The requests to this topology do
not have to include the {gateway} and {topology} elements. So essentially
it will be Default Topology feature but now we can have support for
multiple topologies (listening on different ports).
Off-course the standard port configured through gateway config will work
just the way it always has, so all the existing features will not be
affected.
I am planning to start a new KIP and try to put more information there. I
think this will be an exciting new feature and a good value add.
Please let me know your thoughts !
Best,
Sandeep
[1]
http://knox.apache.org/books/knox-0-12-0/user-guide.html#Default+Topology+URLs
[2] https://issues.apache.org/jira/browse/KNOX-797
[jira] [Commented] (KNOX-819) Create test for avatica gateway service definition
[
https://issues.apache.org/jira/browse/KNOX-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986896#comment-15986896
]
Larry McCay commented on KNOX-819:
--
Hi [~elserj] - what is the status on this patch?
> Create test for avatica gateway service definition
> --
>
> Key: KNOX-819
> URL: https://issues.apache.org/jira/browse/KNOX-819
> Project: Apache Knox
> Issue Type: Test
> Components: Tests
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 0.13.0
>
> Attachments: KNOX-819.001.patch
>
>
> Follow-on from KNOX-817
> {quote}
> For our Apache releases, we largely use our clientDSL which is based on
> groovy.
> Let me point you to the one for hive as it requires a driver and the like as
> well.
> https://github.com/apache/knox/blob/master/gateway-release/home/samples/hive/groovy/jdbc/sandbox/HiveJDBCSample.groovy
> We would need to do something similar to that.
> It would help provide a blog on how to use Phoenix through Knox
> programmatically as well as with sqlline.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KNOX-829) HDFS commands for client: append,checksum,concat,homedir,chown,chmod,touch,symlink,truncate
[ https://issues.apache.org/jira/browse/KNOX-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986893#comment-15986893 ] Larry McCay commented on KNOX-829: -- [~treydone] - What is the status on this JIRA? We are in the process of planning for 0.13.0 and would like these improvements in if they are close and since we are targeting 0.13.0 as a possible 1.0.0 candidate. > HDFS commands for client: > append,checksum,concat,homedir,chown,chmod,touch,symlink,truncate > --- > > Key: KNOX-829 > URL: https://issues.apache.org/jira/browse/KNOX-829 > Project: Apache Knox > Issue Type: Improvement > Components: ClientDSL >Reporter: Vincent Devillers >Assignee: Vincent Devillers >Priority: Minor > Labels: KIP-4 > Fix For: 0.13.0 > > Attachments: KNOX-829.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-843) Add support for load balancing across HA instances
[ https://issues.apache.org/jira/browse/KNOX-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986890#comment-15986890 ] Jeffrey Rodriguez commented on KNOX-843: Thanks Larry. Let me review the patch this weekend and we can have an initial review next week. > Add support for load balancing across HA instances > -- > > Key: KNOX-843 > URL: https://issues.apache.org/jira/browse/KNOX-843 > Project: Apache Knox > Issue Type: New Feature > Components: Server >Affects Versions: 0.11.0 >Reporter: Sam Hjelmfelt >Assignee: Jeffrey E Rodriguez > Fix For: 0.13.0 > > Attachments: KNOX-843.patch > > > Knox should support load balancing across HA service instances rather than > just offering failover. > One solution may be to add an option to the HAProvider. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KNOX-832) Admin UI Should Display Unauthorized Message when 403 is Received via API
[ https://issues.apache.org/jira/browse/KNOX-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay updated KNOX-832: - Component/s: AdminUI > Admin UI Should Display Unauthorized Message when 403 is Received via API > - > > Key: KNOX-832 > URL: https://issues.apache.org/jira/browse/KNOX-832 > Project: Apache Knox > Issue Type: Bug > Components: AdminUI, Server >Reporter: Larry McCay > Fix For: Future > > > Logging into the Admin UI as a non-admin user such as guest in the DEMO LDAP > server results in the page being displayed with no topologies listed. > This should include an Unauthorized error message. > Additionally, we need to see whether authorization is being enforced on the > application itself and not just the API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KNOX-834) Admin UI Fails to Redirect to Knox SSO for API Calls
[ https://issues.apache.org/jira/browse/KNOX-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay updated KNOX-834: - Fix Version/s: (was: 0.13.0) Future > Admin UI Fails to Redirect to Knox SSO for API Calls > > > Key: KNOX-834 > URL: https://issues.apache.org/jira/browse/KNOX-834 > Project: Apache Knox > Issue Type: Bug > Components: AdminUI, Server >Reporter: Larry McCay > Fix For: Future > > > When using KnoxSSO the Admin UI will redirect appropriately to KnoxSSO when > attempting to load the main page either the first time or when the > cookie/token expires. > However, when the cookie/token expires or is removed and a different topology > is selected or a refresh is initiated the KnoxSSO redirect for the API call > is returned into the editor. > We need to detect that a redirect is being requested for the topology call > and force a refresh of the page or do the redirect from js. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KNOX-832) Admin UI Should Display Unauthorized Message when 403 is Received via API
[ https://issues.apache.org/jira/browse/KNOX-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay updated KNOX-832: - Fix Version/s: (was: 0.13.0) Future > Admin UI Should Display Unauthorized Message when 403 is Received via API > - > > Key: KNOX-832 > URL: https://issues.apache.org/jira/browse/KNOX-832 > Project: Apache Knox > Issue Type: Bug > Components: AdminUI, Server >Reporter: Larry McCay > Fix For: Future > > > Logging into the Admin UI as a non-admin user such as guest in the DEMO LDAP > server results in the page being displayed with no topologies listed. > This should include an Unauthorized error message. > Additionally, we need to see whether authorization is being enforced on the > application itself and not just the API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KNOX-834) Admin UI Fails to Redirect to Knox SSO for API Calls
[ https://issues.apache.org/jira/browse/KNOX-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay updated KNOX-834: - Component/s: AdminUI > Admin UI Fails to Redirect to Knox SSO for API Calls > > > Key: KNOX-834 > URL: https://issues.apache.org/jira/browse/KNOX-834 > Project: Apache Knox > Issue Type: Bug > Components: AdminUI, Server >Reporter: Larry McCay > Fix For: Future > > > When using KnoxSSO the Admin UI will redirect appropriately to KnoxSSO when > attempting to load the main page either the first time or when the > cookie/token expires. > However, when the cookie/token expires or is removed and a different topology > is selected or a refresh is initiated the KnoxSSO redirect for the API call > is returned into the editor. > We need to detect that a redirect is being requested for the topology call > and force a refresh of the page or do the redirect from js. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-835) Improvements for Oozie in the ClientDSL
[ https://issues.apache.org/jira/browse/KNOX-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986880#comment-15986880 ] Larry McCay commented on KNOX-835: -- Hi [~treydone] - do you plan to provide a new patch for this improvement? I am trying to scope 0.13.0 with an eye on making it our 1.0.0 release and would like to get this in if it is close. > Improvements for Oozie in the ClientDSL > --- > > Key: KNOX-835 > URL: https://issues.apache.org/jira/browse/KNOX-835 > Project: Apache Knox > Issue Type: Improvement > Components: ClientDSL >Reporter: Vincent Devillers >Assignee: Vincent Devillers >Priority: Minor > Labels: KIP-4 > Fix For: 0.13.0 > > Attachments: KNOX-835.patch > > > Implements: list, kill, change, info, definition, rerun, resume, log, start, > dryrun -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KNOX-840) Admin UI add ability to create a new topology based on a template
[ https://issues.apache.org/jira/browse/KNOX-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay updated KNOX-840: - Fix Version/s: (was: 0.13.0) Future > Admin UI add ability to create a new topology based on a template > - > > Key: KNOX-840 > URL: https://issues.apache.org/jira/browse/KNOX-840 > Project: Apache Knox > Issue Type: Improvement > Components: AdminUI >Reporter: Sumit Gupta >Assignee: Sumit Gupta > Fix For: Future > > > Admin user should be able to use the Admin UI to create new topologies based > on one of the template files that we ship with Knox. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-843) Add support for load balancing across HA instances
[ https://issues.apache.org/jira/browse/KNOX-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986871#comment-15986871 ] Larry McCay commented on KNOX-843: -- [~jeffreyr97] - I am trying to plan for the 0.13.0 scope with an eye on making this the 1.0.0 release instead. It seems that you intended to provide a follow up patch on this. What is your status with it? I am a bit concerned about introducing risk for previous HA behavior so extending the tests would be a good idea here. > Add support for load balancing across HA instances > -- > > Key: KNOX-843 > URL: https://issues.apache.org/jira/browse/KNOX-843 > Project: Apache Knox > Issue Type: New Feature > Components: Server >Affects Versions: 0.11.0 >Reporter: Sam Hjelmfelt >Assignee: Jeffrey E Rodriguez > Fix For: 0.13.0 > > Attachments: KNOX-843.patch > > > Knox should support load balancing across HA service instances rather than > just offering failover. > One solution may be to add an option to the HAProvider. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release
Actually, I meant 5/31 for a release date. You think that is too early for a repackaged and narrowly scoped 1.0.0? On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More wrote: > Great, thanks Larry for starting the discussion and the KIP ! > > May 31st target date sounds good, just to be sure, this date is when we > split 0.13 right ? > > KIP-5 looks good, I will try to see whether I can find any extended classes > that might need adapter classes. > > Best, > Sandeep > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay wrote: > > > Forgot to add the [1] to the initial mail. > > > > Enjoy... > > > > 1. > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704. > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T- > rFEHJG6G5sB4Q%40mail.gmail. > > com%3E > > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay wrote: > > > > > All - > > > > > > After many recent distractions, I would like to start the scoping and > > > planning for what will likely be our 1.0.0 release. > > > > > > As discussed in [1], we will begin to repackaging/refactor master after > > > branching for an 0.13.0 release and only release 0.13.0 if the work on > > > repackaging master doesn't seem like it will make whatever date we > chose > > > for the release. > > > > > > That said, I would like to limit scope to only those new features and > bug > > > fixes that are absolutely necessary or low risk for breaking backward > > > compatibility. > > > > > > I propose that the following is needed: > > > > > > * A KIP (KIP-5) be created for the repackaging/refactoring work > required > > > for the 1.0.0 release > > > * Determine the existing JIRAs and patches that must/can be in the > > release > > > but try and defer as many as possible > > > * Determine required improvements - I have a few security related > > > improvements in mind > > > * Write up KIPs for features that involve architectural and/or > strategic > > > feature details > > > * Determine when to branch for 0.13.0 and take on double commits for > > 1.0.0 > > > parity > > > * Agree on a target release date > > > > > > My initial thought is to target May 31st as the release date. > > > > > > Thoughts? > > > > > > --larry > > > > > >
Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release
Great, thanks Larry for starting the discussion and the KIP ! May 31st target date sounds good, just to be sure, this date is when we split 0.13 right ? KIP-5 looks good, I will try to see whether I can find any extended classes that might need adapter classes. Best, Sandeep On Thu, Apr 27, 2017 at 11:35 AM, larry mccay wrote: > Forgot to add the [1] to the initial mail. > > Enjoy... > > 1. > http://mail-archives.apache.org/mod_mbox/knox-dev/201704. > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-rFEHJG6G5sB4Q%40mail.gmail. > com%3E > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay wrote: > > > All - > > > > After many recent distractions, I would like to start the scoping and > > planning for what will likely be our 1.0.0 release. > > > > As discussed in [1], we will begin to repackaging/refactor master after > > branching for an 0.13.0 release and only release 0.13.0 if the work on > > repackaging master doesn't seem like it will make whatever date we chose > > for the release. > > > > That said, I would like to limit scope to only those new features and bug > > fixes that are absolutely necessary or low risk for breaking backward > > compatibility. > > > > I propose that the following is needed: > > > > * A KIP (KIP-5) be created for the repackaging/refactoring work required > > for the 1.0.0 release > > * Determine the existing JIRAs and patches that must/can be in the > release > > but try and defer as many as possible > > * Determine required improvements - I have a few security related > > improvements in mind > > * Write up KIPs for features that involve architectural and/or strategic > > feature details > > * Determine when to branch for 0.13.0 and take on double commits for > 1.0.0 > > parity > > * Agree on a target release date > > > > My initial thought is to target May 31st as the release date. > > > > Thoughts? > > > > --larry > > >
[jira] [Resolved] (KNOX-909) Ambari rewrite update for SmartSense
[ https://issues.apache.org/jira/browse/KNOX-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay resolved KNOX-909. -- Resolution: Fixed > Ambari rewrite update for SmartSense > > > Key: KNOX-909 > URL: https://issues.apache.org/jira/browse/KNOX-909 > Project: Apache Knox > Issue Type: Bug >Reporter: Larry McCay >Assignee: Larry McCay > Fix For: 0.13.0 > > > Ambari service definition must account for smartsense URLs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (KNOX-919) Upgrade Knox 0.9.1 to 0.12 - Url matching failed
[
https://issues.apache.org/jira/browse/KNOX-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986848#comment-15986848
]
Larry McCay commented on KNOX-919:
--
[~Yoann] - have you made any progress on this issue?
We are currently trying to scope the 0.13.0 release and need to know whether
there is something here that requires work.
> Upgrade Knox 0.9.1 to 0.12 - Url matching failed
>
>
> Key: KNOX-919
> URL: https://issues.apache.org/jira/browse/KNOX-919
> Project: Apache Knox
> Issue Type: Bug
> Components: Release
>Affects Versions: 0.12.0
> Environment: Hadoop Cluster
> LDAP/Kerberos
>Reporter: Yoann Bellet
>Priority: Blocker
> Fix For: 0.13.0
>
>
> Hello,
> I'm trying to upgrade our Knox on Preproduction plateform from version 0.9.1
> to 0.12, (I deployed the same configuration, i don't see any big differencies
> on this side).
> Logs seems to be identicals
> I'm trying these commands :
> {code}
> ./bin/knoxcli.sh user-auth-test --cluster bigdata --u user--p passwd--g --d
> ./bin/knoxcli.sh validate-topology --cluster bigdata
> {code}
> And it works for the two versions.
> But when I'm trying to contact webhdfs with this curl command
> curl -ivk -u user-X GET
> 'https://knox01:8443/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS'
> with 0.9.1 :
> {code}
> 2017-04-03T15:36:24.111779+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFSaccess|uri|/gateway/bigdata/webhdfs/v1/user/user?OP=LISTSTATUS|unavailable|Request
> method: GET
> 2017-04-03T15:36:24.112571+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFS|user|||authentication|uri|/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS|success|
> 2017-04-03T15:36:24.112709+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFS|user|||authentication|uri|/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS|success|Groups:
> []
> 2017-04-03T15:36:24.114225+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFS|user|||dispatch|uri|http://namenode01:50070/webhdfs/v1/user?doAs=user&OP=LISTSTATUS|unavailable|Request
> method: GET
> 2017-04-03T15:36:24.146810+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFS|user|||dispatch|uri|http://namenode01:50070/webhdfs/v1/user?doAs=user&OP=LISTSTATUS|success|Response
> status: 200
> 2017-04-03T15:36:24.152511+02:00 localhost 17/04/03 15:36:24
> ||e196f2d6-bdbe-4e66-b707-8d52c8bafd98|audit|WEBHDFS|user|||access|uri|/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS|success|Response
> status: 200
> {code}
> whith 0.12 :
> {code}
> 2017-04-03T15:37:01.651295+02:00 localhost 17/04/03 15:37:01
> ||8c8c0ef2-db5c-4bc4-83c3-5ef35a7e482e|audit|access|uri|/gateway/bigdata/gateway/bigdata/webhdfs/v1/user/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS|unavailable|Request
> method: GET
> 2017-04-03T15:37:01+02:00 knox01 knox WARN - org.apache.hadoop.gatewayFailed
> to match path /gateway/bigdata/webhdfs/v1/user
> 2017-04-03T15:37:01.652123+02:00 localhost 17/04/03 15:37:01
> ||8c8c0ef2-db5c-4bc4-83c3-5ef35a7e482e|audit|access|uri|/gateway/bigdata/gateway/bigdata/webhdfs/v1/user/gateway/bigdata/webhdfs/v1/user?OP=LISTSTATUS|success|Response
> status: 404
> {code}
> Authentication is not tested and namenode is not call on Knox 0.12 because
> uri matching reveal an error, i don't know why Knox add "gateway/bigdata"
> many times on uri...
> Regards.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KNOX-921) Httpclient max connections are always set to default values
[ https://issues.apache.org/jira/browse/KNOX-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986844#comment-15986844 ] Larry McCay commented on KNOX-921: -- [~cmirashi] - are you planning to contribute a patch for this? > Httpclient max connections are always set to default values > --- > > Key: KNOX-921 > URL: https://issues.apache.org/jira/browse/KNOX-921 > Project: Apache Knox > Issue Type: Bug > Components: Server >Affects Versions: 0.11.0 >Reporter: Chandana Mirashi >Assignee: Chandana Mirashi > Fix For: 0.13.0 > > > When httpclient object gets created it is always set with default number of > max connections per route(2) and max connections total(20) irrespective of > value set in gateway.httpclient.maxConnections property. > When gateway.metrics.enabled property is set to false, only then > gateway.httpclient.maxConnections values take effect. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release
Forgot to add the [1] to the initial mail. Enjoy... 1. http://mail-archives.apache.org/mod_mbox/knox-dev/201704.mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-rFEHJG6G5sB4Q%40mail.gmail.com%3E On Wed, Apr 26, 2017 at 12:45 PM, larry mccay wrote: > All - > > After many recent distractions, I would like to start the scoping and > planning for what will likely be our 1.0.0 release. > > As discussed in [1], we will begin to repackaging/refactor master after > branching for an 0.13.0 release and only release 0.13.0 if the work on > repackaging master doesn't seem like it will make whatever date we chose > for the release. > > That said, I would like to limit scope to only those new features and bug > fixes that are absolutely necessary or low risk for breaking backward > compatibility. > > I propose that the following is needed: > > * A KIP (KIP-5) be created for the repackaging/refactoring work required > for the 1.0.0 release > * Determine the existing JIRAs and patches that must/can be in the release > but try and defer as many as possible > * Determine required improvements - I have a few security related > improvements in mind > * Write up KIPs for features that involve architectural and/or strategic > feature details > * Determine when to branch for 0.13.0 and take on double commits for 1.0.0 > parity > * Agree on a target release date > > My initial thought is to target May 31st as the release date. > > Thoughts? > > --larry >
