[jira] [Commented] (KNOX-758) Add service definition for proxying Druid Queries, Coordinator & Indexer UI

[Nishant Bangarwa (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15656222#comment-15656222
 ] 

Nishant Bangarwa commented on KNOX-758:
---

[~sumit.gupta] yes, the patch needs to be updated. working on it, will update 
once done. 

> Add service definition for proxying Druid Queries, Coordinator & Indexer UI 
> 
>
> Key: KNOX-758
> URL: https://issues.apache.org/jira/browse/KNOX-758
> Project: Apache Knox
>  Issue Type: New Feature
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
> Fix For: 0.11.0
>
> Attachments: KNOX-758.patch
>
>
> Druid (http://druid.io) is an Open Source distributed Database for providing 
> sub-second OLAP queries. This task is to add service definitions for proxying 
> Druid UI and queries using KNOX gateway. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Supporting Email address in preauth header

[larry mccay]

Oops - that was the wrong link for the header based preauth - sorry:

http://knox.apache.org/books/knox-0-10-0/user-guide.html#Preauthenticated+SSO+Provider

On Thu, Nov 10, 2016 at 9:41 PM, larry mccay  wrote:

> For that usecase, I would consider the HeaderPreAuth federation provider
> and mutual authentication between your multi-tenant service and Knox.
>
> The SSL based mutual authentication ensures that there is a trust
> relationship between the service and Knox.
> Otherwise, anyone could call it and pass the header with any username.
>
> http://knox.apache.org/books/knox-0-10-0/user-guide.html#
> HadoopAuth+Authentication+Provider
> http://knox.apache.org/books/knox-0-10-0/user-guide.html#
> Mutual+Authentication+with+SSL
>
> On Thu, Nov 10, 2016 at 9:32 PM, Mohammad Islam <
> misla...@yahoo.com.invalid> wrote:
>
>> Excellent!! It shows Knox has a lot of important features with
>> flexibility.I will give a try.
>> In a related note, does Knox allows its user (service) to impersonate its
>> end user. For example,I have a multi-tenant service which is running as
>> user "serviceX". It wants to access to WebHDFS as its end-user (say userY)
>> not as  serviceX. Does Knox provide this type of impersonation or doas() by
>> its client?
>> Any link would be really helpful? Regards,Mohammad
>>
>>
>>
>>
>> On Thursday, November 10, 2016 3:07 PM, larry mccay <
>> lmc...@apache.org> wrote:
>>
>>
>>  I believe that what you want to do is more like:
>>
>> * HeaderPreAuthFederationFilter *as is*
>> * RegexIdentityAssertionFilter to extract the username from the email
>> address
>>
>> http://knox.apache.org/books/knox-0-10-0/user-guide.html#Reg
>> ular+Expression+Identity+Assertion+Provider
>>
>> This allows the incoming header to be flown through the provider chain as
>> the email address until it gets to identity assertion provider. The
>> identity assertion provider is responsible for determining the identity to
>> assert to the backend service. It is invoked prior to authorization checks
>> within the request processing as well. This allows the authorization
>> checks
>> to be applied to the asserted identity as they will be done inside the
>> cluster as well.
>>
>>
>>
>> On Thu, Nov 10, 2016 at 5:18 PM, Mohammad Islam 
>> wrote:
>>
>> > Hi,
>> > Currently Knox supports username in http header with key SMUSER (which
>> is
>> > configurable).
>> >
>> > I'm wandering how can we support email address in place of user name. In
>> > other words, in my use-case, preauth filter gets the email address as
>> > header, can we parse the email address to get the username/principal
>> name?
>> >
>> > I was considering two options:
>> >
>> > 1. Extending current functionality of HeaderPreAuthFederationFilter to
>> > support email address as well. That means if SMUSER is null, check for
>> > email address and then parse to get the principal name.
>> >
>> > 2. In HeaderPreAuthContributor class, set the "PREAUTH_FILTER_CLASSNAME"
>> > from configuration. Currently it is always assigned to "
>> > HeaderPreAuthFederationFilter". I believe this approach is
>> > extendable/pluggable.
>> >
>> > What do you guys think?
>> >
>> > Based on your suggestion, I can start working on it.
>> >
>> > Regards,
>> > Mohammad
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>
>

Re: Supporting Email address in preauth header

[larry mccay]

For that usecase, I would consider the HeaderPreAuth federation provider
and mutual authentication between your multi-tenant service and Knox.

The SSL based mutual authentication ensures that there is a trust
relationship between the service and Knox.
Otherwise, anyone could call it and pass the header with any username.

http://knox.apache.org/books/knox-0-10-0/user-guide.html#HadoopAuth+Authentication+Provider
http://knox.apache.org/books/knox-0-10-0/user-guide.html#Mutual+Authentication+with+SSL

On Thu, Nov 10, 2016 at 9:32 PM, Mohammad Islam 
wrote:

> Excellent!! It shows Knox has a lot of important features with
> flexibility.I will give a try.
> In a related note, does Knox allows its user (service) to impersonate its
> end user. For example,I have a multi-tenant service which is running as
> user "serviceX". It wants to access to WebHDFS as its end-user (say userY)
> not as  serviceX. Does Knox provide this type of impersonation or doas() by
> its client?
> Any link would be really helpful? Regards,Mohammad
>
>
>
>
> On Thursday, November 10, 2016 3:07 PM, larry mccay 
> wrote:
>
>
>  I believe that what you want to do is more like:
>
> * HeaderPreAuthFederationFilter *as is*
> * RegexIdentityAssertionFilter to extract the username from the email
> address
>
> http://knox.apache.org/books/knox-0-10-0/user-guide.html#
> Regular+Expression+Identity+Assertion+Provider
>
> This allows the incoming header to be flown through the provider chain as
> the email address until it gets to identity assertion provider. The
> identity assertion provider is responsible for determining the identity to
> assert to the backend service. It is invoked prior to authorization checks
> within the request processing as well. This allows the authorization checks
> to be applied to the asserted identity as they will be done inside the
> cluster as well.
>
>
>
> On Thu, Nov 10, 2016 at 5:18 PM, Mohammad Islam 
> wrote:
>
> > Hi,
> > Currently Knox supports username in http header with key SMUSER (which is
> > configurable).
> >
> > I'm wandering how can we support email address in place of user name. In
> > other words, in my use-case, preauth filter gets the email address as
> > header, can we parse the email address to get the username/principal
> name?
> >
> > I was considering two options:
> >
> > 1. Extending current functionality of HeaderPreAuthFederationFilter to
> > support email address as well. That means if SMUSER is null, check for
> > email address and then parse to get the principal name.
> >
> > 2. In HeaderPreAuthContributor class, set the "PREAUTH_FILTER_CLASSNAME"
> > from configuration. Currently it is always assigned to "
> > HeaderPreAuthFederationFilter". I believe this approach is
> > extendable/pluggable.
> >
> > What do you guys think?
> >
> > Based on your suggestion, I can start working on it.
> >
> > Regards,
> > Mohammad
> >
> >
> >
> >
>
>
>
>

Re: Supporting Email address in preauth header

[Mohammad Islam]

Excellent!! It shows Knox has a lot of important features with flexibility.I 
will give a try.
In a related note, does Knox allows its user (service) to impersonate its end 
user. For example,I have a multi-tenant service which is running as user 
"serviceX". It wants to access to WebHDFS as its end-user (say userY) not as  
serviceX. Does Knox provide this type of impersonation or doas() by its client? 
Any link would be really helpful? Regards,Mohammad


 

On Thursday, November 10, 2016 3:07 PM, larry mccay  
wrote:
 

 I believe that what you want to do is more like:

* HeaderPreAuthFederationFilter *as is*
* RegexIdentityAssertionFilter to extract the username from the email
address

http://knox.apache.org/books/knox-0-10-0/user-guide.html#Regular+Expression+Identity+Assertion+Provider

This allows the incoming header to be flown through the provider chain as
the email address until it gets to identity assertion provider. The
identity assertion provider is responsible for determining the identity to
assert to the backend service. It is invoked prior to authorization checks
within the request processing as well. This allows the authorization checks
to be applied to the asserted identity as they will be done inside the
cluster as well.



On Thu, Nov 10, 2016 at 5:18 PM, Mohammad Islam  wrote:

> Hi,
> Currently Knox supports username in http header with key SMUSER (which is
> configurable).
>
> I'm wandering how can we support email address in place of user name. In
> other words, in my use-case, preauth filter gets the email address as
> header, can we parse the email address to get the username/principal name?
>
> I was considering two options:
>
> 1. Extending current functionality of HeaderPreAuthFederationFilter to
> support email address as well. That means if SMUSER is null, check for
> email address and then parse to get the principal name.
>
> 2. In HeaderPreAuthContributor class, set the "PREAUTH_FILTER_CLASSNAME"
> from configuration. Currently it is always assigned to "
> HeaderPreAuthFederationFilter". I believe this approach is
> extendable/pluggable.
>
> What do you guys think?
>
> Based on your suggestion, I can start working on it.
>
> Regards,
> Mohammad
>
>
>
>


   

Re: Supporting Email address in preauth header

[larry mccay]

I believe that what you want to do is more like:

* HeaderPreAuthFederationFilter *as is*
* RegexIdentityAssertionFilter to extract the username from the email
address

http://knox.apache.org/books/knox-0-10-0/user-guide.html#Regular+Expression+Identity+Assertion+Provider

This allows the incoming header to be flown through the provider chain as
the email address until it gets to identity assertion provider. The
identity assertion provider is responsible for determining the identity to
assert to the backend service. It is invoked prior to authorization checks
within the request processing as well. This allows the authorization checks
to be applied to the asserted identity as they will be done inside the
cluster as well.



On Thu, Nov 10, 2016 at 5:18 PM, Mohammad Islam  wrote:

> Hi,
> Currently Knox supports username in http header with key SMUSER (which is
> configurable).
>
> I'm wandering how can we support email address in place of user name. In
> other words, in my use-case, preauth filter gets the email address as
> header, can we parse the email address to get the username/principal name?
>
> I was considering two options:
>
> 1. Extending current functionality of HeaderPreAuthFederationFilter to
> support email address as well. That means if SMUSER is null, check for
> email address and then parse to get the principal name.
>
> 2. In HeaderPreAuthContributor class, set the "PREAUTH_FILTER_CLASSNAME"
> from configuration. Currently it is always assigned to "
> HeaderPreAuthFederationFilter". I believe this approach is
> extendable/pluggable.
>
> What do you guys think?
>
> Based on your suggestion, I can start working on it.
>
> Regards,
> Mohammad
>
>
>
>

Supporting Email address in preauth header

[Mohammad Islam]

Hi,Currently Knox supports username in http header with key SMUSER (which is 
configurable). 
I'm wandering how can we support email address in place of user name. In other 
words, in my use-case, preauth filter gets the email address as header, can we 
parse the email address to get the username/principal name?
I was considering two options:
1. Extending current functionality of HeaderPreAuthFederationFilter to support 
email address as well. That means if SMUSER is null, check for email address 
and then parse to get the principal name.
2. In HeaderPreAuthContributor class, set the "PREAUTH_FILTER_CLASSNAME" from 
configuration. Currently it is always assigned to 
"HeaderPreAuthFederationFilter". I believe this approach is 
extendable/pluggable.
What do you guys think?
Based on your suggestion, I can start working on it.
Regards,Mohammad 

[jira] [Created] (KNOX-783) Add REST API for getting metrics from Knox

[Sumit Gupta (JIRA)]

Sumit Gupta created KNOX-783:


 Summary: Add REST API for getting metrics from Knox
 Key: KNOX-783
 URL: https://issues.apache.org/jira/browse/KNOX-783
 Project: Apache Knox
  Issue Type: Bug
Affects Versions: 0.11.0
Reporter: Sumit Gupta
 Fix For: Future






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KNOX-571) UI Web pages should have a way to logout

[Sumit Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15655273#comment-15655273
 ] 

Sumit Gupta commented on KNOX-571:
--

[~jeffreyr97], I want to ensure that this JIRA is still relevant and determine 
whether you are still looking to provide a patch for this. Our UI proxying thus 
far has used a pass through approach for auth, so I'm not sure logout belongs 
in Knox anymore...but I might be missing the problem you are trying to solve.

> UI Web pages should have a way to logout
> 
>
> Key: KNOX-571
> URL: https://issues.apache.org/jira/browse/KNOX-571
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 0.7.0
> Environment: Redhat/Windows
>Reporter: Jeffrey E  Rodriguez
> Fix For: Future
>
> Attachments: knox_logout_design.jpg
>
>
> UI using Knox as a proxy should have  a way to define a logout so Browser to 
> Knox session is invalidated and user is challenged for Authentication. This 
> is a web security requirement to prevent session hijacking attacks.
> References
> https://www.owasp.org/index.php/Session_hijacking_attack
> https://owasp.org/index.php/Testing_for_logout_functionality_%28OTG-SESS-007%29



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KNOX-749) Simple Admin UI

[Sumit Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15655263#comment-15655263
 ] 

Sumit Gupta commented on KNOX-749:
--

I'll take a look at this in the next few days with an eye on trying to get 
something simple in using [~zacblanco]'s patch as the base and adding something 
only if needed.

> Simple Admin UI
> ---
>
> Key: KNOX-749
> URL: https://issues.apache.org/jira/browse/KNOX-749
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Reporter: Larry McCay
>Assignee: Zachary Blanco
> Fix For: 0.11.0
>
> Attachments: knox-admin-ui-001.patch
>
>
> We need to a simple UI for management/admin insights based on the Knox Admin 
> API.
> We can start with a read-only iteration and extend it in a future release.
> [~zacblanco] has expressed interest in this effort on the dev list and 
> possibly other JIRAs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KNOX-571) UI Web pages should have a way to logout

[Sumit Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15655246#comment-15655246
 ] 

Sumit Gupta commented on KNOX-571:
--

[~lmccay], does this relate to [KNOX-763]? 

> UI Web pages should have a way to logout
> 
>
> Key: KNOX-571
> URL: https://issues.apache.org/jira/browse/KNOX-571
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 0.7.0
> Environment: Redhat/Windows
>Reporter: Jeffrey E  Rodriguez
> Fix For: Future
>
> Attachments: knox_logout_design.jpg
>
>
> UI using Knox as a proxy should have  a way to define a logout so Browser to 
> Knox session is invalidated and user is challenged for Authentication. This 
> is a web security requirement to prevent session hijacking attacks.
> References
> https://www.owasp.org/index.php/Session_hijacking_attack
> https://owasp.org/index.php/Testing_for_logout_functionality_%28OTG-SESS-007%29



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KNOX-758) Add service definition for proxying Druid Queries, Coordinator & Indexer UI

