Reviewed the PR on github, but bringing it back to the list... On Sat, Aug 11, 2018 at 2:39 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > Two questions so far: > > 1) I marked the librados calls that take aui deprecated, but I can wire > them up to still work. For example, if you call pool_create_with_auid it > can still create a pool. Alternatively, I can make those calls now return > EOPNOTSUPP. That could break some wayward librados user, though. > Similarly, there are calls to get and set the pool auid. Currently I have > converted to no-ops, but they could also return an error instead. > Thoughts? I think we should be more subtle: mark them deprecated, but continue functioning as normal if the user doesn't set an auid. Return EOPNOTSUPP if they do. That seems like a gentler transition for librados users without silently breaking anybody who actually uses auids. > > 2) The rados cli has a 'mkpool' command that works like 'rados mkpool > <poolname> [auid [crush-rule]]'. The ordering means I can't just drop > auid. So, I could ignore the auid argument, or change the calling > convention completely. > > Or, we could remove the command completely and let people use 'ceph osd > pool create' for this. This is my preference! This is fine. > In fact, there are > several commands I'd suggest killing at the same time: > > " mkpool <pool-name> [123[ 4]] create pool <pool-name>'\n" > " [with auid 123[and using crush rule > 4]]\n" > " cppool <pool-name> <dest-pool> copy content of a pool\n" > " rmpool <pool-name> [<pool-name> --yes-i-really-really-mean-it]\n" > " remove pool <pool-name>'\n" > " purge <pool-name> --yes-i-really-really-mean-it\n" > " remove all objects from pool > <pool-name> without removing it\n" > > cppool is an imcomplete implementation anyway (doesn't preserve snaps, > for example; prabably doesn't do omap either?). The others just scare me. I'm generally with you here, although we should do a separate (more obvious) subject line about removing that -- I'm not sure all the cppool users are broken. On Sat, Aug 11, 2018 at 4:51 PM, Adam Tygart <mozes@xxxxxxx> wrote: > I don't care what happens to most of these rados commands, and I've > never used the auid "functionality", but I have found the rados purge > command quite useful when testing different rados level applications. > > Run a rados-level application test. Whoops it didn't do what you > wanted, purge and start over. It is significantly faster than > alternative of looping through a 'rados ls' and issuing 'rados rm' for > every object. Sure I could delete the pool and recreate one with the > same name, but that seems wasteful. Enabling pool deletion in the > monitors, allocating new pool ids, causing the mass re-peering of > placement groups, making sure the all of the per-pool settings exactly > match what you had before. It gets tedious. > > If the code-path for a purge is different on the server-side, perhaps > there could be an additional permission to let the cephx user perform > a purge. At least then it is protected from the casual (ab)user. I'm surprised that you find purge this much faster -- it is not in itself doing anything clever or server-side, merely running an object listing and issuing deletes for whatever turns up. I think it also doesn't do anything with snapshots etc (though maybe I didn't look hard enough) which would make it not even a real purge... Perhaps it's best to just let users who want this functionality wire it up in a hacky binary themselves so they understand its behavior? -Greg _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |