hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: 0.94 non-secure tarballs
Date Thu, 27 Mar 2014 17:14:44 GMT
Good by me.  Was done for historical reasons and because the fellas adding
security were gracious, being careful, ensuring security did not impinge on
non-secure deploys.  We are in a different place now: i.e. underlying
hadoop versions now support it and security is no longer a rare
consideration.

St.Ack


On Thu, Mar 27, 2014 at 10:04 AM, Gary Helmling <ghelmling@gmail.com> wrote:

> +1, seems fine to eliminate the non-secure builds now.
>
> The main reason for doing security as a separate profile was to make it
> possible to continue to build and run HBase on a pre-1.0 Hadoop (Hadoop
> without the security classes referenced in the HBase security code).  We
> don't even have a profile for a non-secure Hadoop anymore, so I can't see
> this being an issue any longer.
>
>
> On Wed, Mar 26, 2014 at 9:39 PM, Jesse Yates <jesse.k.yates@gmail.com
> >wrote:
>
> > +1
> >
> > Might need a good set of documentation the first couple times, but seems
> > reasonable.
> > On Mar 26, 2014 9:04 PM, "lars hofhansl" <larsh@apache.org> wrote:
> >
> > > I am thinking to stop releasing the tarballs without the security code.
> > > They do not really add anything, the secure tarballs work perfectly OK
> > > without security. The secure builds just have some source and class
> > files.
> > >
> > > I would also get rid of the non-secure build completely and just have
> one
> > > way to build HBase.
> > >
> > > Any objections? Are there any other reasons to build both a secure and
> > > non-secure tarball? Export restrictions, or anything?
> > >
> > > I think that would also make it trivial to release the secure bits to
> > > maven (but maven is black magic to me, so I do not know for sure).
> > >
> > > -- Lars
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message