[Sumit Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15655238#comment-15655238
 ] 

Sumit Gupta commented on KNOX-758:
--

Hi [~nishantbangarwa], will [KNOX-763] change this patch? I would be happy to 
try this out soon but I'm curious if I should wait if it is going to change.

> Add service definition for proxying Druid Queries, Coordinator & Indexer UI 
> 
>
> Key: KNOX-758
> URL: https://issues.apache.org/jira/browse/KNOX-758
> Project: Apache Knox
>  Issue Type: New Feature
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
> Fix For: 0.11.0
>
> Attachments: KNOX-758.patch
>
>
> Druid (http://druid.io) is an Open Source distributed Database for providing 
> sub-second OLAP queries. This task is to add service definitions for proxying 
> Druid UI and queries using KNOX gateway. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (KNOX-643) Add the ability to gather and expose metrics in the gateway

[Sumit Gupta (JIRA)]

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

Sumit Gupta resolved KNOX-643.
--
   Resolution: Fixed
Fix Version/s: (was: Future)
   0.11.0

Creating additional JIRAs for further enhancements and for the missing 
requirements in the original list that we still think need to be done.

> Add the ability to gather and expose metrics in the gateway
> ---
>
> Key: KNOX-643
> URL: https://issues.apache.org/jira/browse/KNOX-643
> Project: Apache Knox
>  Issue Type: New Feature
>  Components: Server
>Affects Versions: 0.8.0
>Reporter: Sumit Gupta
>Assignee: Sumit Gupta
> Fix For: 0.11.0
>
> Attachments: KNOX-643.patch
>
>
> The goal would be to capture various request/response metrics in the gateway 
> and expose them via JMX and/or REST.
> Some of the requests on the dev mailing list are:
> - Capture TPS both at the service level as well as aggregate for the server 
> instance.
> - Byte transfer counts per service and aggregate
> - Unsuccessful login
> - Successful login but overall return was HTTP 500 which indicates failure
> on the cluster side.  An example would be users connecting to Knox with
> valid AD user/pass but which were not authorized in the cluster.  This can
> happen when the cluster is in secure mode but a service like Centrify has
> not allowed the user into the cluster's zone.
> - Unsuccessful AD lookup by Knox - user doesn't exist.
> - Connection counts that used and didn't use an auth cookie and resulted in
> an AD lookup
> - Current open connections 
> - Capability to reset the aggregate counters while Knox is running.
> - Ability to hook into Ambari's Metric collection framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (KNOX-782) Add aggregate metrics at the topology and server level

[Sumit Gupta (JIRA)]

Sumit Gupta created KNOX-782:


 Summary: Add aggregate metrics at the topology and server level
 Key: KNOX-782
 URL: https://issues.apache.org/jira/browse/KNOX-782
 Project: Apache Knox
  Issue Type: Bug
Affects Versions: 0.11.0
Reporter: Sumit Gupta


Metrics in the initial [KNOX-643] implementation are at the service level. We 
need some aggregation at the topology level if possible, but certainly at the 
server level.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (KNOX-781) Add a metrics reporter for Ambari Metrics

[Sumit Gupta (JIRA)]

Sumit Gupta created KNOX-781:


 Summary: Add a metrics reporter for Ambari Metrics
 Key: KNOX-781
 URL: https://issues.apache.org/jira/browse/KNOX-781
 Project: Apache Knox
  Issue Type: Bug
Affects Versions: 0.11.0
Reporter: Sumit Gupta


The default reporters in the initial implementation are JMX and Graphite based. 
We need to add reporting capability for Ambari Metrics.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KNOX-643) Add the ability to gather and expose metrics in the gateway

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15655154#comment-15655154
 ] 

