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
Copy link to this message
-
Re: [DISCUSS] Hadoop SSO/Token Server Components
Hi Larry (and all),

Happy Fourth of July to you and yours.

In our shop Kai and Tianyou are already doing the coding, so I'd defer to
them on the detailed points.

My concern here is there may have been a misinterpretation or lack of
consensus on what is meant by "clean slate". Hopefully that can be quickly
cleared up. Certainly we did not mean ignore all that came before. The idea
was to reset discussions to find common ground and new direction where we
are working together, not in conflict, on an agreed upon set of design
points and tasks. There's been a lot of good discussion and design
preceeding that we should figure out how to port over. 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 read Kai's latest document as something approaching today's consensus (or
at least a common point of view?) rather than a historical document.
Perhaps he and it can be given equal share of the consideration.
On Wednesday, July 3, 2013, Larry McCay wrote:

> Hey Andrew -
>
> I largely agree with that statement.
> My intention was to let the differences be worked out within the
> individual components once they were identified and subtasks created.
>
> My reference to HSSO was really referring to a SSO *server* based design
> which was not clearly articulated in the earlier documents.
> We aren't trying to compare and contrast one design over another anymore.
>
> Let's move this collaboration along as we've mapped out and the
> differences in the details will reveal themselves and be addressed within
> their components.
>
> I've actually been looking forward to you weighing in on the actual
> discussion points in this thread.
> Could you do that?
>
> At this point, I am most interested in your thoughts on a single jira to
> represent all of this work and whether we should start discussing the SSO
> Tokens.
> If you think there are discussion points missing from that list, feel free
> to add to it.
>
> thanks,
>
> --larry
>
> On Jul 3, 2013, at 7:35 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
>
> > Hi Larry,
> >
> > Of course I'll let Kai speak for himself. However, let me point out that,
> > while the differences between the competing JIRAs have been reduced for
> > sure, there were some key differences that didn't just disappear.
> > Subsequent discussion will make that clear. I also disagree with your
> > characterization that we have simply endorsed all of the design decisions
> > of the so-called HSSO, this is taking a mile from an inch. We are here to
> > engage in a collaborative process as peers. I've been encouraged by the
> > spirit of the discussions up to this point and hope that can continue
> > beyond one design summit.
> >
> >
> >
> > On Wed, Jul 3, 2013 at 1:10 PM, Larry McCay <[EMAIL PROTECTED]>
> wrote:
> >
> >> Hi Kai -
> >>
> >> I think that I need to clarify something…
> >>
> >> This is not an update for 9533 but a continuation of the discussions
> that
> >> are focused on a fresh look at a SSO for Hadoop.
> >> We've agreed to leave our previous designs behind and therefore we
> aren't
> >> really seeing it as an HSSO layered on top of TAS approach or an HSSO vs
> >> TAS discussion.
> >>
> >> Your latest design revision actually makes it clear that you are now
> >> targeting exactly what was described as HSSO - so comparing and
> contrasting
> >> is not going to add any value.
> >>
> >> What we need you to do at this point, is to look at those high-level
> >> components described on this thread and comment on whether we need
> >> additional components or any that are listed that don't seem necessary
> to
> >> you and why.
> >> In other words, we need to define and agree on the work that has to be
> >> done.
> >>
> >> We also need to determine those components that need to be done before
> >> anything else can be started.
> >> I happen to agree with Brian that #4 Hadoop SSO Tokens are central to

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
+
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
+
Larry McCay 2013-07-10, 13:42
+
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