hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: adding constraints
Date Tue, 18 Oct 2011 22:31:53 GMT
> > Yeah, we can do security, but you have to include
> > the jars make sure it works, etc. As opposed to _certain_ systems where
> > security is built in. Similar arguments can be made for things like
> > constraints - its just _easier_ to have it built in, and let people use them
> > (or not) as they choose.

> [...] But the current approach for security was
> arrived at as a result of extensive discussions with the entire
> community about the right approach, where many concerns were raised
> about paying any overhead for security when it was not being used.  As
> a result, all security components were built in a loadable fashion,
> with the trade-off of some extra configuration complexity

This discussion more than casually reminds me of past discussions regarding moving from a
statically linked kernel to one that supports dynamically loaded modules seen on both the
Linux and FreeBSD mailing lists.

Again we have a tightly coupled code base making a transition to dynamic runtime composition.

IMO, anyone concerned that HBase doesn't have security or constraints built in can ship a
default configuration that has either or both loaded as system coprocessors. Those that don't
want the "bloat" can simply not load them. This balances the demands we will see over a contiuum
here, from those that want the most functionality "out of the box", to those that want maximum
performance or minimal runtime complexity or both.

If there is sufficient concern about user-friendliness, those so concerned could build the
plumbing to automatically load coprocessors a la modprobe. Perhaps by reading hbase-site.xml
and matching config vars to CP jars (via reflection and some kind of decorator convention?).

I also see HBASE-4554 as about improving how CPs get configuration, if needed, and how the
user can change it.

It looks like everyone is in favor of, or at least does not object to, some sort of constraint
checking and enforcement implemented as a coprocessor, independent of the core code.

Personally, I have the same attitude about this as I did security -- it's great to have, and
even better if it can be dynamically loaded only as needed so those that do not want it suffer
no overheads or performance degradation.

   - Andy





>________________________________
>From: Gary Helmling <ghelmling@gmail.com>
>To: dev@hbase.apache.org
>Sent: Tuesday, October 18, 2011 12:43 AM
>Subject: Re: adding constraints
>
>>
>> There is an example of how to do Constraints as a jar with CPs already
>> attached to the ticket, and its pretty simple. However, the ticket goes into
>> the plusses and minuses for a top-level or just basic CP based
>> implementation.
>>
>> For me, the best reason for top level is top make HBase easy to use and have
>> certain built-in features.
>
>Hmm, I wasn't really reading the two implementation options for
>constraints as a choice between a "built-in" feature and CP based.
>I'm reading it as a choice between:
>1) a bundled CP implementation (which you still have to _enable_) that
>does constraint checking loading user classes that implement a simple
>interface (Constraint or Predicate<Put> or whatever)
>2) an abstract CP example class that you have to extend with your own
>implementation logic, which, if you want to do it right, you'll still
>wind up with something resembling #1 anyway
>
>FYI, I see option #1 as fairly analogous to the bundled aggregation
>client that Lars mentioned.
>
>If you want this as real top-level functionality built directly in to,
>say, the HRegion code paths for puts, the question is why should we
>add the complexity directly when we have CPs?
>
>> Yeah, we can do security, but you have to include
>> the jars make sure it works, etc. As opposed to _certain_ systems where
>> security is built in. Similar arguments can be made for things like
>> constraints - its just _easier_ to have it built in, and let people use them
>> (or not) as they choose.
>>
>
>We have a security implementation up for review that provides
>meaningful security.  Yes, it has to be enabled to be used and the
>process of configuring it could be much simpler.  Security is always a
>matter of trade-offs.  You can argue about about whether or not we've
>made the right ones.  But the current approach for security was
>arrived at as a result of extensive discussions with the entire
>community about the right approach, where many concerns were raised
>about paying any overhead for security when it was not being used.  As
>a result, all security components were built in a loadable fashion,
>with the trade-off of some extra configuration complexity.
>
>Yes, Accumulo has "security" always enabled.  But this is still not an
>apples-to-apples comparison.  HBase security relies on Kerberos to
>provide a trusted third part for strong authentication while never
>sending the password over the wire.  Accumulo sends username and
>password in plain text on the rpc connections.  As a result HBase
>relies on external systems for managing credentials, while Accumulo
>embeds its own user database, with the usernames and hashed passwords
>stored as globally readable znodes in zookeeper.  You could say that
>reliance on an external system makes the HBase setup more complex, but
>that's a narrow view.  While managing an internal user database does
>keep things self contained, it also forces you to create usernames and
>passwords for an application in multiple places (your application does
>run under its own account, right?), adding it's own complexity.
>Accumulo allows access control labels to be placed on each key value
>individually, while HBase uses a simpler model for assignments limited
>to table, column family, or column qualifier scope.
>
>Each system makes it's own trade-offs based on its implementation
>goals.  What's right for you is going to depend on your needs.  But
>the HBase approach did not just disregard simplicity willy-nilly.
>
>> The ticket also talks about abstracting out some of the CP things to make it
>> easier to add other top level features, which would be a win too. Yeah, they
>> would be backed by CPs, but that doesn't mean it doesn't make sense for
>> people to use the stuff really (as in dead simple) easily.
>>
>
>Again, I don't really see the other changes discussed (HBASE-4554?) as
>top-level vs. CP-based.  I think that change is just about providing
>the shell with the ability to easily set arbitrary attributes on
>HTableDescriptor.  Those already exist, they're just not properly
>exposed in the shell.  Maybe you're envisioning something beyond this
>for the constraints case?  That may be good too, but we should
>probably move the discussion over to the JIRA.
>
>It may not sound like it, but I'm all in favor of making things as
>simple as possible.  It's just that, when simplifying, you're usually
>moving complexity from one place to another.  So let's work out where
>we can get the biggest benefit.
>
>--gh
>
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message