On Fri, Jun 10, 2016 at 12:58 PM, Adam C. Emerson <aemerson@xxxxxxxxxx> wrote:
> 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.
So you want everything to stay with/go back to having a global member
for the ProcessContext?
I'm surprised it needs to find its way into so many random things;
most objects have references to their parent that let them go back to
the MDSRank/OSD/whatever main class there is.
>
>
> --
> 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