ASF subversion and git services commented on KNOX-643:
--

Commit f345f889508306c739b15c49a462b3d1d838768a in knox's branch 
refs/heads/master from [~sumit.gupta]
[ https://git-wip-us.apache.org/repos/asf?p=knox.git;h=f345f88 ]

KNOX-643 Initial metrics api and implementation


> Add the ability to gather and expose metrics in the gateway
> ---
>
> Key: KNOX-643
> URL: https://issues.apache.org/jira/browse/KNOX-643
> Project: Apache Knox
>  Issue Type: New Feature
>  Components: Server
>Affects Versions: 0.8.0
>Reporter: Sumit Gupta
>Assignee: Sumit Gupta
> Fix For: Future
>
> Attachments: KNOX-643.patch
>
>
> The goal would be to capture various request/response metrics in the gateway 
> and expose them via JMX and/or REST.
> Some of the requests on the dev mailing list are:
> - Capture TPS both at the service level as well as aggregate for the server 
> instance.
> - Byte transfer counts per service and aggregate
> - Unsuccessful login
> - Successful login but overall return was HTTP 500 which indicates failure
> on the cluster side.  An example would be users connecting to Knox with
> valid AD user/pass but which were not authorized in the cluster.  This can
> happen when the cluster is in secure mode but a service like Centrify has
> not allowed the user into the cluster's zone.
> - Unsuccessful AD lookup by Knox - user doesn't exist.
> - Connection counts that used and didn't use an auth cookie and resulted in
> an AD lookup
> - Current open connections 
> - Capability to reset the aggregate counters while Knox is running.
> - Ability to hook into Ambari's Metric collection framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] KIP-4: KnoxShell Improvements Proposal for 0.11.0

[larry mccay]

Thanks for your thoughts, Sandeep.
Replies inline...

On Thu, Nov 10, 2016 at 9:51 AM, Sandeep More  wrote:

> Thanks Larry !
>
> I really like the idea of expanding KnoxShell, following are my initial
> thoughts on KIP-4
>
> 1) It appears that the "Discussion thread" points to KIP-1 thread.
>

