[
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.
