> -----Original Message----- > From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel- > owner@xxxxxxxxxxxxxxx] On Behalf Of Adam C. Emerson > Sent: Friday, June 10, 2016 12:59 PM > To: Gregory Farnum <gfarnum@xxxxxxxxxx> > Cc: The Sacred Order of the Squid Cybernetic <ceph-devel@xxxxxxxxxxxxxxx> > Subject: Re: A Transformation of our Global Context > > On 10/06/2016, Gregory Farnum wrote: > > Maybe I'm misunderstanding the scope of what you're proposing, but I > > don't think this is a good reason to go through this work right now. > > Lots of things that seem process-specific turn out to be essentially > > cluster properties, despite being configurable on both ends, and will > > need to be referenced from all over the stack. And in general if we're > > addressing multiple Ceph clusters within a utility we want a full > > RadosClient etc for each cluster, so the split doesn't do us much good > > on its own, does it? (If we don't want separate admin sockets for each > > one, we'd need to extend all of those interfaces to support two > > entries for the same type of thing, etc) > > Finding out exactly which things are process specific is one reason I'm > soliciting for feedback. AdminSocket doesn't have to be included. Really, I > think we'd get a lot of benefit if we made JUST some debug options and dout > support process specific and refactored it that way. Other things could move > later on if people wanted them to but wouldn't have to. > > > > If this is your actual goal, I think the unappealing work of replacing > > g_ceph_context with a CephContext *cct is the way to go — we'd need to > > do this much to support multiple ClusterContexts within a process > > anyway. Once we have a motivating use case for splitting stuff up, we > > can address that. But if we try and do a generic solution it'll be > > much more difficult, and probably will miss some key points we don't > > run into until trying to make use of it. > > > > Am I missing something? > > -Greg > > I have been working on the unappealing work of replacing g_ceph_context > with CephContext* cct. It's not just unappealing work, it ends up wiht a > result ugly enough I don't think I'd want to merge it if someone presented it > to me. It's very invasive in that it changes a whole lot of everything. The split > would ALSO change a whole lot of everything, but likely less. You would at > least be able to avoid changing the constructors of a while bunch of > unrelated things just to pass a variable in that only some member several > classes in cares about so it can log a message. Have you considered threadlocal storage for this? I suspect it's a *much* easier way to go. Very little source code will need modification. > > > -- > Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US > IRC: Aemerson@{RedHat, OFTC, Freenode} > 0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C 7C12 80F7 544B 90ED BFB9 > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the > body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at > http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