It was a placeholder until I started the actual thread. It's fixed. :)


> 2) I like the idea of Programming Model/Definitions, like you mentioned
> some use cases would be great to get jump started. Do you think they should
> get their own sub KIP when the formalization process starts ?
>

Not sure whether that would be necessary - let's wait and see.


> 3) KnoxShell Session/SSO - Headless scripts would be cool. Also, do you
> think KnoxShell should retain some state data i.e. say command_1 returns a
> json, then command_2 might use it as an argument to do something else. One
> of the problem with this, other then storing state, would be
>  transformations (might or might not be needed) , may be this can be
> something of a future enhancement.
>

Interesting thought.
Seems this would be a way to maybe pipe output from one script to another
which would lead to the development of smaller and specific tooling scripts.
Alternatively, scripts that do the entire job would certainly be possible
without having to externalize state or output.

Seems this would be an interesting outcome of defining was is actually
needed in the programming model.


>
> Best,
> Sandeep
>
>
>
>
>
>
> On Wed, Nov 9, 2016 at 3:49 PM, larry mccay  wrote:
>
> > All -
> >
> > I've taken a stab at a first iteration of the KIP for KnoxShell
> > improvements.
> >
> > https://cwiki.apache.org/confluence/display/KNOX/KIP-4+
> > KnoxShell+Improvements
> >
> > We should try and discuss these ideas and come up with what exactly what
> > needs to be in a programming model definition and SDK and whether they
> are
> > compelling enough to pursue.
> >
> > I think that there are some exciting opportunities here when we consider
> > the cloud deployments - as I've said.
> >
> > Let's figure out what we would like to light up in the 0.11.0 if
> anything!
> >
> > thanks,
> >
> > --larry
> >
>

