CEPH filesystem development
 help / color / mirror / Atom feed
From: Marcus Watts <mwatts@redhat.com>
To: Sage Weil <sweil@redhat.com>
Cc: Ken Dreyer <kdreyer@redhat.com>, ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: ceph / rocksdb
Date: Thu, 25 Feb 2016 03:15:22 -0500	[thread overview]
Message-ID: <20160225081522.GA14622@degu.b.linuxbox.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1602241305060.7555@cpach.fuggernut.com>

On Wed, Feb 24, 2016 at 01:06:48PM -0500, Sage Weil wrote:
> On Wed, 24 Feb 2016, Ken Dreyer wrote:
> > I'm really interested in getting our various bundled libraries into
> > separate packages.
> > 
> > Does ceph's rocksdb have a lot of changes from rocksdb upstream? If
> > so, I'm leaning towards packaging this as "ceph-rocksdb" until those
> > changes are present in an upstream rocksdb release.
> 
> There are a few that aren't upstream yet, but they'll merge eventually. 
> That said, I fully expect that we'll make other changes in the future that 
> we'll want to build/test/ship before they go upstream... so a special 
> package name probably makes sense.
> 
> sage
> 
> 
> > 
> > - Ken
> > 
... and I'm eliding what I posted originally to conserve electrons.

When I looked at upstream rocksdb I couldn't find anything we had that
they didn't have.  I believe it should not be hard to work towards
a target of using the unmodified distribution version in production
environments.

Looks like:
* debian - has rocksdb (=4.1.0); appears to be very recent.  Has no
  current packages that use rocksdb.  There appear to be plans to use
  rocksdb with osquery.
* ubuntu.  Looks to be the identical state to debian, same maintainer.
* fedora.  No rocksdb currently.  I think we could be the maintainer here,
		if we want.

All this is going to be very distribution specific, involve maintainers,
upstream, &etc.  Still, this looks like it could be very tractable.

What we do locally with "build/test/ship" is another matter entirely.
I can see a world where the gitbuilders just install "our" rocksdb as
another build dependency for ceph.  Conceivably if we want to get fancy
those gitbuilders (or others?) could also be building rocksdb (presumably
from our repo), producing packages that after additional vetting (teuthology
etc.) can be made available to the ceph git builders.  The only real
complexity I can see is it might be useful sometimes to steer different
rocksdb packages towards different ceph branches.

					-Marcus Watts

  reply	other threads:[~2016-02-25  8:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24  6:05 ceph / rocksdb Marcus Watts
2016-02-24 17:58 ` Ken Dreyer
2016-02-24 18:04   ` Allen Samuels
2016-02-24 18:06   ` Sage Weil
2016-02-25  8:15     ` Marcus Watts [this message]
2016-02-25 20:21   ` Nathan Cutler
2016-06-06 10:05     ` Willem Jan Withagen
2016-06-06 10:43       ` Nathan Cutler
2016-06-06 12:26       ` Sage Weil
2016-06-06 12:29         ` Willem Jan Withagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160225081522.GA14622@degu.b.linuxbox.com \
    --to=mwatts@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=kdreyer@redhat.com \
    --cc=sweil@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox