Re: [DISCUSS] Separating out the metastore as its own TLP

On 7/25/17, 4:45 PM, "cwsteinb...@gmail.com on behalf of Carl Steinbach" wrote: >"IceWeasel" and "MetaStore" are both examples of English compound words. >What exactly makes the former any safer than the latter? Usually descriptive

Re: [DISCUSS] Separating out the metastore as its own TLP

Johndee (and everyone else), wiki edit privileges are easy to get: About This Wiki -- How to get permission to edit . -- Lefty On Thu, Jul 27, 2017 at 2:32 PM, Johndee Cloudera

Re: [DISCUSS] Separating out the metastore as its own TLP

Well if I cannot get Metastore, how about Hadoop Metastore it is simple and self explanatory to a degree. @Alan, Sorry to make the name suggestion here but I could not comment or edit the page you created. On Mon, Jul 24, 2017 at 7:17 PM, Gopal Vijayaraghavan wrote: > Hi, >

Re: [DISCUSS] Separating out the metastore as its own TLP

I think the concerns with Metastore are twofold. One, it’s a common term in software, and thus would be hard to defend as a trademark. Hence Gopal’s link to the Debian package already named metastore. IANAL but as I understand trademark law the test is whether a name could cause a reasonable

Re: [DISCUSS] Separating out the metastore as its own TLP

"IceWeasel" and "MetaStore" are both examples of English compound words. What exactly makes the former any safer than the latter? On Mon, Jul 24, 2017 at 4:17 PM, Gopal Vijayaraghavan wrote: > Hi, > > > Changing the name isn't really optional or "being google-able" [2]. > >

Re: [DISCUSS] Separating out the metastore as its own TLP

I’ve collected the naming suggestions on the wiki at https://cwiki.apache.org/confluence/display/Hive/Metastore+TLP+Proposal Please feel free to add additional ones there. Alan. On Mon, Jul 24, 2017 at 4:17 PM, Gopal Vijayaraghavan wrote: > Hi, > > > Changing the name isn't

Re: [DISCUSS] Separating out the metastore as its own TLP

Hi, Changing the name isn't really optional or "being google-able" [2]. The naming is a crucial part of trademark protection [1], which is the only protection ASF has against hostile Embrace & Extends. Fragmented forks with the same name is particularly bad, especially if the feature in

Re: [DISCUSS] Separating out the metastore as its own TLP

+1 to Vihang's suggestion. Changing the name will only cause confusion. On Mon, Jul 24, 2017 at 2:28 PM, Johndee Cloudera wrote: > +1 Vihang, I do not really like Catalog as it could create confusion with > the Catalog daemon from impala. > > On Mon, Jul 24, 2017 at 5:20

Re: [DISCUSS] Separating out the metastore as its own TLP

+1 Vihang, I do not really like Catalog as it could create confusion with the Catalog daemon from impala. On Mon, Jul 24, 2017 at 5:20 PM, Vihang Karajgaonkar wrote: > Before we see a flood of name suggestions :) Why not just keep it > Metastore? Its already well-known in

Re: [DISCUSS] Separating out the metastore as its own TLP

Before we see a flood of name suggestions :) Why not just keep it Metastore? Its already well-known in the community and easy to relate to. On Mon, Jul 24, 2017 at 2:13 PM, Alan Gates wrote: > In the same vein Carter and Gunther suggested Omegastore. Pick your > alphabet

Re: [DISCUSS] Separating out the metastore as its own TLP

In the same vein Carter and Gunther suggested Omegastore. Pick your alphabet and whether it’s a catalog or a store I guess. Alan. On Mon, Jul 24, 2017 at 1:35 PM, Sergey Shelukhin wrote: > I’d like to suggest ZCatalog. > > On 17/7/11, 15:41, "Lefty Leverenz"

Re: [DISCUSS] Separating out the metastore as its own TLP

I’d like to suggest ZCatalog. On 17/7/11, 15:41, "Lefty Leverenz" wrote: >>> I'd like to suggest Riven. (Owen O'Malley) > >> How about "Flora"? (Andrew Sherman) > >Nice idea and thanks for introducing me to that book, Andrew. > >Along the same lines, how about

Re: [DISCUSS] Separating out the metastore as its own TLP

It seems we have settled into a consensus that this will be good for the ecosystem, but there are concerns that this will be a burden on Hive. The original proposal included a time to work on the separation inside the Hive project to help address any such issues. This would culminate in a source

Re: [DISCUSS] Separating out the metastore as its own TLP

>> I'd like to suggest Riven. (Owen O'Malley) > How about "Flora"? (Andrew Sherman) Nice idea and thanks for introducing me to that book, Andrew. Along the same lines, how about "Honeycomb"? But since the idea is to make the metastore useful for many projects, a generic name that starts with

Re: [DISCUSS] Separating out the metastore as its own TLP