[jira] [Commented] (KNOX-779) Exclude older org.codehaus.jackson dependencies from build cycle

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654256#comment-15654256
 ] 

ASF subversion and git services commented on KNOX-779:
--

Commit c6aa4700afaeba0d23c643e97feb3410047f5b23 in knox's branch 
refs/heads/master from [~lmccay]
[ https://git-wip-us.apache.org/repos/asf?p=knox.git;h=c6aa470 ]

KNOX-779 - Exclude older org.codehaus.jackson dependencies from build cycle

> Exclude older org.codehaus.jackson dependencies from build cycle
> 
>
> Key: KNOX-779
> URL: https://issues.apache.org/jira/browse/KNOX-779
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 0.11.0
>
> Attachments: 
> 0001-KNOX-779-Exclude-older-org.codehaus.jackson-dependen.patch
>
>
> Currently there is a mix of two different Jackson dependencies in the build 
> cycle, due to the older "org.codehaus.jackson" dependency coming from the 
> rest-assured test dependency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (KNOX-780) Remove dependency on SNAPSHOT version of hadoop-common-test jar

[Sumit Gupta (JIRA)]

Sumit Gupta created KNOX-780:


 Summary: Remove dependency on SNAPSHOT version of 
hadoop-common-test jar
 Key: KNOX-780
 URL: https://issues.apache.org/jira/browse/KNOX-780
 Project: Apache Knox
  Issue Type: Bug
Affects Versions: 0.10.0
Reporter: Sumit Gupta
 Fix For: 0.11.0


When doing a clean build without a populated local maven repository it was 
found that we have a dependency on a SNAPSHOT jar. This is okay for development 
but not okay at all for releases. We need to determine why we are pulling this 
dependency and move to a non-snapshot version of it.

The following was found by [~kamrul]

{code}
Failed to execute goal 
org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process (default) on 
project gateway-test-release: Failed to resolve dependencies for one or more 
projects in the reactor. Reason: Missing:[ERROR] --[ERROR] 1) 
org.apache.hadoop:hadoop-common-test:jar:0.23.0-SNAPSHOT[ERROR] [ERROR] Try 
downloading the file manually from the project website.[ERROR] [ERROR] Then, 
install it using the command:[ERROR] mvn install:install-file 
-DgroupId=org.apache.hadoop -DartifactId=hadoop-common-test 
-Dversion=0.23.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file[ERROR] [ERROR] 
Alternatively, if you host your own repository you can deploy the file 
there:[ERROR] mvn deploy:deploy-file -DgroupId=org.apache.hadoop 
-DartifactId=hadoop-common-test -Dversion=0.23.0-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id][ERROR] [ERROR] Path to 
dependency:[ERROR] 1) org.apache.knox:gateway-test-release:pom:0.10.0[ERROR] 2) 
org.apache.hadoop:hadoop-common-test:jar:0.23.0-SNAPSHOT[ERROR] [ERROR] 
--[ERROR] 1 required artifact is missing.

{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KNOX-779) Exclude older org.codehaus.jackson dependencies from build cycle

