Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Hadoop >> mail # dev >> [DISCUSS] Hadoop SSO/Token Server Components


+
Larry McCay 2013-07-02, 20:03
+
Zheng, Kai 2013-07-03, 18:39
+
Larry McCay 2013-07-03, 20:10
+
Andrew Purtell 2013-07-03, 23:35
+
Larry McCay 2013-07-03, 23:49
+
Andrew Purtell 2013-07-04, 18:40
+
Alejandro Abdelnur 2013-07-04, 20:09
+
Zheng, Kai 2013-07-05, 17:34
+
Larry McCay 2013-07-05, 18:25
+
Larry McCay 2013-07-05, 19:24
Copy link to this message
-
Re: [DISCUSS] Hadoop SSO/Token Server Components
All -

After combing through this thread - as well as the summit session summary thread, I think that we have the following two items that we can probably move forward with:

1. TokenAuth method - assuming this means the pluggable authentication mechanisms within the RPC layer (2 votes: Kai and Kyle)
2. An actual Hadoop Token format (2 votes: Brian and myself)

I propose that we attack both of these aspects as one. Let's provide the structure and interfaces of the pluggable framework for use in the RPC layer through leveraging Daryn's pluggability work and POC it with a particular token format (not necessarily the only format ever supported - we just need one to start). If there has already been work done in this area by anyone then please speak up and commit to providing a patch - so that we don't duplicate effort.

@Daryn - is there a particular Jira or set of Jiras that we can look at to discern the pluggability mechanism details? Documentation of it would be great as well.
@Kai - do you have existing code for the pluggable token authentication mechanism - if not, we can take a stab at representing it with interfaces and/or POC code.
I can standup and say that we have a token format that we have been working with already and can provide a patch that represents it as a contribution to test out the pluggable tokenAuth.

These patches will provide progress toward code being the central discussion vehicle. As a community, we can then incrementally build on that foundation in order to collaboratively deliver the common vision.

In the absence of any other home for posting such patches, let's assume that they will be attached to HADOOP-9392 - or a dedicated subtask for this particular aspect/s - I will leave that detail to Kai.

@Alejandro, being the only voice on this thread that isn't represented in the votes above, please feel free to agree or disagree with this direction.

thanks,

--larry

On Jul 5, 2013, at 3:24 PM, Larry McCay <[EMAIL PROTECTED]> wrote:

> Hi Andy -
>
>> Happy Fourth of July to you and yours.
>
> Same to you and yours. :-)
> We had some fun in the sun for a change - we've had nothing but rain on the east coast lately.
>
>> My concern here is there may have been a misinterpretation or lack of
>> consensus on what is meant by "clean slate"
>
>
> Apparently so.
> On the pre-summit call, I stated that I was interested in reconciling the jiras so that we had one to work from.
>
> You recommended that we set them aside for the time being - with the understanding that work would continue on your side (and our's as well) - and approach the community discussion from a clean slate.
> We seemed to do this at the summit session quite well.
> It was my understanding that this community discussion would live beyond the summit and continue on this list.
>
> While closing the summit session we agreed to follow up on common-dev with first a summary then a discussion of the moving parts.
>
> I never expected the previous work to be abandoned and fully expected it to inform the discussion that happened here.
>
> If you would like to reframe what clean slate was supposed to mean or describe what it means now - that would be welcome - before I waste anymore time trying to facilitate a community discussion that is apparently not wanted.
>
>> Nowhere in this
>> picture are self appointed "master JIRAs" and such, which have been
>> disappointing to see crop up, we should be collaboratively coding not
>> planting flags.
>
> I don't know what you mean by self-appointed master JIRAs.
> It has certainly not been anyone's intention to disappoint.
> Any mention of a new JIRA was just to have a clear context to gather the agreed upon points - previous and/or existing JIRAs would easily be linked.
>
> Planting flags… I need to go back and read my discussion point about the JIRA and see how this is the impression that was made.
> That is not how I define success. The only flags that count is code. What we are lacking is the roadmap on which to put the code.
+
Daryn Sharp 2013-07-10, 16:30
+
Alejandro Abdelnur 2013-07-10, 15:14
+
Brian Swan 2013-07-10, 17:06
+
Larry McCay 2013-07-10, 17:39
+
Brian Swan 2013-07-10, 17:59
+
Larry McCay 2013-07-27, 00:59
+
Larry McCay 2013-07-30, 16:43
+
Alejandro Abdelnur 2013-08-06, 20:04
+
Chris Nauroth 2013-08-06, 20:12
+
Alejandro Abdelnur 2013-08-06, 20:15
+
Larry McCay 2013-08-06, 21:48
+
Chris Nauroth 2013-08-06, 22:22
+
Larry McCay 2013-09-03, 12:20
+
Chris Douglas 2013-09-03, 22:44
+
Larry McCay 2013-09-03, 22:55
+
Zheng, Kai 2013-09-04, 02:00
+
Larry McCay 2013-09-04, 18:19
+
Chris Douglas 2013-09-04, 19:39
+
Suresh Srinivas 2013-09-05, 06:41
+
Zheng, Kai 2013-09-05, 07:29
+
Li, Tianyou 2013-07-04, 04:19
+
Larry McCay 2013-07-04, 10:52
+
Zheng, Kai 2013-07-04, 11:21
+
Larry McCay 2013-07-04, 16:18
+
Brian Swan 2013-07-03, 18:32
+
Larry McCay 2013-07-03, 20:13
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB