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.
--
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