[Larry McCay (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654260#comment-15654260
 ] 

Larry McCay commented on KNOX-779:
--

[~coheigea] - I've just pushed this to master.
Thanks for the clean up!

> Exclude older org.codehaus.jackson dependencies from build cycle
> 
>
> Key: KNOX-779
> URL: https://issues.apache.org/jira/browse/KNOX-779
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 0.11.0
>
> Attachments: 
> 0001-KNOX-779-Exclude-older-org.codehaus.jackson-dependen.patch
>
>
> Currently there is a mix of two different Jackson dependencies in the build 
> cycle, due to the older "org.codehaus.jackson" dependency coming from the 
> rest-assured test dependency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] KIP-4: KnoxShell Improvements Proposal for 0.11.0

[Sandeep More]

Thanks Larry !

I really like the idea of expanding KnoxShell, following are my initial
thoughts on KIP-4

1) It appears that the "Discussion thread" points to KIP-1 thread.
2) I like the idea of Programming Model/Definitions, like you mentioned
some use cases would be great to get jump started. Do you think they should
get their own sub KIP when the formalization process starts ?
3) KnoxShell Session/SSO - Headless scripts would be cool. Also, do you
think KnoxShell should retain some state data i.e. say command_1 returns a
json, then command_2 might use it as an argument to do something else. One
of the problem with this, other then storing state, would be
 transformations (might or might not be needed) , may be this can be
something of a future enhancement.

Best,
Sandeep






On Wed, Nov 9, 2016 at 3:49 PM, larry mccay  wrote:

> All -
>
> I've taken a stab at a first iteration of the KIP for KnoxShell
> improvements.
>
> https://cwiki.apache.org/confluence/display/KNOX/KIP-4+
> KnoxShell+Improvements
>
> We should try and discuss these ideas and come up with what exactly what
> needs to be in a programming model definition and SDK and whether they are
> compelling enough to pursue.
>
> I think that there are some exciting opportunities here when we consider
> the cloud deployments - as I've said.
>
> Let's figure out what we would like to light up in the 0.11.0 if anything!
>
> thanks,
>
> --larry
>

[jira] [Resolved] (KNOX-757) Add log4j properties for shiro related logs to the gateway log4j file

[Sumit Gupta (JIRA)]

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

Sumit Gupta resolved KNOX-757.
--
Resolution: Fixed

> Add log4j properties for shiro related logs to the gateway log4j file
> -
>
> Key: KNOX-757
> URL: https://issues.apache.org/jira/browse/KNOX-757
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Sumit Gupta
>Assignee: John McParland
> Attachments: KNOX-757.patch, KNOX-757_clean.patch
>
>
> Properties for controlling logging for shiro functionality should be made 
> easier to switch on/off in the gateway log4j file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KNOX-757) Add log4j properties for shiro related logs to the gateway log4j file

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654213#comment-15654213
 ] 

ASF subversion and git services commented on KNOX-757:
--

Commit 30298e1e467f9c88503321b6fc6d4525b2e2f41a in knox's branch 
refs/heads/master from [~sumit.gupta]
[ https://git-wip-us.apache.org/repos/asf?p=knox.git;h=30298e1 ]

KNOX-757 shiro related log4j properties (John McParland via Sumit Gupta)


> Add log4j properties for shiro related logs to the gateway log4j file
> -
>
> Key: KNOX-757
> URL: https://issues.apache.org/jira/browse/KNOX-757
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Sumit Gupta
> Attachments: KNOX-757.patch, KNOX-757_clean.patch
>
>
> Properties for controlling logging for shiro functionality should be made 
> easier to switch on/off in the gateway log4j file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KNOX-779) Exclude older org.codehaus.jackson dependencies from build cycle

[Colm O hEigeartaigh (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654206#comment-15654206
 ] 

Colm O hEigeartaigh commented on KNOX-779:
--

Hi [~lmccay],

Just general clean up! I was looking at the dependencies and noticed that 
multiple Jackson dependencies were being used (albeit at test scope) in the 
build cycle.

Colm.

> Exclude older org.codehaus.jackson dependencies from build cycle
> 
>
> Key: KNOX-779
> URL: https://issues.apache.org/jira/browse/KNOX-779
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 0.11.0
>
> Attachments: 
> 0001-KNOX-779-Exclude-older-org.codehaus.jackson-dependen.patch
>
>
> Currently there is a mix of two different Jackson dependencies in the build 
> cycle, due to the older "org.codehaus.jackson" dependency coming from the 
> rest-assured test dependency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KNOX-779) Exclude older org.codehaus.jackson dependencies from build cycle

