hadoop-hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Capriolo (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HIVE-30) Hive web interface
Date Wed, 19 Nov 2008 22:49:44 GMT

    [ https://issues.apache.org/jira/browse/HIVE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649198#action_12649198
] 

Edward Capriolo commented on HIVE-30:
-------------------------------------

I understand the concern about having multiple session servers. However, I believe the state
belongs to the client. I might want to make a swing application that uses three SessionStates,
etc. A generic SessionState server is just an extra abstraction at this phase. You never know
how the client will want to use the SessionState.  

>>we should also have one server side to manage common abstractions like userids and
such
...True. The 'userid' and 'password' in hwi is just a nice way of naming the session. Imagine
a web server managing thousands of jobs, the SHOW_SERVER_STATUS page would be thousands of
meaningless session ids. I decided to attach a human readable name to the hive sessions. A
simple password mechanism just protects Bob from from editing Sara's session. It was a throw
in feature. If you set the password to empty string it has no effect. My goal for was not
to create a wide reaching security implication for hive/hadoop but to simply give the user
the ability to name and optionally protect their session since anyone who goes to the web
server can get at the session. --Lets talk more about passing that information from a web
interface--

>>we seem to be initializing HiveConf for each show table/database
True. I am using the thrift API for the meta operations. Using the web interface it is possible
to view the schema without starting a session state. Those two parts of the application are
different. The schema browsing is more or less stateless, that is why the HiveConf is reloaded
per request.
>>how are the logs going to be managed?--Right now there is no logging. JSP Session
ID might make sense over Hive Session ID 

>>Regarding the userid and authentication stuff, I think the best there is to use pam
based scheme to tie this in with an existing LDAP repository or unix accounts. But that can
perhaps be done as a follow up transaction?
Again, my goal was to name the sessions and give a simple password mechanism. I know there
is a hadoop jira open for kerberos.  I work a lot with LDAP, in the end you can force the
hadoop property from inside java, right? Also my LDAP server uses public key authentication,
I actually do not have a password in the entire server. So LDAP brings other complications.


> Hive web interface
> ------------------
>
>                 Key: HIVE-30
>                 URL: https://issues.apache.org/jira/browse/HIVE-30
>             Project: Hadoop Hive
>          Issue Type: Bug
>            Reporter: Jeff Hammerbacher
>            Assignee: Edward Capriolo
>            Priority: Minor
>         Attachments: HIVE-30.patch
>
>
> Hive needs a web interface. The initial checkin should have:
> * simple schema browsing
> * query submission
> * query history (similar to MySQL's SHOW PROCESSLIST)
> A suggested feature: the ability to have a query notify the user when it's completed.
> Edward Capriolo has expressed some interest in driving this process.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message