On Tue, 2016-09-27 at 11:17 -0700, Gregory Farnum wrote: > On Tue, Sep 27, 2016 at 10:39 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > On Tue, 2016-09-27 at 15:13 +0000, Sage Weil wrote: > > > > > > On Tue, 27 Sep 2016, Jeff Layton wrote: > > > > > > > > (tl;dr: we need to make some changes to the libcephfs API to allow > > > > proper credential handling. What's the right approach to take?) > > > > > > > > Greg Farnum has posted a pull request to rework how credentials are > > > > handled in cephfs: > > > > > > > > https://github.com/ceph/ceph/pull/11218 > > > > > > > > ...the patch pile is rather large, but the upshot is basically to > > > > change the code not to carve out '-1' in the uid and gid ranges, and to > > > > allow callers to pass down lists of supplementary groups. This is > > > > mainly needed for nfs-ganesha, but it also allows ceph-fuse to delegate > > > > permissions checks to the MDS. > > > > > > > > That PR adds most of the low-level plumbing that's needed, but we still > > > > need to expose this capability to applications via libcephfs. Many > > > > libcephfs calls either take "int uid, int gid" or don't allow the > > > > caller to send down creds at all. > > > > > > > > I think what we'll want to do is allow applications to create a new > > > > credential object and pass that down to the library in some fashion. > > > > The question is: what's the best way to handle those API changes? > > > > > > > > We have several options here: > > > > > > > > 1) make a clean break with the old API: just change the arguments to > > > > the existing functions, bump the library's major version and set the > > > > "age" field in it to 0. If you built against old headers, it'll fail to > > > > load the library at runtime. This is clearly the simplest option, but > > > > requires everyone to rebuild applications that were built against the > > > > old headers. > > > > > > I think this is the way to go. We'd bump the SONAME (libcephfs2!). The > > > packaging infrastructure is such that you can have the old version of the > > > package (libcephfs1) installed at the same time as libcephfs2 (and > > > -devel), so stuff that's linked to the old API can still work and > > > coexist with stuff linked to the new one. The only restriction (on debian > > > at least; I assume in rpm-land it is the same) is that you can only have > > > one version of the -dev package (headers) installed at a time, so you can > > > only compile new code against one version at a time. > > > > > > IIRC with the SONAME stuff you can specify the oldest compatible > > > version. We can take the lazy route and skip #2 below and make that 2 as > > > well, which would mean installing libcephfs1 and libcephfs2 concurrently > > > for compatibility. > > > > > > It seems like the key downside here is that any project building against > > > libcephfs that isn't updated will not be able to use newer versions of the > > > client until they move to the new API... > > > > > > sage > > > > > > > This brings up another point... > > > > When I added the struct ceph_statx interfaces, I left the old struct > > stat interfaces intact. So we now have ceph_statx and ceph_ll_getattrx, > > etc. If we're making a clean API break where we change args on existing > > function names, then we don't really need those new calls. > > > > Anyone have objections to me just converting the old struct stat based > > functions to use struct ceph_statx instead, and dumping the new > > function prototypes that I added? > > > > It'll mean some code churn in the short term, but I think it'll make > > for a simpler API later. > > Yeah, that makes sense as long as we're going incompatible. > > Here's another question, though: should we actually copy the source > code to create libcephfs2, and generate libcephfs1 through the > Luminous release to give anybody who is running stuff out there a > window to change over smoothly? I don't expect we'd need to actually > change the libcephfs1 source code; certainly it won't take much... > -Greg Sure, I don't think it'd be too hard to do that, just a little shim layer on top of the new API. Here's another thing too though. We have both java and python bindings in the tree as well. They don't really deal with creds, but they do wrap ceph_stat() and friends...should I convert those over to use the statx-based APIs as well? -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
