Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # dev >> Thinking about 0.98


+
Andrew Purtell 2013-08-15, 19:21
+
Stack 2013-08-15, 20:14
+
Jonathan Hsieh 2013-08-15, 20:25
+
Andrew Purtell 2013-08-16, 00:57
+
Jonathan Hsieh 2013-08-22, 01:42
+
Andrew Purtell 2013-08-22, 02:18
+
lars hofhansl 2013-08-22, 05:40
+
Andrew Purtell 2013-08-22, 16:42
+
Stack 2013-08-22, 20:36
+
Andrew Purtell 2013-08-22, 21:39
+
Stack 2013-08-22, 21:56
+
Andrew Purtell 2013-08-22, 23:07
+
Stack 2013-08-22, 23:20
+
Andrew Purtell 2013-08-22, 23:28
+
Dan Burkert 2013-08-23, 03:41
+
Stack 2013-08-23, 17:15
+
Dan Burkert 2013-08-23, 23:03
+
James Taylor 2013-08-23, 23:06
+
Andrew Purtell 2013-08-27, 11:28
Copy link to this message
-
Re: Thinking about 0.98
HBASE-9247.  (will post when I've cleaned it up moe)  Has to do with the
full comparator classnames being included in HFile's trailer and Bloom
block meta data.  I have a kludgy workaround for it now but if we are
updating file versions, it could be nice to unkludge it.
On Wed, Aug 21, 2013 at 7:18 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> >
> I'm working on some API clean up currently which oddly will also affect the
> HFile format.
>
> Can you point to a jira?
>
> > I'd also like to do some API culling and simplification -- where would
> this
> go?
>
> Since 0.98 is to come quickly after 0.96 and test our compatibility story,
> we should take this case by case. My feeling is if after the changes a 0.96
> client can still talk to a 0.98 server, and a mixed 0.96 and 0.98 server
> environment is still possible, then it could go into 0.98 even if it breaks
> Java binary compatibility for client applications, we're not at 1.0 yet.
> Any objections?
>
> >
> Would 0.98 be branched off of trunk or 0.96 then?
>
> I was thinking of branching 0.98 from trunk "soon" after 0.96 is released.
>
>
>
> On Wed, Aug 21, 2013 at 6:42 PM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:
>
> > A few questions:
> >
> >
> > On Thu, Aug 15, 2013 at 5:57 PM, Andrew Purtell <[EMAIL PROTECTED]>
> > wrote:
> >
> > > > My suggestion is that we limit the number of major features targeting
> > > this version.
> > >
> > > +1
> > >
> > > > Can we say Tags the only Major feature that must get in and then all
> > > major features are not blockers?
> > >
> > > Core changes, you mean? One or perhaps two significant core changes
> could
> > > be doable in the available time. Is there another besides tags/HFile
> V3?
> > >
> > >
> > Something will likely show up --
> > I'm working on some API clean up currently
> > which oddly will also affect the HFile format.
> >
> >
> >
> > > What I would consider a blocker would be a usability problem, a
> > performance
> > > regression, or an API, wire, or data compatibility regression.
> > >
> > > In my opinion, a new feature should be implemented within a well
> defined
> > > space for that purpose: as a coprocessor, plugin, or as a feature of
> > HFile
> > > V3 (which I would like to make more pluggable, therefore extensible and
> > > maintainable). I propose HFile V3 be included, marked as experimental
> > > through the 0.98 cycle, with a feature freeze at the .0 release.
> > >
> > > Sounds reasonable.
> >
> >
> > > > What do you think our planned 0.96 compat story is wrt 0.98?
> > >
> > > 0.96 and 0.98 should be able to run in a mixed server side environment
> > > while a rolling upgrade is in progress, without limits imposed on how
> > long
> > > that might take. Perhaps 0.98 is deployed only to one table placement
> > group
> > > as a trial. With the caveat that new features might introduce
> > > complications, continuing the example, a new HFile feature is enabled
> > for a
> > > table and placement group so the table can't be placed elsewhere.
> Clients
> > > should be able to run in a mixed version environment indefinitely.
> > >
> > > I'd also like to do some API culling and simplification -- where would
> > this go?
> >
> > Would 0.98 be branched off of trunk or 0.96 then?
> >
> >
> > >
> > > On Thu, Aug 15, 2013 at 1:25 PM, Jonathan Hsieh <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > On Thu, Aug 15, 2013 at 12:21 PM, Andrew Purtell <
> [EMAIL PROTECTED]
> > > > >wrote:
> > > >
> > > > > On the thread '[UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96
> > > > > remaining issues', Stack, our RM for 0.95/0.96 has drawn the line
> on
> > a
> > > > > feature freeze and set a course for an 0.96 release to happen soon.
> > > > Toward
> > > > > the end of that thread there is a bit on beyond 0.96 that I have
> > > included
> > > > > below for your reference. To summarize the discussion points:
> > > > >
> > > > > - This is a call for an 0.98 major release in early October. Let's
> > > > discuss
> > > > > first if that timeframe is reasonable, and then what can and should

// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB