[GitHub] incubator-hawq-docs pull request #98: HAWQ-1296 - initial draft of hawq gett...

[lisakowen]

GitHub user lisakowen opened a pull request:

https://github.com/apache/incubator-hawq-docs/pull/98

HAWQ-1296 - initial draft of hawq getting started guide

initial revision of the "Getting Started with HAWQ" tutorial.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/lisakowen/incubator-hawq-docs 
feature/getting-started2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-hawq-docs/pull/98.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #98


commit fb21d13cd8970bf7ab816c1e51ef6ec0702cd035
Author: Lisa Owen 
Date:   2017-01-25T15:28:00Z

initial check-in of hawq getting started guide




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (HAWQ-1376) docs - better describe the pxf host and port settings

[Lisa Owen (JIRA)]

Lisa Owen created HAWQ-1376:
---

 Summary: docs - better describe the pxf host and port settings
 Key: HAWQ-1376
 URL: https://issues.apache.org/jira/browse/HAWQ-1376
 Project: Apache HAWQ
  Issue Type: Bug
  Components: Documentation
Reporter: Lisa Owen
Assignee: David Yozie


the pxf host and port settings as described some places in the docs as hdfs 
namenode and port.  this is confusing - the host does not have to be the 
namenode and the port should be the pxf port.

clarify the docs in this area.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: New Committer: Kyle Dunn

[Jon Roberts]

Congrats Kyle!!


Jon Roberts

On Fri, Mar 3, 2017 at 9:15 AM, Jim Campbell  wrote:

> Congratulations Kyle!
>
> James Campbell
> Data Engineer
> Pivotal Software
> P:  571-247-6511
> E:  jacampb...@pivotal.io
>
>
>
> On March 2, 2017 at 7:44:31 PM, Lei Chang (lei_ch...@apache.org) wrote:
>
> Congratulations! Kyle.
>
> Cheers
> Lei
>
>
>
> On Fri, Mar 3, 2017 at 8:30 AM, Kyle Dunn  wrote:
>
> > Thanks team! Honored to be invited to join this great community!
> >
> >
> > -Kyle
> >
> > On Thu, Mar 2, 2017 at 10:07 AM Roman Shaposhnik 
> > wrote:
> >
> > > Congrats Kyle! Great to have you onboard!
> > >
> > > Thanks,
> > > Roman.
> > >
> > > On Thu, Mar 2, 2017 at 9:05 AM, Ed Espino  wrote:
> > > > The Project Management Committee (PMC) for Apache HAWQ (incubating)
> has
> > > > invited Kyle Dunn to become a committer and we are pleased to
> announce
> > > that
> > > > he has accepted.
> > > >
> > > > His contributions include (but not limited to):
> > > >
> > > > - Issues submitted: He has reported a total of 10 HAWQ issues
> > > > <
> > > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20%22Apache%20HAWQ%22%20and%20reporter%20%3D%20kdunn926
> > > >
> > > > across
> > > > significant areas of the HAWQ product
> > > > - He is active on the dev list.
> > > > - He has recently requested and was granted update privileges to the
> > > > HAWQ wiki. He has updated the RHEL 6.X build instructions.
> > > > - He has submitted 5 HAWQ PRs
> > > > <
> > > https://github.com/apache/incubator-hawq/pulls?utf8=%E2%
> > 9C%93=is%3Apr%20author%3Akdunn926%20
> > > >
> > > > covering
> > > > new feature areas. Not all were accepted but it shows he is
> > committed
> > > to
> > > > enhancing HAWQ feature set.
> > > >
> > > > Being a committer enables easier contribution to the project. This
> > should
> > > > enable improved productivity.
> > > >
> > > > Please join us in congratulating him. We are looking forward to a
> > closer
> > > > collaboration with the open source community.
> > > >
> > > > *WELCOME and CONGRATULATIONS Kyle!!!*
> > > >
> > > > Cheers,
> > > > -=e
> > > >
> > > > --
> > > > *Ed Espino*
> > >
> > --
> > *Kyle Dunn | Data Engineering | Pivotal*
> > Direct: 303.905.3171 <3039053171> | Email: kd...@pivotal.io
> >
>

Re: hawq Ambari integration

[Jon Roberts]

Thanks everyone for the clarification.

Just a bit off topic question to end this thread.  When a cluster is
configured with Ranger and a GRANT/REVOKE is executed, will this RAISE an
ERROR, WARN, INFO, other, or none?

Jon Roberts

On Thu, Mar 2, 2017 at 9:04 PM, Vineet Goel  wrote:

