I really like the idea of a ceph users/devs meetup in Europe.
Especially if it's in NL/BE. Keep me posted :-)
On Wed, Sep 25, 2013 at 10:53 AM, Loic Dachary wrote:
> Hi Eric & Patrick,
>
> Yesterday morning Eric suggested that organizing a ceph user meetup would be
> great and proposed his help
Oh, and I meant the sha hash you're using (so basically the output of
git rev-parse HEAD), so I can reproduce it... :-)
On Fri, Sep 13, 2013 at 9:50 PM, Roald van Loon wrote:
> Hi Lluis,
>
> Something strange is happening here; seems like automake does not add
> any of the lib
hat output.
Roald
On Fri, Sep 13, 2013 at 9:04 PM, Lluís Pàmies i Juárez
wrote:
> Hi Roald,
>
> I'm using git version 1.8.1.2, and run a plain "./configure" with no extra
> args.
>
> Thank you.
>
> On Fri, Sep 13, 2013 at 11:23 AM, Roald van Loon
>
Hi,
I assume this is fixed by #594?
Roald
On Fri, Sep 13, 2013 at 5:01 PM, Sage Weil wrote:
> afaict the tcmalloc gitbuidler is building against tcmalloc again. this
> probably got broken by the Makefile refactor?
>
> s
>
> On Thu, 12 Sep 2013, teuthwor...@teuthology.front.sepia.ceph.com wrote
Hi,
I haven't seen this error before. What's your git version? And could
you give us your configure command, config.status file and the output
of a make V=1?
Roald
On Fri, Sep 13, 2013 at 6:06 PM, Lluís Pàmies i Juárez
wrote:
> Hello,
>
> I'm having problems to compile the main git branch. I tr
On Sat, Sep 7, 2013 at 10:39 PM, Sage Weil wrote:
> I'm particularly keen on doing what we can to reduce build time. I also
> agree there is a fair bit of tree restructuring that needs to be done.
> (For example, libcommon.la is huge and includes lots of stuff that most
> targets don't actually n
On Mon, Sep 9, 2013 at 1:27 AM, Milosz Tanski wrote:
> Are you using gold as a linker already instead of the traditional
> binutils bdf based ld. It does make a difference esp on large C++ code
> bases (where linking takes a lot of time).
Actually I'm using by default on code bases the size of Ce
On Mon, Sep 9, 2013 at 1:16 AM, Sage Weil wrote:
> I took a quick look and it looks pretty great. The builds are coming back
> okay, too.. any compelling reason not to merge it now?
Nope, not really. I'll do some last build checks at the end of today
(monday over here) and then send you a pull r
Hi Noah, Sage,
The build time has improved in wip-automake somewhat (mainly because
almost all files are now only compiled to objects once instead of
per-target), but much of the time goes into linking.
> I was just looking through build-refactor, and it doesn't really look
> like there is much t
On Sat, Sep 7, 2013 at 7:47 PM, Noah Watkins wrote:
> Oh, and one question about the non-recursive approach. If I stick a
> Makefile.am in the test/ directory I can do things like:
>
> LDADD = all-the-test-dependencies
>
> and then avoid redundant per-target primaries like test_LDADD = (deps)
>
> up a branch, make-refactor, that I was hacking on a bit. Not sure how
> much overlap there is, or if my approach is bogus, but I thought I'd
> point it out to see if there is anything that can be combined :)
>
> -Noah
>
> On Wed, Aug 21, 2013 at 2:01 PM, Roald van Loon
Hi,
> Good catch. I've cherry-picked the first, and just the MonitorDBStore::Op
> part to next. I think the header changes should stay in your branch until
> it is ready to go. It appears to be getting closer, though!
Alright. I just rebased my branch against master to see if it still
builds,
Sorry, the format-patch of the first email was screwed up (tried to
copy/paste the email because git was compiled without perl and hence
had no send-email support... should have known that would go haywire)
Roald
On Tue, Aug 27, 2013 at 11:49 AM, Roald J. van Loon
wrote:
> Trivial cleanup. There
Trivial cleanup. There were still 3 references to g_conf in CephxKeyServer.
Replaced them in favor of cct->_conf.
Signed-off-by: Roald J. van Loon
---
diff --git a/src/auth/cephx/CephxKeyServer.cc b/src/auth/cephx/CephxKeyServer.cc
index e0c8174..e57b557 100644
--- a/src/auth/cephx/CephxKeyServer
On Wed, Aug 21, 2013 at 10:41 PM, Sage Weil wrote:
> Yes, the Makefile.am is in dire need of from TLC from someone who knows a
> bit of autotools-fu. It is only this way because in the beginning I
> didn't know any better.
Well, my average knowledge of autotools could at least fix this
particula
Hi,
On Wed, Aug 21, 2013 at 10:01 PM, Noah Watkins wrote:
> This patch will turn on the option (which should also fix your problem
> if I understand correctly?), and should probably be committed anyway
> as newer versions of autotools will complain loudly about our current
> Makefile structure.
Hi Ceph devs,
I'm working on doing some structuring/designing plugins for RGW. In a
recent discussion with Yehuda, I'm looking into how we can statically
link 'plugins' into the RGW core (so, not really plugins, but more of
a code separation).
However, the ceph automake structure doesn't use AM's
On Tue, Aug 20, 2013 at 4:49 PM, Yehuda Sadeh wrote:
> I was referring to your work at wip-rgw-plugin, where the plugin code
> itself still needs to rely on the rgw utility code.
Right. So we can agree on ditching the dynamic loading thing and clean
internal API (for now), but at least start sepa
On Tue, Aug 20, 2013 at 2:58 AM, Yehuda Sadeh wrote:
> Well, practically I'd like to have such work doing baby steps, rather
> than swiping changes. Such changes have higher chances of getting
> completed and eventually merged upstream. That's why I prefer the
> current model of directly linking
That's why I
asked for comments to begin with :-)
I'll start thinking about a design for an internal API but I'll
definitely need some help with that. I'm not a fulltime Ceph developer
:-)
Roald
On Mon, Aug 19, 2013 at 10:05 PM, Yehuda Sadeh wrote:
> On Mon, Aug 19, 2013
Hi,
I started out by defining the plugin system a bit more
(http://wiki.ceph.com/01Planning/02Blueprints/Emperor/rgw:_plugin_architecture).
I'd really appreciate any comments.
On Wed, Aug 14, 2013 at 8:40 PM, Yehuda Sadeh wrote:
>> - "AUTH" (Authentication backends): Rados/internal, Keystone
>
imply moving existing code into plugins
instead of adding new code until we have a plugin system with which we
can live with, we can always go back without breaking functionality.
Roald
On Wed, Aug 14, 2013 at 7:17 PM, Yehuda Sadeh wrote:
> On Wed, Aug 14, 2013 at 5:57 AM, Roald van Loon
>
Hi all,
For those interested;
http://wiki.ceph.com/01Planning/02Blueprints/Emperor/rgw:_plugin_architecture
I know a plugin architecture is a sensitive subject for a lot of
people (it is for me at least), but I think it might be worthwhile
discussing it.
Please comment/flame away :-)
Roald
PS:
Hi ceph devs,
I was working with a RGW / keystone implementation, source tree from
github master. I stumbled against this error from the radosgw log;
2013-08-06 14:00:02.523331 7f929c011780 10 allocated request req=0x1c31640
2013-08-06 14:00:02.556052 7f923bfff700 10 request returned
2013-08-06 1
Came across it this morning when booting my development environment,
has anyone seen this before?
It's with 0.67-rc2;
2013-07-30 08:09:09.230349 mon.0 [INF] pgmap v4172: 1216 pgs: 123
active, 219 active+clean, 161 active+clean+replay, 713 peering; 241 MB
data, 630 MB used, 5483 MB / 6114 MB avail
Sorry, just realized you're in a different timezone and that the
fix/cleanup is actually quite easy and done before you will read this
message :-)
I've sent a pull request on github.
Roald
On Fri, Dec 21, 2012 at 12:01 PM, Roald van Loon wrote:
> I see.
>
> I always tho
t; In an ideal world, things that link in g_ceph_context would have a
> separate #include and other code wouldn't see the declaration, but we
> didn't get that far when this was cleaned up a while back. Instead, you
> get a linker error if you, say, do dout(...) instead of ldout(..
Hi ceph devs,
I was wondering. In common/dout.h is an #include of
global/ceph_context.h, but it is not used there (I stumbled upon it
because while playing around in the codebase, I noticed librados would
not link because of an undefined reference to g_ceph_context). I have
no idea why this includ
ild (tm), but could be that some binaries
fail to link. I've tested ceph-osd, -mon and -mds, and at least
those compile OK.
Let me know if you have any questions/comments.
- Roald
On Sat, Dec 15, 2012 at 10:38 AM, Roald van Loon wrote:
> For the new configuration framework, I need so
Would be nice indeed, but IIRC, nilfs does not support xattrs, yet...
On Fri, Dec 14, 2012 at 1:47 AM, Sage Weil wrote:
> nilfs2 has a 'continuous snapshotting' architecture that the ceph-osd can
> take advantage of for making fully-consistent checkpoints of state for
> recovering from a crash.
nged some entries in MonMap.cc::build_initial
to show how we can use the macros.
If this is OK with you guys, I want to slowly replace access
to configuration value with these macros.
Signed-off-by: Roald van Loon
---
src/common/config.h |2 ++
src/config/config.h | 36 +++
Hi,
Alright, I did some work on this. My time was limited last week, so it
took a while. Nonetheless, I have some changes pushed to github
(github.com/roaldvanloon, ceph, branch wip-config).
Most of the time went into thinking about a nice & clean interface
which A) would make porting the existin
On Mon, Dec 3, 2012 at 10:51 PM, Josh Durgin wrote:
> It looks like you've got a good start on integrating it into the main
> ceph infrastructure. Skimming over it, the general structure makes sense
> to me. One part that might be a bit tricky is making the new parsing
> backwards compatible with
ation in main() such that it uses the new config.
A make ceph-osd2 && ./ceph_osd2 --help should work.
- Roald
On Mon, Dec 3, 2012 at 10:57 AM, Roald van Loon wrote:
> Hi list, ceph devs,
>
> I've been doing some toying with Ceph lately in my spare time and one
> of the t
Hi list, ceph devs,
I've been doing some toying with Ceph lately in my spare time and one
of the things I'm doing is trying to refactor some of the
configuration handling / argument parsing. I had some trouble finding
specific runtime options and configuration settings, so I thought this
was a goo
Hi Tim,
It's all up to you whether you assign more roles to a system or not.
What actually happens is that you need to start a daemon for each
of the ceph services. Each of the systems in your ceph cluster will
most likely run at least one of those daemons, but it is not required
that all system r
36 matches
Mail list logo