On Fri, Jun 30, 2017 at 5:05 PM, Owen O'Malley wrote: > On Fri, Jun 30, 2017 at 3:26 PM, Chao Sun wrote: > > > and maybe a different project name? > > > > Yes, it certainly needs a new name. I'd like to suggest Riven. > > .. Owen > How about "Flora"?

Re: [DISCUSS] Separating out the metastore as its own TLP

On Wed, Jul 5, 2017 at 12:33 PM, Edward Capriolo wrote: > > I hate to draw in something else but I feel it is related: > > 8 December 2016 : release 2.1.1 available > 07 April 2017 : release 1.2.2 available > hive-dev [DISCUSS] Supporting Hadoop-1 and experimental features

Re: [DISCUSS] Separating out the metastore as its own TLP

The proposal does build in a time delay by doing the separation first in the Hive project. This will take several months. We should not put an absolute bound on it (6 months or whatever). The reasoning behind doing the separation in Hive before moving the code out is to make sure it’s feasible

Re: [DISCUSS] Separating out the metastore as its own TLP

+1 to having an always releasable head of master. +1 to having test verified API compliance. I was thinking that the project should set up verification tests where it runs against supported versions of Hive, Imapala, Spark, … (and obviously open to others to add their tests as well) on a nightly

Re: [DISCUSS] Separating out the metastore as its own TLP

I can understand the concerns from Edward and Xuefu and I think they are valid as well. I think having a regular cadence of release will help alleviate the concerns related to features making into releases to a certain extent. Having quarterly or semi-annual releases would be a good thing in

Re: [DISCUSS] Separating out the metastore as its own TLP

Hi folks, I agree with most of the things Edward said. I have faced similar issues in smaller scale when integrated Hive with Yetus. We are forced to keep patched Yetus files in Hive repo until they push their next release. Also followed one more serious problem when a patch was committed to

Re: [DISCUSS] Separating out the metastore as its own TLP

I think Edward's concern is valid. While I voiced my support for this proposal, which was more from the benefits of the whole Hadoop ecosystem, I don't see the equal benefits for Hive. Instead, it may even create more overhead for Hive. I'd really like to take time to see what are the road blocks

Re: [DISCUSS] Separating out the metastore as its own TLP

On Wed, Jul 5, 2017 at 1:51 PM, Alan Gates wrote: > On Mon, Jul 3, 2017 at 6:20 AM, Edward Capriolo > wrote: > > > > > We already have things in the meta-store not directly tied to language > > features. For example hive metastore has a "retention"

Re: [DISCUSS] Separating out the metastore as its own TLP

On Mon, Jul 3, 2017 at 10:17 AM, Dain Sundstrom wrote: > +1 > > I work on Presto and I think this the right direction for our users. We > have several users running Presto without Hive and anything we can do to > help simplify the Metastore experience would be a good help. > >

Re: [DISCUSS] Separating out the metastore as its own TLP

On Mon, Jul 3, 2017 at 6:20 AM, Edward Capriolo wrote: > > We already have things in the meta-store not directly tied to language > features. For example hive metastore has a "retention" property which is > not actively in use by anything. In reality, we rarely say 'no' or

Re: [DISCUSS] Separating out the metastore as its own TLP

+1 I work on Presto and I think this the right direction for our users. We have several users running Presto without Hive and anything we can do to help simplify the Metastore experience would be a good help. When I read proposals like this, one thing I like to see is a vision (scope) for

Re: [DISCUSS] Separating out the metastore as its own TLP

This rings very true to me On 7/3/17, 6:20 AM, "Edward Capriolo" wrote: I am going to give a hypothetical but real world situation. Suppose I want to add the statement "CREATE permanent macro xyz", this feature I believe would cross cut calcite, hive, and hive

Re: [DISCUSS] Separating out the metastore as its own TLP

On Sun, Jul 2, 2017 at 10:15 PM, Alan Gates wrote: > Comments inlined. > > On Sun, Jul 2, 2017 at 3:22 PM, Edward Capriolo > wrote: > > > I am not sure I am on the fence with this. > > > > I am -1, and I offer this -1 with the hope of being convinced

Re: [DISCUSS] Separating out the metastore as its own TLP

I think it would be great to move the metastore into a separate project - It seems to me that some security related features/apis which are specific to the metastore are outside of it…so separating the metastore would definetly mean a cleanup in this area as well - which will in turn make the

Re: [DISCUSS] Separating out the metastore as its own TLP

Comments inlined. On Sun, Jul 2, 2017 at 3:22 PM, Edward Capriolo wrote: > I am not sure I am on the fence with this. > > I am -1, and I offer this -1 with the hope of being convinced otherwise > Thank you for being open to reconsider. > > > "By making it a separate

Re: [DISCUSS] Separating out the metastore as its own TLP

"I do not know how this works for TLP proposals, but I also do not think the TLP process will "open" anything new up for you. IE I do not think the proposal will grant anyone a free ride seat on the commiter/pmc list (I surely would not support that" I was unclear, I did not mean "you" or

Re: [DISCUSS] Separating out the metastore as its own TLP

On Fri, Jun 30, 2017 at 2:49 PM, Julian Hyde wrote: > +1 > > As a Calcite PMC member, I am very pleased to see this change. Calcite > reads metadata from a variety of sources (including JDBC databases, NoSQL > databases such as Cassandra and Druid, and streaming systems), and

Re: [DISCUSS] Separating out the metastore as its own TLP

I am not sure I am on the fence with this. On Sat, Jul 1, 2017 at 6:38 AM, Chaoyu Tang wrote: > +1. A nice move which might help HMS to be more easily adopted by more > other components. > > On Sat, Jul 1, 2017 at 12:41 AM, Sushanth Sowmyan > wrote: > >

Re: [DISCUSS] Separating out the metastore as its own TLP

+1. A nice move which might help HMS to be more easily adopted by more other components. On Sat, Jul 1, 2017 at 12:41 AM, Sushanth Sowmyan wrote: > +1 > > On Jun 30, 2017 17:05, "Owen O'Malley" wrote: > > > On Fri, Jun 30, 2017 at 3:26 PM, Chao Sun

Re: [DISCUSS] Separating out the metastore as its own TLP

+1 On Jun 30, 2017 17:05, "Owen O'Malley" wrote: > On Fri, Jun 30, 2017 at 3:26 PM, Chao Sun wrote: > > > and maybe a different project name? > > > > Yes, it certainly needs a new name. I'd like to suggest Riven. > > .. Owen >

Re: [DISCUSS] Separating out the metastore as its own TLP

On Fri, Jun 30, 2017 at 3:26 PM, Chao Sun wrote: > and maybe a different project name? > Yes, it certainly needs a new name. I'd like to suggest Riven. .. Owen

Re: [DISCUSS] Separating out the metastore as its own TLP

Yeah, this is good idea. +1 On Fri, Jun 30, 2017 at 3:26 PM, Chao Sun wrote: > HMS has become the shared catalog service for multiple projects outside > Hive, > so +1 on this move (and maybe a different project name?). > > On Fri, Jun 30, 2017 at 2:10 PM, Owen O'Malley

Re: [DISCUSS] Separating out the metastore as its own TLP

HMS has become the shared catalog service for multiple projects outside Hive, so +1 on this move (and maybe a different project name?). On Fri, Jun 30, 2017 at 2:10 PM, Owen O'Malley wrote: > I'm +1 on separating out the metastore. It recognizes the reality that a > lot

Re: [DISCUSS] Separating out the metastore as its own TLP

I'm +1 on separating out the metastore. It recognizes the reality that a lot of different projects use the Hive Metastore and opening up the community is a great move. ..Owen On Fri, Jun 30, 2017 at 1:30 PM, Xuefu Zhang wrote: > +1, sounds like a good idea! > > On Fri, Jun 30,

Re: [DISCUSS] Separating out the metastore as its own TLP

+1, sounds like a good idea! On Fri, Jun 30, 2017 at 1:24 PM, Harsha wrote: > Thanks for the proposal Alan. I am +1 on separating the Hive Metastore. > This is a great opportunity for building a Metastore to not only address > schemas for the data at rest but also for the data

Re: [DISCUSS] Separating out the metastore as its own TLP

Thanks for the proposal Alan. I am +1 on separating the Hive Metastore. This is a great opportunity for building a Metastore to not only address schemas for the data at rest but also for the data in motion. We have a SchemaRegistry (http://github.com/hortonworks/registry) project that allows

Re: [DISCUSS] Separating out the metastore as its own TLP

Great, thanks Alan for putting all this in the email. +1 Allowing other components to continue to use the Metastore without the need to use Hive dependencies is a big plus for them. I agree with everything you mention on the email. - Sergio On Fri, Jun 30, 2017 at 1:49 PM, Julian Hyde

Re: [DISCUSS] Separating out the metastore as its own TLP

+1 As a Calcite PMC member, I am very pleased to see this change. Calcite reads metadata from a variety of sources (including JDBC databases, NoSQL databases such as Cassandra and Druid, and streaming systems), and if more of those sources choose to store their metadata in the metastore it

Re: [DISCUSS] Separating out the metastore as its own TLP

On 2017-06-30 07:56 (-0700), Alan Gates wrote: > A few of us have been talking and come to the conclussion that it would be > a good thing to split out the Hive metastore into its own Apache project. > Below and in the linked wiki page we explain what we see as the

[DISCUSS] Separating out the metastore as its own TLP

A few of us have been talking and come to the conclussion that it would be a good thing to split out the Hive metastore into its own Apache project. Below and in the linked wiki page we explain what we see as the advantages to this and how we would go about it. Hive’s metastore has long been used