Based on past LTS release dates would predict Luminous much sooner than that, possibly even in May... http://docs.ceph.com/docs/master/releases/
The docs also say "Spring" http://docs.ceph.com/docs/master/release-notes/ -Ben On Thu, Apr 13, 2017 at 12:11 PM, <[email protected]> wrote: > Thanks a lot, Trey. > > I'll try that stuff next week, once back from Easter holidays. > And some "multi site" and "metasearch" is also still on my to-be-tested > list. Need badly to free up some time for all the interesting "future of > storage" things. > > BTW., we are on Kraken and I'd hope to see more of the new and shiny stuff > here soon (something like 11.2.X) instead of waiting for Luminous late > 2017. Not sure how the CEPH release policy is usually?! > > Anyhow, thanks and happy Easter everyone! > Anton > > > Gesendet: Donnerstag, 13. April 2017 um 20:15 Uhr > Von: "Trey Palmer" <[email protected]> > An: [email protected] > Cc: "Trey Palmer" <[email protected]>, [email protected] > Betreff: Re: [ceph-users] Question about RadosGW subusers > > Anton, > > It turns out that Adam Emerson is trying to get bucket policies and roles > merged in time for Luminous: > > https://github.com/ceph/ceph/pull/14307 > > Given this, I think we will only be using subusers temporarily as a method > to track which human or service did what in which bucket. This seems to us > much easier than trying to deal with ACL's without any concept of groups, > roles, or policies, in buckets that can often have millions of objects. > > Here is the general idea: > > > 1. Each bucket has a user ("master user"), but we don't use or issue that > set of keys at all. > > > radosgw-admin user create --uid=mybucket --display-name="My Bucket" > > You can of course have multiple buckets per user but so far for us it has > been simple to have one user per bucket, with the username the same as the > bucket name. If a human needs access to more than one bucket, we will > create multiple subusers for them. That's not convenient, but it's > temporary. > > So what we're doing is effectively making the user into the group, with > the subusers being the users, and each user only capable of being in one > group. Very suboptimal, but better than the total chaos that would result > from giving everyone the same set of keys for a given bucket. > > > 2. For each human user or service/machine user of that bucket, we create > subusers. You can do this via: > > ## full-control ops user > radosgw-admin subuser create --uid=mybucket --subuser=mybucket:alice > --access=full --gen-access-key --gen-secret --key-type=s3 > > ## write-only server user > radosgw-admin subuser create --uid=mybucket --subuser=mybucket:daemon > --access=write --gen-access-key --gen-secret-key --key-type=s3 > > If you then do a "radosgw-admin metadata get user:mybucket", the JSON > output contains the subusers and their keys. > > > 3. Raise the RGW log level in ceph.conf to make an "access key id" line > available for each request, which you can then map to a subuser if/when you > need to track who did what after the fact. In ceph.conf: > > debug_rgw = 10/10 > > This will cause the logs to be VERY verbose, an order of magnitude and > some change more verbose than default. We plan to discard most of the > logs while feeding them into ElasticSearch. > > We might not need this much log verbosity once we have policies and are > using unique users rather than subusers. > > Nevertheless, I hope we can eventually reduce the log level of the "access > key id" line, as we have a pretty mainstream use case and I'm certain that > tracking S3 request users will be required for many organizations for > accounting and forensic purposes just as it is for us. > > -- Trey > > On Thu, Apr 13, 2017 at 1:29 PM, <[email protected][mailto: > [email protected]]> wrote:Hey Trey. > > Sounds great, we were discussing the same kind of requirements and > couldn't agree on/find something "useful"... so THANK YOU for sharing!!! > > It would be great if you could provide some more details or an example how > you configure the "bucket user" and sub-users and all that stuff. > Even more interesting for me, how do the "different ppl or services" > access that buckets/objects afterwards?! I mean via which tools (s3cmd, > boto, cyberduck, mix of some, ...) and are there any ACLs set/in use as > well?! > > (sorry if this all sounds somehow dumb but I'm a just a novice ;) ) > > best > Anton > > > Gesendet: Dienstag, 11. April 2017 um 00:17 Uhr > Von: "Trey Palmer" <[email protected][mailto:[email protected]]> > An: [email protected][mailto:[email protected]] > Betreff: [ceph-users] Question about RadosGW subusers > > Probably a question for @yehuda : > > > We have fairly strict user accountability requirements. The best way we > have found to meet them with S3 object storage on Ceph is by using RadosGW > subusers. > > If we set up one user per bucket, then set up subusers to provide separate > individual S3 keys and access rights for different people or services using > that bucket, then we can track who did what via access key in the RadosGW > logs (at debug_rgw = 10/10). > > Of course, this is not a documented use case for subusers. I'm wondering > if Yehuda or anyone else could estimate our risk of future incompatibility > if we implement user/key management around subusers in this manner? > > Thanks, > Trey_______________________________________________ ceph-users mailing > list [email protected][mailto:[email protected]] > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > _______________________________________________ > ceph-users mailing list > [email protected] > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >
_______________________________________________ ceph-users mailing list [email protected] http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