[Larry McCay (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654177#comment-15654177
 ] 

Larry McCay commented on KNOX-779:
--

Hi [~coheigea] - thanks for this contribution!

Question: is this addressing some error or intermittent failure that you are 
seeing or just general clean up?
I will take a look and test it quickly.

Thanks again!

> Exclude older org.codehaus.jackson dependencies from build cycle
> 
>
> Key: KNOX-779
> URL: https://issues.apache.org/jira/browse/KNOX-779
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 0.11.0
>
> Attachments: 
> 0001-KNOX-779-Exclude-older-org.codehaus.jackson-dependen.patch
>
>
> Currently there is a mix of two different Jackson dependencies in the build 
> cycle, due to the older "org.codehaus.jackson" dependency coming from the 
> rest-assured test dependency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KNOX-779) Exclude older org.codehaus.jackson dependencies from build cycle

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh updated KNOX-779:
-
Attachment: 0001-KNOX-779-Exclude-older-org.codehaus.jackson-dependen.patch

> Exclude older org.codehaus.jackson dependencies from build cycle
> 
>
> Key: KNOX-779
> URL: https://issues.apache.org/jira/browse/KNOX-779
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 0.11.0
>
> Attachments: 
> 0001-KNOX-779-Exclude-older-org.codehaus.jackson-dependen.patch
>
>
> Currently there is a mix of two different Jackson dependencies in the build 
> cycle, due to the older "org.codehaus.jackson" dependency coming from the 
> rest-assured test dependency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KNOX-779) Exclude older org.codehaus.jackson dependencies from build cycle

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh updated KNOX-779:
-
Assignee: Colm O hEigeartaigh
  Status: Patch Available  (was: Open)

This patch contains two changes:

a) Remove jackson-core dependency from the poms - this is not required, as it's 
picked up via jackson-databind anyway.
b) Exclude org.codehaus.jackson dependencies from rest-assured.

> Exclude older org.codehaus.jackson dependencies from build cycle
> 
>
> Key: KNOX-779
> URL: https://issues.apache.org/jira/browse/KNOX-779
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 0.11.0
>
> Attachments: 
> 0001-KNOX-779-Exclude-older-org.codehaus.jackson-dependen.patch
>
>
> Currently there is a mix of two different Jackson dependencies in the build 
> cycle, due to the older "org.codehaus.jackson" dependency coming from the 
> rest-assured test dependency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (KNOX-779) Exclude older org.codehaus.jackson dependencies from build cycle

[Colm O hEigeartaigh (JIRA)]

Colm O hEigeartaigh created KNOX-779:


 Summary: Exclude older org.codehaus.jackson dependencies from 
build cycle
 Key: KNOX-779
 URL: https://issues.apache.org/jira/browse/KNOX-779
 Project: Apache Knox
  Issue Type: Improvement
Reporter: Colm O hEigeartaigh
Priority: Trivial
 Fix For: 0.11.0


Currently there is a mix of two different Jackson dependencies in the build 
cycle, due to the older "org.codehaus.jackson" dependency coming from the 
rest-assured test dependency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build is back to normal : Knox-master-patch-scan #25870

[Apache Jenkins Server]

See 

Build failed in Jenkins: Knox-master-patch-scan #25869

[Apache Jenkins Server]

See 

--
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H1 (Hadoop) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/knox.git # timeout=10
Fetching upstream changes from https://github.com/apache/knox.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/apache/knox.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision c7c58cddab5e7818d6f2a390cb354a9c16aaf8da 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f c7c58cddab5e7818d6f2a390cb354a9c16aaf8da
 > git rev-list c7c58cddab5e7818d6f2a390cb354a9c16aaf8da # timeout=10
[Knox-master-patch-scan] $ /bin/bash /tmp/hudson9200288159716254838.sh
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
100  113k0  113k0 0   136k  0 --:--:-- --:--:-- --:--:--  136k
curl: (18) transfer closed with outstanding read data remaining
Could not retrieve available patches from JIRA
Build step 'Execute shell' marked build as failure