> Ranger community advises against sync between Ranger policies and native
> authorization metastores. It complicates design and users haven't shown a
> real need to switch between auth models back and forth.
>
> -Vineet
>
>
> On Thu, Mar 2, 2017 at 6:33 PM Alexander Denissov 
> wrote:
>
> > Not quite.
> >
> > For the first phase, there will be no integration between GRANT/REVOKE
> and
> > Ranger policies -- once Ranger is turned on, GRANT/REVOKE from psql will
> no
> > longer work.
> >
> > In a later stage, we will likely provide integration HAWQ --> Ranger,
> such
> > that when GRANT/REVOKE is issued from psql, an appropriate policy is
> > created / deleted from Ranger.
> >
> > I don't think Ranger --> HAWQ integration is planned or is even possible,
> > as admin action in Ranger UI would need to be somehow detected and
> > translated to HAWQ grants which are not going to be used anyways as
> > authorization will be performed in Ranger only.
> >
> > --
> > Thanks,
> > Alex
> >
> > On Thu, Mar 2, 2017 at 6:20 PM, Jon Roberts  wrote:
> >
> > > Have I misunderstood the Ranger integration work?  When a GRANT/REVOKE
> is
> > > executed in HAWQ it will be replicated to Ranger and when a
> GRANT/REVOKE
> > is
> > > executed in Ranger, it will be replicated to HAWQ.  Right?  If yes,
> then
> > > this is the model that I'm suggesting for Ambari.
> > >
> > > Jon Roberts
> > > Principal Engineer | jrobe...@pivotal.io | 615-426-8661
> > <(615)%20426-8661>
> > >
> > > On Thu, Mar 2, 2017 at 7:27 PM, Vineet Goel 
> wrote:
> > >
> > > > Having worked with Ambari and knowing the complexities of this
> desired
> > > > integration, I agree with Alex on his comments below. Users need some
> > > time
> > > > to get used to exclusive HAWQ CLI or Ambari usage model, and avoid
> mix
> > > and
> > > > match despite the fact that HAWQ CLI and Ambari have their
> > > > advantages/disadvantages.
> > > >
> > > > -Vineet
> > > >
> > > >
> > > > On Thu, Mar 2, 2017 at 5:17 PM Alexander Denissov <
> > adenis...@pivotal.io>
> > > > wrote:
> > > >
> > > > > Ambari is designed as a tool to sit on top of individual service
> CLI
> > > > tools
> > > > > and provide consistent user experience. Ambari can also have
> wizards
> > > and
> > > > > custom actions that go beyond service lifecycle management. It is
> > > assumed
> > > > > by Ambari design that once Ambari is used to manage configurations,
> > CLI
> > > > > tools should not be used, otherwise changes will be out-of-sync or
> > will
> > > > be
> > > > > overwritten by Ambari upon service restart.
> > > > >
> > > > > Having HAWQ CLI tools communicate back to Ambari is not desirable
> > > > because:
> > > > > - knowledge of Ambari REST APIs needs to be built into the tools
> > > > > - Ambari APIs change outside of service release lifecycle
> > > > > - complexity in error handling (what do you do if Ambari call
> failed
> > ?)
> > > > > - introduction of feedback loop and potential infinite cycle
> (Ambari
> > > > calls
> > > > > the tool, the tool calls Ambari back, etc)
> > > > >
> > > > > If customers want to do some extra automation they can decide how
> to
> > > tie
> > > > > tools and Ambari, if they like, but I will say we should not have
> > HAWQ
> > > > CLI
> > > > > tools call Ambari.
> > > > >
> > > > > --
> > > > > Thanks,
> > > > > Alex Denissov
> > > > >
> > > > > On Thu, Mar 2, 2017 at 4:44 PM, Alex (Oleksandr) Diachenko <
> > > > > odiache...@pivotal.io> wrote:
> > > > >
> > > > > > Sure,
> > > > > >
> > > > > > Users can automate configuration changes via Ambari API, which
> > > provides
> > > > > > unified access
> > > > > > to all services in a cluster. It's very likely they need to
> > configure
> > > > > HAWQ,
> > > > > > HDFS and YARN
> > > > > > when working with configuration changes, so with Ambari API it
> > would
> > > be
> > > > > > easier to call one API
> > > > > > rather than using all different CLI's.
> > > > > >
> > > > > > Regards, Alex.
> > > > > >
> > > > > > On Thu, Mar 2, 2017 at 4:39 PM, Lei Chang 
> > > > wrote:
> > > > > >
> > > > > > > I think there are some use cases we need What Jon proposed.
> > > > > > >
> > > > > > > For example, users installed hawq via Ambari, but they want to
> > > > automate
> > > > > > the
> > > > > > > configuration changes, it would be convenient to have hawq CLI
> > > change
> > > > > the
> > > > > > > configurations.
> > > > > > >
> > > > > > > Cheers
> > > > > > > Lei
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Mar 3, 2017 at 8:36 AM, Alex (Oleksandr) 

[jira] [Created] (HAWQ-1375) Ranger should always using the current user to do privilege check.

[Hubert Zhang (JIRA)]

Hubert Zhang created HAWQ-1375:
--

 Summary: Ranger should always using the current user to do 
privilege check.
 Key: HAWQ-1375
 URL: https://issues.apache.org/jira/browse/HAWQ-1375
 Project: Apache HAWQ
  Issue Type: Bug
Reporter: Hubert Zhang
Assignee: Ed Espino


Failure Case:
{code}
user u1 create table a(i int);
user u2 create view av as select * from a;
user u3 select * from av.
{code}
When ORCA is on, u3 will first ask select privilege as user u3 to Ranger, and 
then ask select privilege as user u2 to Ranger.
The second check should be removed, since there may be no privilege for u2 to 
select av even if av is created by u2 in Ranger mode.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)