On Fri, 9 Mar 2018, Matt Benjamin wrote: > Hi Sage, > > On Fri, Mar 9, 2018 at 6:44 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > > I suspect there are some headaches with regard to the current structure of > > radosgw-admin code that make wrapping it up in a library with python > > bindings a painful exercise, but that doesn't mean it isn't worth the > > effort for just the realm management pieces? > > > > sage > > I see those concerns as more serious then mere headaches in the short > to medium run. The issue is not how quickly wrappers can be > developed, but how robust and serviceable long-running ceph-mgr > daemons that have loaded an RGW instance in-process will be over the > life of deployed L and M clusters, relative to some other organization > of the same code. My (limited) understanding is that radosgw-admin runs in two modes: one where it instantiates itself as a radosgw (with watches and so on) and another where it does not, and which depends one which function it is doing. My assumption is that for things that manipulate the zone maps it isn't instantiating a full radosgw (because e.g. a zone may not even exist), and that the limited set of things we need to do from the mgr would probably all fall in that category. Maybe I'm misunderstanding what you mean by "robust and serviceable long-running ceph-mgr daemons" means, though. Are you worried that the mgr daemons will restart to frequently to be stable, or that it will be harder to upgrade the radosgw plugin piece if it is loaded into a long-running mgr daemon? (If it's the latter, I would expect we'd just upgrade and restart mgr when we upgrade and restart radosgw, although again the limited set of functions we need in mgr probably wouldn't require it.) > It's not as if I'm not a strong advocate for in-process organization > in general, there already is a librgw that does NFS, and in the longer > run, I'd like to see more integration along those lines (e.g., as we > had at Cohort with pNFS data servers and OSDs). I think python > bindings for RGW RADOS is a lot different, though, and I'm not sold > yet that we really have to, to give the dashboard everything it > aspires to. > > Is that crazy talk? I can't really tell without details. Why are python bindings for rgw zone management functions different, and what is the alternative you propose? I mean, we could do it all today if the mgr just shells out to radosgw-admin (to make changes or dump the zone map and parse the output), I suppose, but I'm not sure I like that as a permanent solution. sage -- 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
